Receipts are unnecessary when the output looks right. Really?

Appearance can earn a first look

A page that loads, a poem that reads well or a balance that looks correct can be reassuring. For a small creative sketch, the visible artifact may be nearly all the evidence a reader needs to judge its merit.

For a consequential action, the same surface can hide a wrong version, a duplicate payment or an unauthorized source. Two identical numbers on a screen might have come from very different transactions. A polished answer may have used a stale design document as if it were current runtime truth.

The invisible questions matter later

Suppose a site displays the correct music player. A build receipt identifies the packaged file; an upload receipt records the deployment action. Neither proves what the public page served. A separate live readback, compared with the artifact hash and time, tests that claim. Without these distinct proofs, repair becomes guesswork. The aim is not bureaucracy for its own sake; it is the ability to repair the result.

PHS's Governor consumer contract requires execution references and review rows for governed turns. Its scar-and-repair design links significant consequences to history. Those are design requirements, and a pretty screen does not independently establish that a live implementation met them.

Pause here: If this result were wrong tomorrow, what evidence would let someone reconstruct and repair it?

Keep receipts proportionate and useful

Receipts should match the stakes. A draft caption needs less machinery than a CRU transfer. They should say who authorized the operation, what was attempted, what happened, and how the claim was verified. They should be available to the people responsible without leaking private details into a public page.

If the output looks right, celebrate that it looks right. Then state what the record actually proves. The record protects the person who must answer when the attractive result and the underlying state diverge.