The basis of a conclusion
Information comes from different sources, with unclear freshness or relevance to the decision.
- Review focus
- Material provenance, acceptance criteria and the connection between a conclusion and its supporting basis.
← Home
RESEARCH / EVIDENCE / VERIFICATION
Approach and evidence discipline
From your system’s question to explicit trust boundaries, agreed criteria and verification of a specific implementation.
VISUAL CONTEXTData review
APPROACH / PRACTICAL QUESTIONS
Find your starting question.
Start with a situation in your system. Each one identifies a subject for assessment and the relevant research programmes.
Permission to act
An analytical recommendation, including one from an AI model, may initiate a critical operation.
- Review focus
- A separate basis for permission: who may act, on which object, under what conditions and within which limits.
An unknown outcome
After an interruption or loss of connectivity, it is unclear whether an operation took place.
- Review focus
- Separation of permission, attempt and confirmation; explicit uncertainty and conditions for retry and recovery.
Controlled state changes
A new rule or configuration may enter a system without a clearly defined point of acceptance.
- Review focus
- Separation of a proposal, its assessment, an admission decision and the state actually persisted.
Trust between nodes
Participants hold different information, messages arrive late and connectivity may be interrupted.
- Review focus
- Boundaries between received information, local state, authority and confirmation of an outcome.
Readiness of a specific version
Source code and passing tests exist, but the basis for admission to the intended environment has not been established.
- Review focus
- Alignment of the artifact, criteria, verification results and gaps in the evidence.
These are subjects for research and technical review. Actual properties and readiness are assessed for a specific implementation, version and environment.
APPROACH / EXISTING INFRASTRUCTURE
A place in your existing architecture.
The review examines connections between analysis, access, state and execution. It identifies the supporting basis each component passes on and the authority each transition requires.
Access and roles+
Is permission tied to the specific operation, current context and defined conditions?
For access-management tools, including IAM and RBAC, the review examines the transition from identity and roles to admission of an individual action.
AI and agent platforms+
Where is the boundary between a model’s recommendation and authority to act?
Identify preconditions, permitted operations and outcome confirmation when an analytical component hands a proposal to an executor.
Logs and audit+
Is a record tied to the relevant version, authority and actual outcome?
Examine whether the operation trail makes its basis traceable and distinguishes an attempt from a confirmed consequence.
Software verification+
Does the available evidence support the specific admission decision?
Compare the checked version, method, conditions and results with acceptance criteria, and explicitly record the limits of the conclusion.
Synchronisation and consensus+
Which decisions remain local, and who may grant authority?
Examine how agreed data or state relate to the right to execute, especially under delays or incomplete information.
Monitoring and response+
Which actions are permitted after an anomaly is detected, and how are their outcomes confirmed?
Connect response conditions to operational limits, execution records and available observations of the consequences.
From claim to conclusion.
The open DA-EX-001 case demonstrates the method on the inquiry form of this site. For research programmes, the public site presents purpose, bounded summaries and conclusion limits; technical materials are reviewed within an agreed scope.
Claim
What property is being asserted?
Mechanism
What part of the system supports it?
Evidence
Which version do the materials refer to?
Verification
Who checked it, how and under which conditions?
METHOD / AN EXAMPLE
One operation. Three distinct questions.
An illustrative example: a team plans to update a software component. The decision can be examined in sequence.
- 01
Basis
Which version is under consideration? Which materials support its properties?
- 02
Permission
Who approved the change? Within what scope and under which conditions?
- 03
Outcome
What is confirmed after the attempt? Which consequences remain unknown?
A test report, permission to update and an outcome record answer different questions.
What a verification package should contain
This structure helps a reviewer understand and reproduce the basis of a conclusion. It is a recommended structure, not a list of evidence already published.
- 01
Artifact
Version, build identifier and a manifest of materials.
- 02
Claim
The property, its boundaries and acceptance criterion.
- 03
Preconditions
Environment, dependencies and verification assumptions.
- 04
Method
Procedure, input conditions and expected outcome.
- 05
Results
Logs, reports, deviations and open questions.
- 06
Conclusion
What was established, who checked it and where it does not apply.
METHOD / CONCLUSION BOUNDARIES
How to read a status
Under research
A problem or architectural hypothesis has been formulated. The property still requires appropriate substantiation.
Implemented
A specific software artifact exists. The presence of code alone does not establish all claimed properties.
Verified within a defined scope
A method, conditions, result and version are identified. The conclusion applies to the scope that was checked.
Verification materials are made available for an agreed technical assessment. A public programme profile does not replace examination of a specific package.
Key terms, clearly explained
- Provenance
- Where information or material originated and how its history can be traced.
- Admissibility
- Whether material meets explicit rules for use in a particular decision.
- Authority
- A defined right to permit an action within a scope and under specified conditions.
- Artifact
- A specific object of assessment: a code version, build, model or document.
- Fail-closed
- The principle that an unmet necessary condition does not become permission. The system model defines the specific behaviour.
- Evidence trail
- The connection between a claim, its supporting basis, a decision and the recorded outcome.
R&D / DIALOGUE
You do not need a programme name.
Describe the decision, action or state that needs to become accountable. That is the starting point for defining the work.