Evidence that links decision to outcome.
A conceptual event model for reconstructing an autonomous action without inventing a production schema.
- Input
- principal + task + action
- Check
- authority + policy + context
- Output
- decision + evidence
- request
- principal · task · exact action
- decision
- policy version · reason · timestamp
- execution
- attempt · response · timestamp
- observation
- source · state · timestamp
A successful decision and an observed result remain separate records.
The facts to correlate
A useful evidence trail links acting principal, owner, originating authority, delegated chain, applicable policy, trust context, requested action and runtime decision. Approval belongs in the record when required. Execution result and observed outcome should be separate correlated facts.
Identifiers and timestamps matter because decisions, tool calls and observations may occur in different systems. The correlation design should make a decision traceable without copying sensitive payloads into every log.
- Principal and owner
- Authority origin and chain
- Policy and context
- Action and decision
- Approval when relevant
- Execution response and observed outcome
Different failures, different stories
If a request is denied because the child grant expired, an operator should see that boundary. If the request is allowed but the tool fails, a reviewer should not conclude the action happened. If the tool succeeds but the expected state never appears, verification should show the observation gap.
Evidence also helps identify indirect paths that bypassed a policy decision. The record needs enough structure to distinguish an authorization failure from an integration or execution failure.
Concept, not contract
This page describes the categories of evidence needed for trustworthy review. It does not publish field names, retention guarantees, transport protocols or a production event schema. Those details belong to the specific product and deployment agreement.
Preserve uncertainty honestly
Execution systems can time out after receiving a request. The caller may not know whether the operation happened. Evidence should say that the outcome is unknown until it is reconciled, rather than recording a false success or failure. This distinction matters for payments, remediation and physical commands where a duplicate retry can cause harm.
The same principle applies to delayed observations. A configuration API accepting a change is not proof that the target state propagated to every region. Correlate the later observation with the original decision, while retaining the different timestamps and sources.
Integration Review