Storing a document is not the same as being able to prove something about it. A document management system answers "where is the file?" A compliance system answers "which requirement does this record satisfy, who attested to it, and can you reconstruct that on demand?"
Those are different questions, and only the second one survives an audit.
The folder-structure fallacy
Walk into most regulated organisations and the compliance architecture is a directory tree. /Quality/2025/Audits/Q3/Batch-Records/. It is meticulous. Someone maintains a naming convention document. There is a SharePoint permissions matrix.
And it encodes nothing.
The folder path is a convention, not a constraint. Nothing in the system knows that a batch record in that folder is the evidence for a specific clause of a specific regulation. Nothing prevents a record from being filed correctly and being, substantively, the wrong record. When the auditor asks "show me that every batch released in Q3 had a completed deviation review," the honest answer is: we will go and look.
That sentence — we will go and look — is the entire problem. An audit becomes an investigation, staffed by your best people, for a fortnight.
What a compliance data model actually is
The move is to make the relationship between record and requirement a first-class entity, stored and enforced, rather than implied by where the file sits.
Concretely, the schema needs to represent:
- Requirements, as discrete, addressable clauses — not "ISO 9001" but the specific sub-clause, versioned, with its effective date
- Records, as immutable, hash-addressed artefacts, so that "the document" always means one exact byte sequence
- Assertions binding a record to a requirement: this document, at this version, is offered as evidence for that clause, attested by this person, at this time
- Lifecycle policy attached to the record class: retention period, archival trigger, disposal rule — and these must be executable, not written in a separate SOP that a human is supposed to run annually
- An activity ledger, append-only and hash-chained, recording every access, edit, approval, and export
Once that exists, the audit question changes shape. "Show me every batch released in Q3 with a completed deviation review" stops being a search and becomes a query, because the system already knows which records were offered as evidence for which clause.
Audit readiness becomes a property of the schema. It is not a function of how carefully the folders were named, or how good your quality manager's memory is.
Immutability is the cheap part
Organisations often fixate on the cryptography — hashing, chaining, sometimes a blockchain — because it is the part with a satisfying technical answer.
It matters. A tamper-evident, append-only ledger converts "we believe nobody altered this" into "altering this would be detectable." That is a genuine upgrade, and it is not hard.
But it is not where audits are failed. Audits are failed because the evidence chain has a gap: a record exists, but nothing captures why it was sufficient, or who decided that, or against which version of the requirement. You can hash an incoherent evidence chain perfectly and still have nothing to show.
Get the relationships right first. Then make them tamper-evident.
Where AI legitimately helps, and where it does not
There is real work for machine learning here, and it is narrower than the marketing suggests.
It helps with ingestion. Legacy archives are paper, scans, and non-searchable PDFs. OCR and layout models turn them into indexed, queryable assets. Classification and metadata extraction propose which record class an artefact belongs to, and which clause it plausibly evidences. That proposal saves enormous human effort.
It helps with retrieval. Semantic search over millions of pages, returning the passage rather than the file, is a step change over filename search.
It must not make the assertion. A model may propose that a document evidences a clause. A human with authority attests to it, and that attestation is what the ledger records. The moment a statistical system is the last signature in the evidence chain, you have automated away the accountability that the regulation exists to create.
This is not a philosophical position. It is what an auditor will ask you, and "the model classified it" is not an answer that ends the conversation well.
The practical test
Ask your current system three questions:
- For an arbitrary regulatory clause, can you enumerate every record currently offered as evidence for it, at the version that was effective on a given date?
- For an arbitrary record, can you produce the complete, tamper-evident history of who touched it and what changed?
- When a retention period expires, does anything happen without a human remembering?
If the answer to any of these is "we would go and look," you have a filing system. That is a real thing and it has value. It is just not a compliance system, and the difference will only become visible on the worst possible day.
DBOMS was built to answer those three questions as queries. See how it works.