Evidence is not the same as a tool response
A tool response can prove that an operation was attempted or accepted. It may not prove that the intended real-world state now exists.
Match evidence to the claim
Use the strongest practical source for the task: read the resulting file, inspect the UI state, query service health, retrieve the resulting record or observe the device state.
Preserve uncertainty
If evidence is missing or contradictory, the agent should preserve that uncertainty instead of turning it into confident prose. The user benefits more from a bounded incomplete result than from false certainty.
Prefer deterministic checks where possible
The survival-test report is a concrete case: ten of fifteen checks passed, but truncated code prevented autonomous completion. For visual output, a vision-based checking method helps only if its own error rate is tested.
Simple facts such as file existence, schema validity, counts, hashes or service status should be checked by software rather than inferred from model language.
Choose the evidence before running the action
Start by writing down what a successful result would look like. For a generated document, this might be an existing file with the requested title and sections, not merely a tool's “write succeeded” message. For a service restart, it might be a fresh health response and successful request after the restart, not the restart command's exit code.
Keep the evidence close to the task record: what was requested, what action ran, what was observed and whether the observation matched. Do not store private documents or credentials in a public report. If the observation is stale, inaccessible or inconsistent, mark it inconclusive and say what could be checked next. The read-back guide shows that separation in a compact workflow.
Keep the public principle separate from implementation
Products can publish that important outcomes are independently verified without publishing their private evidence schema, state model, routing rules or recovery contracts.