The Originals-Untouched Guarantee for an ISO Automation System

The originals-untouched guarantee means an ISO automation system never opens, edits, renames, or overwrites your original controlled documents. It reads state, it writes to registers and folders it owns, and it leaves the source file exactly as your reviewer and approver left it: same file ID, same name, same format, same modification time. A vendor who can't show that holding up under inspection doesn't have a guarantee. They have a promise.

This matters more in document control than almost anywhere else in a factory's software stack, because the thing being automated is also the thing being audited. An auditor doesn't just check whether your register says revision 4 exists. They can, and sometimes do, check whether the file itself has been tampered with outside the sign-off trail. A system that treats your controlled documents as something it's allowed to touch can quietly undermine the exact record it's supposed to protect.

Why "untouched" has to mean something specific for an ISO automation system

"We don't touch your originals" is easy to say on a call. It's much harder to build and even harder to prove. For it to mean anything, it has to be checkable against something concrete, not a policy statement, but a comparison you can run before and after a build goes live.

That comparison has four parts, and all four have to hold.

1. File ID — the document's underlying identifier in your storage system is unchanged. It wasn't deleted and recreated under the same name.
2. File name — no silent renaming, no suffixes appended, no versioning artifacts left behind by the automation itself.
3. File format — a .docx stays a .docx. Nothing gets converted, flattened, or re-saved through an intermediate tool that changes the file's structure.
4. Modification time — the timestamp reflects the last time a person edited the document, not the last time a workflow ran near it.

Any one of these drifting is a finding waiting to happen. A file ID that changed means something recreated the document instead of leaving it alone. A modification time that moved on a day nobody touched the file means a process wrote to it, even if the content looks identical afterward.

How you build against working copies, not originals

The architectural answer is simple to state and easy to get wrong in practice: the automation should never need write access to the document under review. It needs read access to know what exists, and write access only to the records that describe that document — the register row, the amendment entry, the distribution matrix, the retention date. The source document sits outside the blast radius entirely.

Concretely, the workflow engine's job is to react to a human decision — a reviewer's mark, an approver's sign-off — and translate that decision into entries in systems the automation owns: a Google Sheets register, an activity log, a folder move that mirrors lifecycle state. It is never the tool doing the editing, converting, or re-saving of the controlled document. If a document needs a new revision, a person creates that revision the way your SOP already says they should. The automation's job starts after that file exists, not before.

This is the same boundary covered in what ISO automation actually means: the system executes the clerical consequences of a decision, it doesn't touch the substance of the thing being decided on, and the document file itself is part of that substance, not the clerical layer.

What "verified unchanged" actually looks like

Here is what that guarantee looked like when we tested it, not described it, on our reference build for a Thai manufacturer, ISO 9001:2015 certified across two sites.

The build touched five original source documents belonging to that manufacturer's document-control process. After the automation went live and ran through its full lifecycle — new document, revision, cancellation, controlled copy, uncontrolled copy — all five were checked against their pre-build state: file ID, file name, format, and modification time. All five came back unchanged.

That's not a claim about intent. It's a comparison you can run yourself, on your own documents, with your own tooling. The automation preserved the four human decision gates already in the manufacturer's SOP: a reviewer marking the paper change-request form, an approver checking content adequacy, a combined final gate completing master sign-off across internal and external documents. None of those gates involve the automation opening the source file. They involve people making a call, and the system picking up the outcome afterward.

What changes, and what never does

The last row matters as much as the first. A build that respects your originals but quietly breaks something else running on the same automation tenant hasn't actually respected your operation — it's just moved the blast radius somewhere you weren't looking. Only after that final human sign-off does the system act, writing the eight fields a document controller previously retyped by hand into the register and master list, never into the source document.

What this protects you from

Most of the risk in bringing automation into document control isn't that it fails loudly. It's that it succeeds quietly at the wrong thing: converting a file format during a workflow run, leaving a timestamp that doesn't match your SOP, touching a document nobody meant for it to touch. Any of those, discovered at audit, costs more credibility than the automation ever saved in time.

The originals-untouched guarantee closes that gap. It isn't a feature you configure. It's a property of how the system is scoped from the start: read from the document, write to the records that describe it, stay out of the file itself.