Trust2026-09-22 · 6 min read
Why your audit log must be append-only
No update routes, no delete routes. Learn why that design makes an audit trail meaningful and how to verify it on any system.
Field notes · Built by Arche Axon
An audit log that can be edited is a suggestion, not a record. The design decision that separates the two is unfashionably simple: no update routes, no delete routes; the log only grows.
Why the absence of routes matters
It is not that administrators are trusted to 'usually not' rewrite history. The API surface makes rewriting history impossible; there is no endpoint to call. Good audit systems are defined by what they refuse to implement. Every mutation on customers, orders, products, broadcasts, tickets, and permissions writes a structured event: what changed, who changed it, when, and from where.
How to verify it on any system you use
- 01Ask for the API reference for the audit resource. If you see PATCH or DELETE next to it, the trail is negotiable.
- 02Ask what happens on permission changes specifically: role grants are the edits a bad actor would most want to disappear.
- 03Ask if the log is exportable. An audit trail you cannot take with you belongs to the vendor, not to you.
Trust is not a feeling you extend to a system. It is a property you verify, ideally by trying to break it.