Evidence

What question does this solve?

A test passed, a review happened, a decision was recorded. Each of these answers a different question, and none of them answers every question. The model needs to say what information supports which conclusion, so that a passing check is not read as proof that everything works and an agent’s report that it is done is not read as proof that it is.

Definition and role

Evidence is information used to support an evaluation or a decision in the route of a Delivery Unit. Its role depends on the conclusion it is meant to establish and on the conditions under which it was produced. It can also reveal uncertainty that was previously unknown.

A test result can support a conclusion about one behaviour. A review record can support that certain rules were examined. A recorded decision can show which commitment was authorized. Evidence is not an abstract guarantee of quality: it grounds a bounded conclusion, and using it means understanding what was observed or decided, which output it refers to, and which limits remain.

Artifact and evidence are different. Artifacts are products of the work. They can provide evidence, but their existence alone does not show adequacy. A test that has been written is an artifact; the result of running it can provide evidence; interpreting that result against a criterion is part of Evaluation; the resulting acceptance is a decision.

How it works

The question defines relevance

The question guiding an evaluation has to be clear. Plentiful information can still be insufficient if it does not answer the relevant condition. In an approval flow with spending limits, checking that the application starts does not show that a request is routed correctly, and one correct routing scenario does not, on its own, show the rule for substituting approvers.

Relevance is established against the Stage Contract and the purpose of the transformation. For a feasibility analysis, the relevant information may be constraints and alternatives; for an implementation, the evaluation has to consider behaviour and conditions of use. Not every decision needs the same depth of support: risk, reversibility and scope influence it, and that proportionality should be made explicit to avoid both weak evaluations and demands unrelated to the decision.

Context and traceability

These questions guide how evidence is understood; they are not a mandatory technical schema.

Aspect	Relevant question
Object	Which demand, stage and output does the information refer to?
Condition evaluated	Which requirement, assumption or criterion is being examined?
Origin	Who or which system produced it, and by what procedure?
Context	Under which conditions, environment and configuration was it obtained?
Point in time	When was it produced, and which revision of the work does it correspond to?
Result	What was observed, including failures and limitations?
Use in the decision	Which conclusion does it support, and who can decide on that basis?

A result obtained before a relevant change may not support the same conclusion about the later version. Missing information is not an unfavourable result. Not finding a check does not show that it failed, but it does not allow assuming that it succeeded either. The decision may have to wait for confirmation.

Sufficiency and the limits of a conclusion

Evidence can be relevant without being sufficient. Sufficiency is the relation between a body of information and the decision it is meant to support, within the established conditions. It does not mean removing all uncertainty; it means recognizing whether there is adequate ground for that decision and which limitations are accepted. When criteria depend on judgment, it should be understandable why the information was considered sufficient.

Conclusions must not widen as they travel along the flow. An accepted analysis does not show that implementation will be simple. An accepted feature does not show that it will produce the expected business benefit. Each conclusion stays tied to the scope of the information behind it.

Contrary information and revealed uncertainty

Evidence can show that an output misses a criterion, that an assumption does not hold, or that an unknown constraint affects the work. Its role is not only to confirm the chosen path. An analysis can find that the integrated system does not provide information the solution needs; that can be an adequate output of an investigation stage and, at the same time, stop the imagined solution from going ahead. Contradictory information must be dealt with rather than filtered for the favourable parts. More evidence does not always mean a narrower forecast or a lower cost; the model has to allow understanding to be revised, a stage to be revisited, or work to stop.

Human, automated and combined production

People and systems can both produce relevant evidence. Origin alone does not guarantee validity: a person can misread a rule, and a system can check a condition other than the one needed. An agent’s statement that the work is finished must be distinguished from the information that would let anyone verify it, and the same holds for a human statement.

When production and evaluation share the same mistaken assumptions, they can agree without detecting the problem. Evaluation by another agent does not guarantee independence either: incomplete criteria, shared context or the same wrong interpretation can affect both. The composition should seek signals suited to the conclusion, such as observations of the environment, integration checks and references to the demand. Depending on risk, the policy may require additional review or separation of responsibilities; the model sets no universal obligation of independent evaluation, and does not make every evaluation manual.

In the running example

Discovery and construction at the barbershop produce evidence with different roles, and the operation has to recognize what each one allows it to conclude.

Illustrative information	Conclusion it can support	Limit
Booking rules clarified and accepted	There is a reference for designing booking.	It does not show the exact cost of construction.
Investigation of the existing integration	One alternative was examined under identified conditions.	Changes in the environment may require investigating again.
Offer accepted by a direct or delegated authority	There is a commitment within the recorded scope.	It does not show the implementation is technically adequate.
Test of conflicting times	The observed behaviour meets the scenario examined.	It does not prove rules or scenarios not covered.
Deployment confirmed and evaluated	The change is accessible under the verified conditions.	It does not prove fewer missed appointments.

When a rule or the integration changes, the operation identifies which conclusions still apply. That link makes it possible to resume work, revise conditions and decide on continuing without losing the origin of the information. The integrated acceptance criteria of the case are listed in the example Delivery Unit.

Boundaries and failure modes

Evidence informs decisions; it does not make them. A Quality Gate uses evaluation to decide on technical or quality acceptance, and its evidence should relate to the relevant criteria. A Commercial Gate can use technical information, estimates and economic conditions to decide on continuing; evidence of feasibility contributes to that decision but is not an authorization. Conversely, a recorded authorization shows a commitment was assumed, not that an output is technically adequate. The Delivery State reflects recognized evaluations and decisions; evidence not yet evaluated means there is information available to decide, not that a transition to acceptance can happen directly.

Evaluation is part of the economics. Progressive Estimation uses information produced along the way to revise forecasts; an offer becomes safer through relevant information, such as verified assumptions and bounded risks, not through the number of stages passed. Obtaining, organizing and evaluating evidence consumes resources. The hypothesis about AI includes this share: producing alternatives and implementations more cheaply only widens the viability of the service if their adequacy can be recognized at a sustainable cost. Agreement between agents, or a larger volume of records, does not demonstrate sufficient evaluation.

Too much and too little both fail. Records without context are hard to interpret; disproportionate documentation raises cost without improving the decision. Cutting checks only to save money can leave decisions unsupported. Not all information can be shared freely either: being able to use evidence in an evaluation does not authorize distributing it to every participant or tool. How to demonstrate sufficiency, deal with conflicting information and reuse evaluations across contexts remain open.

Connected concepts

• Structures overview
• Previous: Artifacts, the products that evidence is about
• Stage Contract, where acceptance criteria are specified
• Delivery State, which reflects the decisions evidence supports
• Glossary