A large ERP programme was designed around performance and integration. Eighteen months in it fails audit - not because it is slow or badly integrated, but because it cannot demonstrate who changed a financial record and why. Which architectural driver was missed, and why is this structural rather than a missing feature?

Why this is a driver, not a requirement

An architectural driver is a requirement whose change would force the structure to change. Test it: can auditability be added later by building a feature?

To answer "who changed this record, when, from what to what, under whose authority, and were they allowed to" you need every mutation captured at the point of write; the identity of the acting principal carried through every layer including batch jobs and interfaces; immutability once written; and retention outliving the row itself.

Each is a property of the write path, and the write path is everywhere. That is what makes it structural.

Why enterprise systems fail here specifically

ERP workloads are integration-heavy: data arrives from interfaces, batch loads, workflow engines and direct corrections by support staff. Each is a place where "who did this" is lost — usually replaced by a service account. A system where 80% of financial mutations are attributed to SVC_BATCH_01 has an audit log and no auditability.

The retrofit cost

Retrofitting means touching every write path, backfilling attribution that in many cases no longer exists, and — the expensive part — reconciling the new history against reports already issued from the old state. That is why the finding lands as a rebuild rather than a sprint.

The generalisable lesson

Ask of every candidate requirement: if this changed, would I redraw the diagram? Latency, availability, auditability, data residency and multi-tenancy usually pass. Most feature requests do not. The ones that pass are your drivers and belong on page one of the architecture document, not in a compliance appendix.