Observation is not the same as fact
An AI tool can return data without proving the interpretation the model wants to make from it.
A search result can be outdated. A command can succeed while printing an unexpected value. A browser can load a page that is not the intended account. Two APIs can return different versions. A write can succeed while containing the wrong content.
A useful evidence system therefore separates:
Observation: what a tool or source returned.
Evidence: an observation retained with source, context and verification status.
Fact: a value the system is prepared to treat as verified for a specific obligation.
Three states are often enough
A minimal fact-state model can be surprisingly powerful.
UNKNOWN means the system does not yet have adequate proof.
VERIFIED means accepted evidence satisfies the defined condition.
CONFLICT means accepted evidence supports incompatible values or conclusions.
This is better than a Boolean true/false flag because uncertainty and disagreement are not the same thing as failure.
Why UNKNOWN should be legal
Agents often feel pressure to answer. That pressure can turn missing evidence into a guess.
If a required version number has not been found, UNKNOWN is the correct state. The next step can search another source, request clarification or explain that the fact cannot currently be verified.
Keeping UNKNOWN explicit also prevents a completion gate from accidentally treating an absent value as a successful empty result.
Why CONFLICT deserves its own state
Suppose two accepted sources return different values. Silently overwriting the first value with the second destroys useful information.
A CONFLICT state preserves the disagreement and forces the workflow to resolve it deliberately. Resolution might involve:
- preferring an authoritative primary source;
- comparing publication timestamps;
- checking environment or version scope;
- seeking a third independent source;
- asking the user which interpretation is relevant.
Until the conflict is resolved, a required obligation should normally block semantic completion.
Evidence should be tied to the obligation it supports
A response being “accepted” globally is too vague. Evidence should record what it supports.
Useful fields include:
- source or tool identity;
- timestamp;
- target obligation or fact;
- raw or normalised value;
- verification state;
- derivation method if the value was computed;
- relevant limitations or scope.
This prevents unrelated successful evidence from being reused to close the wrong task condition.
Use deterministic resolvers whenever possible
If evidence contains a structured value, software should extract it directly rather than asking the model to repeat it.
Examples include:
- read a JSON field;
- filter records by an explicit predicate;
- count matching items;
- sum numeric values;
- select min/max;
- parse and order semantic versions;
- deduplicate values;
- compare exact strings or numeric thresholds.
Deterministic derivation improves reproducibility and reduces the number of state transitions that depend on model wording.
Derived facts still need provenance
If code derives 62 by summing accepted values 35 and 27, the final fact should retain enough provenance to show where the inputs came from and which rule produced the result.
“Deterministic” does not mean “source-free”. It means the transformation can be reproduced exactly.
Mutation receipts need independent verification
Mutating tools are the most important evidence boundary.
A successful receipt can establish that an operation executed:
- the file write returned success;
- the API accepted the update;
- the UI automation clicked the control;
- the process launcher created a child process.
But those receipts do not automatically establish the user’s desired postcondition.
For high-value mutations, use:
action receipt → independent observation → semantic comparison.
Examples:
- write file → read file back → compare content;
- change setting → query effective setting;
- start service → check health endpoint;
- submit form → confirm resulting state or record;
- update database → independently query the row.
Do not use the model’s own prose as proof
The model can explain evidence and propose a conclusion, but free-form text should not bypass the verification state.
A finaliser can produce a readable answer from VERIFIED facts while refusing to state unresolved UNKNOWN or CONFLICT values as certain.
This keeps the evidence contract stronger than the narrative layer.
Rejected evidence must stay rejected
If an observation fails validation, it should not later become a verified fact simply because the model repeats it. The verifier should require accepted evidence supporting the target obligation.
This also helps prevent a common agent failure: one malformed or partial response enters context, then becomes “true” through repetition.
Example: one wrong write exposed the boundary
In a retained ARKTOR Controller test, a model wrote an incorrect summary payload while the filesystem tool correctly returned success. The low-level receipt was accidentally promoted to semantic completion by a legacy integration path.
An independent scorer rejected the file, leaving the real result at 8/9.
The lesson was generic: execution evidence and goal evidence are different evidence classes.
Read the engineering story in Tool Success Is Not Goal Success.
Evidence-verification checklist
- Does every required fact start UNKNOWN?
- Is evidence associated with a specific source and obligation?
- Can rejected evidence be prevented from verifying a fact?
- Can two incompatible accepted values create CONFLICT?
- Does conflict clear or block the previously accepted value?
- Are simple derivations performed deterministically?
- Do derived facts retain provenance?
- Are mutations verified through independent observation?
- Does the final answer use verified state rather than model confidence?
- Can the system explain what remains unknown?
The useful principle
An evidence system should make it easier for an AI agent to say “I do not know yet” and harder for it to say “done” without proof.
That may produce fewer impressive green checkmarks.
It produces more useful ones.