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.
- File ID — the document's underlying identifier in your storage system is unchanged. It wasn't deleted and recreated under the same name.
- File name — no silent renaming, no suffixes appended, no versioning artifacts left behind by the automation itself.
- File format — a
.docxstays a.docx. Nothing gets converted, flattened, or re-saved through an intermediate tool that changes the file's structure. - 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
| Layer | What the automation touches | Verified after build |
|---|---|---|
| Source document | Never opened, edited, renamed, or re-saved | File ID, name, format, modification time unchanged |
| Register / master list | Written to after human sign-off | Row added, not the source file |
| Activity log | Written to for every automated action | Individually logged, timestamped |
| Drive folder state | Mirrors lifecycle when a person moves the file | Automation reacts, doesn't initiate the move |
| Other tenant workflows | Not touched by this build at all | 51 pre-existing unrelated workflows checked and unchanged |
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.
FAQ
What does "originals-untouched" actually mean in practice?
The automation never opens, edits, renames, or re-saves your source documents. It reads what's there and writes only to the registers, logs, and folders it owns.
How is this verified, rather than just claimed?
By comparing file ID, file name, format, and modification time before and after the build runs, on the actual documents involved. On our reference build, all five original source documents came back identical on every measure.
Does the automation ever need to edit the document itself?
No. Creating or revising the document is a human action under your existing SOP. The automation's role starts after that file exists, translating the human decision into register entries, not editing the file.
What happens to documents when their status changes?
Lifecycle state is mirrored through folder location, not through editing the file. Moving a document between folders is a human decision the automation reacts to. It doesn't touch the document's content, name, or format when it does.
Could an automation build break other things while leaving my documents alone?
It shouldn't, and that's checkable too. On our reference build, all 51 pre-existing unrelated workflows on the same automation tenant were verified unchanged after go-live.
If you want to see exactly how file-level verification worked on a real build rather than take the guarantee on faith, see the build record. 1% EVO builds this against your own documents and hands over a system you own outright, with no vendor lock-in.