The Receipt

An agent changes something. A record is updated, a message is sent, a file is written, a deployment occurs, money moves, a permission changes or a workflow advances.

The action succeeds.

Now what?

Most software systems answer with some version of: there is probably a log somewhere.

A log may tell us that an API call occurred, which credential was used, when the request arrived, whether the server returned 200 and perhaps which payload crossed the boundary. Useful. But a governed agent must answer a harder question:

Why was this system entitled to make that change?

That requires more than an event record. It requires a receipt.

A receipt connects consequence back to authority. It makes an action reconstructable not merely as something that happened, but as something performed by an identifiable delegate, for a defined purpose, inside a particular authority envelope, using relevant evidence and producing a particular state change.

Without that connection, governance disappears the moment execution succeeds. The action remains; the authority that justified it becomes folklore.

Logging is not legitimacy

Traditional logging is primarily observational. Something happened; record it.

Governance requires the record to preserve enough context to test legitimacy: who acted, for whom, under what delegation, toward what authorised objective, using what evidence, what action was selected, what state changed, what happened as a result and whether the action remained inside its authority.

Technically identical actions can therefore have completely different governance status.

Suppose two agents modify the same production configuration value using the same repository, account and API, changing the same old value to the same new one with the same successful deployment. The infrastructure logs may be nearly identical.

The first agent, however, had explicit production-repair authority for the service during the incident. The second had diagnostic authority only and changed the value because it correctly inferred that the repair would work.

Same operation. Same outcome. Different governance event.

A log describing only the mutation cannot tell the difference.

A receipt can.

The receipt closes the authority chain

The earlier authority chain was:

principal → delegation → artificial delegate → action

A receipt extends it:

principal → delegation → artificial delegate → action → changed state → receipt

The receipt should preserve enough information to travel backward through that chain. From the changed state, we should be able to identify the action that changed it, the delegate that performed the action, the authority envelope that permitted that class of action and the principal that legitimately issued the delegation.

This backward trace matters because consequential agents operate over time. The person who authorised the work may be absent. The agent instance may no longer be running. The surrounding conversation may be gone. The task may have lasted three days and crossed twenty systems. The organisation may now be investigating an outcome nobody expected.

Nobody should need to reconstruct legitimacy from memory.

A receipt is not an explanation generated afterward

Language models are very good at producing coherent explanations. That makes them particularly unsuitable as the sole source of historical provenance.

After an action occurs, an agent may be able to generate a plausible account of why it acted. The account may even be correct. But a post-hoc explanation is not the same thing as evidence captured from the execution state.

A receipt should therefore be derived from or anchored to information available at the time of action: the active delegation, relevant evidence, selected action, current state, result and identifiers of the systems involved.

The agent may later summarise the receipt.

It should not manufacture the receipt retrospectively from memory.

A convincing story is not provenance.

The minimum useful receipt

The exact schema should scale with consequence, but a useful receipt generally needs several fields.

Actor

Which artificial delegate performed the action? If multiple participants were involved, which participant selected the action and which executed it?

Principal

For whom or under whose authority was the delegate acting?

Delegation

Which authority envelope applied? The receipt should reference a stable version of the delegation rather than whatever the current policy happens to say later.

Objective

What authorised objective was the action intended to advance?

Input and evidence

Which facts, records, approvals or observations materially informed the decision? A receipt does not need to preserve every token the agent saw. It needs enough decision-relevant provenance to reconstruct the basis of the action.

Action

What did the agent actually do?

Previous state

What relevant state existed immediately before the action?

Changed state

What changed as a direct result?

Time

When was the decision made and when was the consequence created? These may differ in long-running workflows.

Result

Did the action produce the intended effect?

Errors and uncertainty

What failed, remained unresolved or differed from expectation?

Recovery

What rollback, compensation or recovery path exists where applicable?

Together these fields preserve the relationship:

authority → judgement → action → consequence

The receipt should preserve the authority that existed then

Authority changes.

Permissions are narrowed, roles change and delegations expire. An action may have been legitimate on Monday and prohibited on Friday.

A receipt should therefore not resolve only against the system's current authority state. It should preserve or immutably reference the authority applicable when the action occurred.

Suppose an agent performs an authorised data export, then loses export authority a week later. If investigators resolve the old receipt only against current policy, the historical action may appear unauthorised.

The inverse is worse. If an agent acted without authority and receives that authority later, the new grant must not retroactively legitimise the old action.

Permission is not time travel.

The receipt belongs to historical governance state.

Receipts should be append-only where history matters

A completed action should not quietly acquire a cleaner history later.

If new information appears, add it. If an earlier interpretation was wrong, correct it. If the action caused an unexpected downstream effect, record it. If an investigation later determines that the delegation was invalid, preserve that finding.

But do not rewrite the original event until the past behaves itself.

A useful pattern is:

original receipt → subsequent observation → correction → resolution

Each remains distinguishable.

This preserves an important property: what was believed then remains knowable after what is known now changes.

If every incorrect judgement is silently replaced by its corrected version, the system loses the evidence required to understand how it failed. A perfect historical record produced through retrospective editing is extremely impressive and completely useless.

A receipt can record legitimate refusal too

Receipts are usually imagined as records of actions performed. Governed agents also produce consequential non-actions.

An agent may refuse an unauthorised request, stop at an authority boundary, escalate, abort safely, decline because evidence is insufficient, preserve conflicting state or allow an authorisation to expire unused.

Those events can deserve receipts.

For example:

Requested production mutation not performed.
Existing delegation permits diagnosis and repair proposal only.
Escalation ESC-184 created for release authority.

Nothing changed in production, but something important happened: the system encountered an available capability and correctly declined to convert it into consequence.

That is governance evidence.

One workflow may produce many receipts

A long-running task should not necessarily create one enormous receipt at the end. That would collapse too much authority and consequence into one blob.

Imagine a workflow in which an agent inspects a customer record, identifies an anomaly, retrieves supporting documents, suspends a transfer, creates an escalation, receives approval from an authorised reviewer and then releases the transfer.

Different actions occur under different authority. Different evidence exists at each point. Different actors may participate.

A useful system can therefore maintain a receipt chain:

• R-001 — investigation opened;
• R-002 — records accessed under investigation authority;
• R-003 — transfer suspended under risk-containment authority;
• R-004 — escalation issued because release authority was absent;
• R-005 — approval received from an entitled reviewer;
• R-006 — transfer released under newly established authority.

The workflow remains reconstructable without pretending that one original instruction authorised every later event.

Momentum must not become inherited authority

Long workflows create a subtle pressure: once several legitimate actions have occurred, the next action begins to feel legitimate by association.

The agent has already accessed the records, created the analysis, prepared the change and received one approval. Surely the final step is implied.

No.

Authority should attach to the consequence being created, not to the emotional momentum of the workflow.

A receipt chain helps expose where authority changes, expires or must be renewed. It prevents “we were already doing it” from becoming a governance primitive.

Receipts should be proportional to consequence

Not every action needs a courtroom-grade evidence bundle.

A local agent renaming a scratch file does not need the same receipt integrity as a system transferring money, deleting customer records or changing production access control.

Receipt strength should increase with factors such as consequence, irreversibility, external commitment, contested authority, sensitivity and recovery cost.

Low-consequence actions may need compact records. High-consequence actions may justify stronger provenance, immutable storage, signatures, chained hashes or independent verification.

The goal is not maximal record keeping.

It is sufficient reconstruction.

A receipt should not become a surveillance excuse

Governance infrastructure can easily become an archive of everything the agent saw, every private message it touched and every intermediate thought it produced.

That is not automatically good governance.

A receipt should preserve decision-relevant provenance while respecting data minimisation, confidentiality and legitimate deletion requirements. It should capture enough to establish the authority and basis of consequential action without turning every governed workflow into permanent surveillance.

More evidence is not always better evidence.

Receipt integrity matters

A receipt that can be silently edited by the same actor whose action it is supposed to document provides weak assurance.

Again, proportionality matters. Depending on the stakes, integrity mechanisms may include append-only files, immutable database rules, versioned objects, cryptographic signatures, hash chains or external verification.

The technology is secondary to the property:

later observers should be able to distinguish the original receipt from subsequent alteration.

The receipt is evidence, not absolution

A receipt does not prove that an action was legitimate merely because all the fields are populated.

It may instead reveal that the agent exceeded its authority, the delegator lacked authority to delegate, evidence was insufficient, a policy conflict was ignored, an approval was invalid, the system acted after revocation or the consequence differed materially from the intended result.

That is still a successful receipt. Perhaps an especially valuable one.

Governance infrastructure should help discover illegitimate action, not merely produce prettier documentation for it.

A receipt is not a permission slip written after the crime.

It is evidence.

Receipts enable correction

Once receipts accumulate, governance can improve from observed consequence.

Patterns may reveal that an authority envelope is unnecessarily narrow or dangerously broad, that one escalation occurs fifty times per week and deserves an explicit policy path, that the agent repeatedly reaches a boundary nobody knew existed, or that the system is authorised correctly but exercising poor judgement inside its authority.

Without receipts, organisations design agent authority mainly from theory.

With receipts, they can ask:

What actually happened when we trusted this system?

That is a considerably better question.

The system should be able to answer for its action

For a consequential action, a mature governed agent should be able to provide a compact account:

I performed action A as delegate D for principal P.
Authority envelope E permitted the action toward objective O.
My decision relied on evidence X and Y.
State changed from S1 to S2 and produced result R.
Receipt R-2048 preserves the event.

If authority cannot be established, say so. If relevant evidence is missing, say so. If the result was uncertain, say so. If the action later proved wrong, preserve that too.

The purpose is not to make the agent sound accountable.

It is to make accountability technically possible.

The fourth law

The fourth law is:

Consequential action should leave enough evidence to reconstruct the authority, judgement and state change that produced it.

Without a receipt, authority governs only the instant before execution. Afterward, the world contains changed state and a story.

With a receipt, consequence remains connected to the legitimacy that produced it. When somebody later asks who changed this, why, under whose authority, based on what and with what result, the system does not need to improvise a convincing answer.

It can point to the record.

That is the difference between an agent that merely leaves traces and one whose actions remain answerable.