Start with the claim you need to support
A chronological log can show that code ran without showing whether the intended business action occurred. Evidence should connect a specific claim to an observation: which check passed, which source version it used and which destination record was read back. That structure makes an operator’s question answerable without reconstructing an entire execution transcript.
For an invoice draft, useful evidence includes the accepted contract version, source document reference, supplier lookup result, reconciliation checks, write operation identity and observed draft identifier. Model names and token usage may explain execution choices, but neither is proof that the bill exists.
Keep attempts, checks and effects linked
Retain relationships between events rather than flattening everything into one status message. A successful second attempt should not erase the first attempt’s rejected output. A passed business check should not hide that the destination read-back is still pending. Timestamps need a clear meaning, such as observation time rather than an inferred business-event time.
| Evidence group | Purpose |
|---|---|
| Accepted task | Identify the request, contract and policy context |
| Attempt history | Explain candidate generation and bounded recovery |
| Verifier results | Name the condition, version and supporting observation |
| Action observations | Connect the write to a destination identifier and state |
| Unresolved questions | Show what still requires reconciliation or review |
Useful evidence does not require unrestricted transcripts
Store references, selected values and check summaries according to the task’s data policy. Raw documents, prompts and provider responses can contain sensitive information; including them in every receipt expands the access and retention problem. Evidence access must follow the workspace and record permissions it describes.
A content digest can help compare two artifacts, but a digest alone does not establish who created an artifact or whether its contents were true. Similarly, a read-back records a point-in-time observation, not a promise that another user will never edit the record. Keep these limits attached to the evidence when presenting it for review.
Agree which fields operators need, which fields support personnel may access and how evidence is retained or removed. Define export requirements and access controls alongside the task contract so sensitive information does not become a by-product of troubleshooting. Confirm these arrangements during the integration review.
Missing a detail or found a problem?
Send a documentation question →