Receipt Definition

A Digital Action Receipt is a neutral, append-only, tamper-evident record that a specific digital action occurred, issued at the moment the action executes, so it can be referenced and verified later.

Goal

Replace “post-hoc reconstruction” (logs + screenshots + narratives) with evidence created at decision time. A receipt is the smallest possible proof artifact that can survive across systems, teams, and vendors.

Canonical properties

Issued at execution time: created when the action happens (not hours/days later).
Append-only: receipts are never edited; corrections happen by issuing a new receipt.
Tamper-evident: integrity is verifiable via hashing/signatures and stable identifiers.
Neutral: describes facts about an action without embedding internal logs or business logic.
Referenceable: produces a stable receipt ID / verification link that can be pasted into tickets/docs.
Independently verifiable: verification does not require privileged access to internal systems.

What a receipt proves

That an action was issued/executed at a specific time and context.
The who/what dimensions you choose to include (actor, action, object, scope).
The integrity of the receipt contents (that it has not been altered).
A stable reference that can be used in audits/disputes (“show me the proof”).

What a receipt does not prove

That the action was correct (only that it occurred).
That the system is secure, compliant, or well-designed.
That the underlying data is true (only that this event record is intact).
That humans interpreted the event correctly (verification is about integrity, not meaning).

Minimal receipt envelope

A receipt should be small. The minimal envelope can look like this (fields are illustrative):

{
  "receipt_id": "rct_01J... (stable ID)",
  "issued_at": "2025-12-29T18:23:11Z",
  "actor": { "type": "user|service|agent", "id": "..." },
  "action": "access.approved",
  "object": { "type": "resource", "id": "payments" },
  "ref": "internal-id-123",
  "context": { "request_id": "...", "environment": "prod" },
  "integrity": {
    "hash": "sha256:...",
    "signature": "optional"
  },
  "verification": { "url": "https://.../verify/rct_..." }
}

Design constraints (non-negotiables)

No deletes / no edits. If something changes, issue a new receipt that references the prior receipt.
Idempotency. The same action should not create duplicate receipts when retried.
Stable identifiers. Receipt IDs must remain valid over time; avoid ephemeral links.
Minimal surface area. Integrations should take minutes, not weeks.

Where receipts show up first

Access approvals and privileged actions
Deployments, config changes, automation events
Payment authorizations, limit changes, release approvals
Healthcare consent/access events
AI/agent actions executed on behalf of users/orgs