The audit trail and records that cannot be rewritten

What is recorded

Privileged actions write an audit record as they happen: who did it, what they did, what it was done to, when, and the relevant before and after detail.

Ledger reversals, tax remittances, requisition approvals, invoice matches, bank matches, verification decisions and suspensions all appear there.

Why a policy was not enough

Row-level security stops signed-in users from rewriting history, but it does not apply to privileged connections such as service keys or direct SQL. During an earlier build, automated agents tidying up their own test data deleted the audit rows recording what they had done.

A trigger fires for every role, including the table owner. That is what closes the gap, and it is why the protection is a trigger rather than a policy.

Attribution survives

The platform refuses deletions that would blank who did what. An attempt to delete a retired administrator account was rejected by the database, because removing the user would have nulled the actor on its historical audit entries.

The account was retired instead: no login, no privileges, history intact. That trade is deliberate. A record with the actor removed is not a record.

The same rule elsewhere

Journal lines are append-only, and journal entries can never be deleted. Complaint case histories accumulate rather than being edited. Account suspensions and reinstatements are both events, so the history reads as a sequence.

Corrections everywhere are additive: a reversal and a new entry, never an edit.

Retention

Pruning audit history for retention is possible but deliberately awkward. It requires an explicit migration that disables the trigger, prunes, and re-enables it. Deleting audit history should be a reviewable act, not an incidental delete.