Make every consequential decision reviewable.
Preserve enough context to reconstruct why an autonomous action was requested, decided and executed.
- Attributable principal
- Valid authority origin
- Current policy and trust
- Enforceable action decision
- Authorization decisionALLOW
A valid authority chain permits this exact request.
- Execution requestSENT
The protected operation reaches its executor.
- Executor responseTIMEOUT
The response does not establish whether the effect occurred.
- Observed outcomeUNKNOWN
Reconciliation remains open; a retry requires care.
Execution evidence
The evidence chain
A decision record is useful only if it connects the acting principal to the authority origin and each delegated grant. It should identify applicable policy, trust context, requested action, decision and any approval. Execution result and observed outcome are different facts: a tool may report success while the intended system state has not yet been observed.
This is not simply an “immutable ledger” story. Evidence quality depends on accurate attribution, timing, correlation across systems and clear separation of intent, decision, execution and observation.
- Acting principal and authority origin
- Delegated chain and applicable constraints
- Policy and current context
- Requested action and decision
- Approval, execution result and observed outcome
Verification for operators and reviewers
An operator investigating a denied action needs to see the failed boundary. A reviewer examining an approved action needs to know which authority and policy version applied at the time. A security team may need to correlate a request with an incident, workflow or change ticket.
Evidence should be proportionate to the action. Harmless reads and changes to critical infrastructure have different assurance needs. Sensitive data should not be duplicated into decision logs merely to make an audit trail appear complete.
Evidence contract
A model, not a false schema promise
The ProofGrid architecture describes the facts an end-to-end authority decision should make available. Exact event interfaces and retention terms depend on the product and deployment and are not represented here as a generally available public schema. Existing audit foundations remain part of the platform lineage.
Questions evidence should answer
When an autonomous action is reviewed, the first question is often who or what caused it. The next is why it was permitted. A complete explanation needs the principal, accountable owner, task, authority origin, delegation chain, applicable policy, context and decision. It should also distinguish an approval from the agent’s own request and an execution response from an observed result.
The record should support both routine assurance and incident investigation. A reviewer may need to compare what the agent intended, what the tool attempted and what the system actually changed. Missing observations should be recorded as uncertainty, not silently converted into success.
- Who requested and owned the action?
- Where did the authority originate?
- Which policy and context applied?
- Who approved an escalation?
- What did the executor report?
- What outcome was observed?
Evidence has trust boundaries too
Agent-generated explanations can be useful but are not authoritative evidence of the grant or policy. The decision service, identity source and execution system should contribute records from their own trusted boundaries. A durable review trail correlates those records without assuming the agent’s narrative is accurate.
Evidence design must also minimize sensitive data. A record can reference a protected object, policy version and decision reason without copying an entire customer record or secret into a log. Retention and access controls should be appropriate to the deployment and its agreements, not invented in a marketing page.
Platform / Next Step