Receipts, not logs

Every operational system already produces an enormous amount of writing about itself. Request traces, structured events, debug lines, metrics. That corpus is invaluable for one audience: the engineer diagnosing the code. It is nearly useless for a different audience, the one that matters when an autonomous system acts on the real world — the person who has to explain, defend, or reverse what the business actually did.

Logs answer "what did the process do?" A receipt answers a harder question: what did the organization do, on whose authority, and how do we undo it? Those are not the same question rephrased. They have different subjects, different retention requirements, and different failure modes when the answer is missing.

The failure mode of logs

When an agent acts through ordinary tooling, the record of that action is scattered by construction. The reasoning lives in a model trace. The API call lives in an HTTP log. The effect lives in a third party's audit tab, if they have one. Reassembling "we credited this account because the operator judged the order stuck, under this policy, and here is the reversal" means joining four systems by timestamp and hoping the clocks agree. Under audit pressure, hope is not a data model.

Worse, logs are emitted by whatever code happens to remember to emit them. Coverage is a matter of discipline, and discipline erodes exactly where systems change fastest. A log line is an aside. A receipt is an output.

What a receipt is

In the reference architecture, supported governed actions pass through deterministic execution code that writes a structured record around each attempt. That centralization reduces missing records, but it does not make an external effect and the local record one atomic transaction. Ambiguous outcomes must remain marked as such.

Each receipt carries a fixed anatomy:

That structure makes attribution and recovery support explicit. Because intent travels with the attempt, a reviewer can inspect the system’s stated basis without reassembling every fragment. The record still cannot establish facts the downstream system never confirmed.

Auditability as an output

Fibric treats governed execution records as a product surface. BearScope is live on supported CX and commerce data paths. The generalized executor and hotel BACnet example remain reference patterns; a real physical deployment would need to prove its record and controller-response semantics.

A common record contract can reduce per-integration variation. The catalog has 5 live BearScope listings and 43 managed early-access listings; a listing does not inherit proven accountability until its active path passes conformance and deployment review.

The test

Ask whether the last action has a record naming intent, authority, attempts, observed outcome, and supported recovery — and whether unknowns stay unknown. A useful record shortens an investigation; it is not automatic proof of what an external system or physical device did.

Keep reading: The executor doesn't reason · The audit trail is the product