Surviving an audit
Auditors ask a small number of questions and they are always the same ones. What separates a comfortable day from an expensive one is whether each has an answer that resolves to a record rather than to somebody's recollection.
The five questions
They vary in wording and not in substance. An ISO surveillance audit, a customer quality audit and an acquirer's technical diligence all converge on the same five.
- What did this unit ship with? Not what the current design says — what was specified for that serial number on that build date.
- Who approved this change, and what were they looking at? The approval and the evidence that was in front of the approver at the time.
- Show me the corrective action for this finding, and prove it worked. Closure without verification evidence is the standard finding.
- Which drawing revision was current when this shipped, and who had a copy? The register, not the file.
- Can you demonstrate this record has not been altered? The question behind all the others.
What answers each one
What a unit shipped with is a resolution: the structure as at that date, for that unit number, at that plant, with every line naming its revision and the condition that included it. Reconstructing it from work orders tells you what was consumed rather than what was specified, and if a floor substitution was recorded as the original, the reconstruction is confidently wrong.
Who approved what is an approval bound to the object at the revision approved, with a recorded meaning — approved, rejected, abstained, delegated, escalated — rather than a boolean. The impact set computed at draft time is stored with the change, so what the approver was shown is part of the record.
Corrective action effectiveness is enforced rather than documented: a CAPA cannot close without verification evidence attached, and failed verification reopens at root cause rather than closing with a note.
Drawing distribution is the controlled copy register — who holds which revision, issued when, expiring when — and every outstanding copy of a superseded revision is marked as such with its holders named.
The question behind all of them
Can you demonstrate the record has not been altered? In most systems the honest answer is no. An audit table that somebody with database access can update is a table whose contents rest on trust rather than evidence.
The audit trail here is hash-chained: each row commits to the content of the row before it. Editing a row changes its hash, so the next row's recorded predecessor stops matching and verification fails at that link, naming the row. Editing does not hide a change; it relocates the evidence to the break.
Unattributed writes are refused rather than recorded as unknown, which applies to background jobs, connector runs and agents as well as people. There is no anonymous category to hide in.
Administrators have no silent bypass. One who needs into a restricted programme grants themselves access and leaves a row saying so — which is the difference between an answer and a shrug when somebody asks who read a file.
Preparing, and what still takes work
Most audit preparation is assembling evidence that already exists into a form somebody can read. Exports cover change packages, audit reports, compliance packages and product dossiers, in documented open formats rather than a proprietary archive.
What still takes work is the parts nobody recorded. A relationship that lives in a drawing note, a decision made in a corridor, a qualification whose scope was agreed on a call — none of those become records because a system arrived, and an auditor asking about them gets the same answer as before.
That is worth saying because it is the honest limit of every claim on this page. The system makes recorded things provable; it does not make unrecorded things exist.
How it meets your ERP
Connector runs are attributed audit rows naming the connector, the run and the direction, so “which system changed this value and when” resolves to a system rather than trailing off. That covers half of the most awkward audit question in an integrated setup.
The other half lives in your ERP and Manufacturing PLM cannot show it. A value edited there appears here as a difference at the next sync rather than as an event, and reconstructing that side means using your ERP's own audit facility.
What Manufacturing PLM can demonstrate is that what the ERP received is what engineering approved: the published structure is a resolution of the released revision at the change's effectivity, and because resolution is deterministic that demonstration is repeatable rather than a one-off export somebody has to be trusted about.
Where the boundary is
No compliance claims. This has not been validated against 21 CFR Part 11 or eIDAS, and the electronic signatures are authenticated and audited rather than qualified. The foundation is right; the validation has not been done, and claiming it on a public page is the kind of statement somebody relies on wrongly.
A hash chain also proves internal consistency rather than external timestamping. It shows rows have not been altered relative to each other since they were written; it does not independently prove *when* to a third party. Anchoring to an external notary is a reasonable addition and is not claimed today.
Facts
| What shipped | A resolution — date, unit, plant, every line at revision |
| Approvals | Bound to the revision, with a meaning, not a boolean |
| What the approver saw | The impact set, stored with the change |
| CAPA closure | Requires verification evidence — enforced |
| Drawing distribution | A register with holders, revisions and expiry |
| Tamper evidence | Hash-chained; a break is located, not just detected |
| Unattributed writes | Refused, for jobs and agents as for people |
| Not claimed | 21 CFR Part 11 · eIDAS · external timestamping |
Frequently asked
What do auditors actually ask?
Five questions, in varying words: what did this unit ship with, who approved this change and what were they shown, prove the corrective action worked, which drawing revision was current and who held it, and can you demonstrate this record was not altered.
How do you answer what a unit shipped with?
As a resolution — the structure as at that build date, for that serial number, at that plant, with every line naming its revision. Reconstructing from work orders tells you what was consumed rather than specified, and a recorded substitution makes it confidently wrong.
Can somebody edit the audit trail?
They can change the bytes, and it breaks the chain. Each row commits to the content of the one before it, so an edit makes the next row's recorded predecessor stop matching. Editing does not hide a change; it relocates the evidence to the break.
What proves a corrective action worked?
Verification evidence attached before closure — an inspection record, a batch that passed, a test report at a revision. It is enforced rather than documented: a CAPA cannot close without it, and failed verification reopens at root cause rather than closing with a note.
How do you show who held an old drawing?
The controlled copy register: who received which revision, issued when, expiring when. On a new release, every outstanding copy of the superseded revision is marked as such with its holders named — which turns a guess into a list somebody can work through.
What still will not have an answer?
Anything nobody recorded. A relationship living in a drawing note, a decision made in a corridor, a qualification scope agreed on a call — none of those become records because a system arrived. It makes recorded things provable; it does not make unrecorded things exist.
Are you Part 11 compliant?
No, and we will not claim it. The foundation is right — hash-chained audit, refused unattributed writes, approvals bound to object revisions — but it has not been validated. A compliance claim on a public page is exactly what somebody relies on wrongly.