ISO automation can write a revision number, update a register, and calculate a retention date the moment a document is approved — but it cannot decide whether that document deserved approval in the first place. That decision is content adequacy review, and ISO 9001 assigns it to a competent person, not a script. Any automation build that quietly moves this decision to software has broken the system it claims to support.
This is the part of the workflow we get asked about most, usually by a QMR who has just sat through a vendor pitch promising "AI-reviewed" documents. So it's worth being specific about why this decision resists automation, not as a compliance disclaimer, but as an honest description of what the decision actually requires.
What content adequacy review actually requires
Content adequacy review is the point in the change-control cycle where an approver looks at a proposed document or revision and judges whether its content is correct, complete, and safe to release. That sounds like a single check. In practice it's several distinct judgments happening at once:
- Technical correctness — does the procedure, specification, or work instruction describe a method that actually produces a conforming result?
- Fit with reality — does it match what actually happens on the floor today, or does it describe a process that existed two revisions ago?
- Conflict detection — does it contradict another controlled document already in force — a related work instruction, a customer specification, a regulatory requirement?
- Scope and completeness — does it cover the exceptions, the edge cases, the failure modes an operator will actually encounter?
- Consequence judgment — if this document is wrong, what fails downstream, and is the risk proportionate to how the change is being handled?
Every one of those five checks depends on knowledge that doesn't live inside the document being reviewed. It lives in the approver's understanding of the shop floor, the customer contract, the other twenty documents this one has to stay consistent with, and the plant's own history of what happens when a procedure is quietly wrong for six months before someone notices. That's tacit knowledge, accumulated on the job. No document-comparison algorithm has access to it, because it was never written down anywhere a machine could read it.
Why ISO automation cannot make this judgment
Set aside the compliance argument for a moment and look at the mechanics. A system, including a large language model reading the document text, can compare a draft against other stored documents, flag inconsistent terminology, or catch a missing field. That's real, useful, and something automation can assist with. What it cannot do is verify correspondence between a sentence on a page and a physical reality on a production line it has never observed.
Content adequacy review is not a text-consistency check. It's a judgment about whether words match a world. A model can tell you two documents disagree with each other. It cannot tell you which one is right, and it certainly cannot tell you whether either one reflects what the operators are actually doing at Station 4 this week. Only a person with floor knowledge, contract knowledge, and accountability for the outcome can make that call, and accountability is the operative word. When a document turns out to be inadequate and causes a nonconformance, ISO 9001's clause 7.5 traceability exists precisely so there is a named, competent person who made that judgment and stands behind it. A model output has no such standing, and no auditor will accept one as a substitute.
This is also why we build the clerical layer and stop there. ISO automation, done correctly, executes what happens after a human has made this call — numbering, register entries, distribution updates, retention dates — and never touches the call itself.
Where this sits in the four-gate structure
Content adequacy review isn't a standalone step we invented a category for — it's Gate 2 of the four human decision gates that structure ISO 9001 document control end to end: a reviewer marks the change-request form (Gate 1), an approver checks content adequacy (Gate 2), and a combined final gate completes master sign-off, including external and support documents (Gates 3 and 4).
Gate 2 sits in the middle for a reason. Gate 1 is a lighter filter — is this change worth pursuing at all. Gate 2 is where the real technical judgment happens. Gates 3 and 4 finalize the decision administratively. Automation has no role in any of the four, but Gate 2 is the one worth dwelling on here, because it's the gate most often targeted by "smart approval" pitches, and the one where getting it wrong causes the most damage.
What automation may do around Gate 2, and what it may never do
The boundary is easier to see as a table than as a paragraph:
| Action | Automation's role |
|---|---|
| Routing the document to the correct approver | Allowed — this is logistics, not judgment |
| Reminding an approver a review is pending | Allowed |
| Flagging that a referenced document ID doesn't exist in the register | Allowed — a data-integrity check, not a content judgment |
| Recording the approver's Gate 2 decision once made | Allowed |
| Writing the revision number, register entry, and distribution update after Gate 2 clears | Allowed — this is the clerical layer |
| Suggesting whether the content is technically adequate | Not allowed |
| Auto-approving changes below a "low risk" threshold | Not allowed |
| Skipping Gate 2 because a previous similar change was approved | Not allowed |
| Treating a passed text-similarity check as equivalent to approval | Not allowed |
The left column keeps getting longer as automation tooling improves. The right column doesn't move, because it isn't a technology limit — it's what ISO 9001 requires, and what a serious quality system should want regardless of what's technically possible.
What this looked like in a real build
In the reference build we did for a Thai manufacturer, ISO 9001:2015 certified across two sites, Gate 2 stayed exactly where their own SOP put it: an approver checks content adequacy on the paper change-request form, by hand, the same way they always had. The automation doesn't read the form's content and doesn't weigh in. It waits.
Only once that approval, and the two gates after it, had been recorded did the system act, and what it did at that point was entirely mechanical: it wrote eight fields that a document controller had previously retyped by hand into multiple registers — revision number, effective date, amendment-record entry, a master document list row across a ten-department distribution matrix, change-register entry, the year-keyed request number, page count, and the calculated retention/disposal-due date. You can see the full list of what gets written and how it's logged. Every one of those eight writes is individually logged to an activity log, and the workflow is idempotency-keyed, so replaying the same approval event never duplicates a register row.
That activity log is worth pausing on, because it's the actual answer to "how do we know a human really did the review." It doesn't log a content judgment, it logs the fact that a recorded approval event occurred and exactly what the system did in response. The judgment itself stays where it belongs: on paper, or in whatever medium your SOP already uses, made by the person your SOP already names.
The trust question this actually answers
Every QMR evaluating an automation vendor is really asking one question, whether or not they phrase it this way: will this system quietly start making decisions I'm accountable for? The honest answer, for any system worth adopting, is no — and the way to prove it isn't a reassuring sentence in a sales deck, it's a system design that structurally cannot approve content, because that step was never wired to anything except a human action.
That's the trust-building premise of everything else in this cluster. The clerical work — the retyping, the register drift, the hours lost to copying the same eight fields into six places — is real, tedious, and worth removing. The judgment isn't, and shouldn't be, on the table.
FAQ
Can content adequacy review ever be automated, even partially?
The judgment itself, no. Supporting checks around it — routing, reminders, flagging a missing reference, catching a duplicate document ID — can be automated, because those are data-integrity checks, not judgments about whether the content is correct.
Isn't a large language model getting good enough to read documents for correctness?
A model can compare text against other text. Content adequacy review requires comparing a document against physical reality on a production floor the model has never seen, which is a different task entirely, and one where the accountability for being wrong still needs to sit with a named person under clause 7.5.
What does ISO automation actually remove, then, if not this?
The clerical consequences that follow after Gate 2 clears — numbering, register entries, distribution updates, retention dates — the repetitive, error-prone retyping that has nothing to do with judging content.
How do auditors view a system that automates the clerical layer but not Gate 2?
Generally favorably, because it produces a clean, individually logged audit trail tied to a recorded human decision, which is easier to defend than a hand-maintained register where it's unclear whether an entry matches what was actually approved.
Does this mean automation can't help the approver at all?
It can help around the edges — surfacing the right version of a related document, flagging that a referenced clause number doesn't match anything in the register — without ever weighing in on whether the content itself is adequate.
To see exactly how this boundary held up under a real, signed-off build — Gate 2 preserved on paper, 19 of 19 acceptance criteria passed, and all 51 pre-existing unrelated workflows on the same tenant verified unchanged — see the build record for our reference build for a Thai manufacturer. 1% EVO builds the clerical layer around your existing approval gates and hands you the system outright; the judgment calls stay exactly where your SOP already puts them.