Execution Receipts and Recovery
After a protected operation, the runtime can report what it knows. AIGP preserves that bounded attestation; the runtime remains responsible for the external system.
What a receipt means
An execution receipt is a bounded statement submitted by the authenticated runtime after an earlier ALLOW. It links the saved decision, action, tool-call identity, and arguments digest to the runtime's reported outcome. It does not independently prove that a database, payment system, or other external application changed.
Receipts contain identifiers, references, reason codes, and digests. They do not upload raw tool arguments, results, prompts, credentials, or error payloads to AIGP.
UNREPORTED and UNKNOWN are different
| State | Meaning |
|---|---|
| UNREPORTED | AIGP has an ALLOW but no receipt. It does not guess whether the operation ran. |
| UNKNOWN | The runtime explicitly reports that it cannot yet determine the external outcome, for example after a crash. |
| SUCCEEDED, FAILED, NOT_EXECUTED | A terminal runtime attestation when the runtime knows the outcome. |
Recovery without retry
If a mutation may have happened before a crash, the runtime reports UNKNOWN and reconciles using its own durable transaction record or idempotency evidence. It may then append one terminal receipt that supersedes the uncertain receipt. The original receipt is never edited or deleted.
Unknown is not a retry instruction
AIGP never retries, rolls back, or coordinates the external operation. A new attempt needs a new valid authorization; recovery must first establish what the external system did.What AIGP does not do
A late receipt may still be accepted as historical evidence after its decision expires or delegation is revoked. It never renews permission for another attempt. Read Runtime Action Authorization for the pre-execution decision and Replay Manifests for the separate replay-evidence assessment.