Receipts: what happened, honestly
Every decision leaves a receipt: ALLOW, DENY, REQUIRE_APPROVAL and FAIL_CLOSED alike.
Four words that are not the same
| Word | Receipt field | Meaning |
|---|---|---|
| authorized | authorized | Governance returned ALLOW |
| attempted | attempted | The protected function was invoked |
| executed | occurred | It returned without throwing. The only claim that the effect happened |
| completed | phase is COMPLETED or FAILED | The final receipt was written |
An allowed action that throws halfway is attempted: true, occurred: false. It may be partially applied, and the receipt says so instead of pretending it did or did not happen.
No receipt, no effect
The ALLOW receipt is written before the function runs. If the receipt cannot be written, the action is blocked as FAIL_CLOSED. An action you cannot audit does not get to happen.
What the integrity hash is
Each receipt includes a sha256 over its contents. senscheck explain and verifyReceipt use it to spot accidental or naive edits.
It is not a signature. Anyone who can rewrite a receipt can recompute the hash, and it cannot detect a deleted file. Store receipts somewhere the agent cannot write or delete (append-only storage, a separate account). SensCheck does not claim non-repudiation.
Reading one
npx @senscheck/governance-cli explain .senscheck/receipts.jsonlprints the decision, the plain-English reason for each code, the lifecycle, and whether the integrity hash still matches. Receipts leave out effect parameters, since those may hold sensitive data.