The fast implementation
A developer first builds a CRU transfer and plans to add receipts later. The transfer works in a simple test. Then a network interruption leaves the caller unsure whether to retry. Without a commit point and idempotent record, the missing audit trail is now a risk of charging twice.
Adding logs afterward cannot reliably reconstruct a past operation's authority, exact inputs, or partial effects. These facts must be captured where the operation crosses the boundary, when the information is still available.
Choose the evidence at the boundary
The PHS enforcement standard puts receipt production, failure handling, partial-effect classification, recovery, and runtime probes inside the engineering contract. It rejects compliance by paper declaration or a passing suite that misses the obligation. The claims discipline requires assertions to stay tied to evidence.
This does not mean logging everything forever. A useful audit chooses material events, protects private data, and keeps enough correlation to reproduce a consequential decision. Unbounded noise can hide the very signal the audit was meant to preserve.
Pause here: Which facts will disappear at the moment of action unless the system records them there?
Build trust into the route
Design the question first: what will an operator need to know if the call fails halfway, if the person disputes a result, or if a later version changes the meaning of an old field? That question informs API shape, storage, tests, and user-facing state before deployment.
A bridge's inspection points are easiest to place while its beams are being built. Welding them on after a cart has already vanished into the river is a more expensive form of craftsmanship.
My answer: Auditability is part of the design of consequential operations. Plan receipts, commit points, privacy, and recovery with the feature, not as a retrospective patch.