Controlled documents, from draft to retirement.
DocumentSynth governs the whole lifecycle — review, approval, electronic signature, effectivity, revision and retention — so you can show which version was in force on any date, and who approved it.
The difference
Control the document, not just the file.
File storage keeps bytes safe. Controlled-document management keeps the record correct — which version is in force, who decided, and what happened.
File storage
- A file has a name and a folder
- Anyone with access can overwrite it
- The newest copy wins, approved or not
- History is whatever the file system kept
- Approval happened in an email thread
Controlled documents
- A document has a number, a type and an owner
- A revision creates a version; it never edits one
- One version is effective; the rest are superseded
- Every state change is an append-only audit event
- Approval and signature are recorded acts, bound to a version
Create to retire
The lifecycle stays connected.
Each step knows the version it applied to. That connection is what makes the history worth reading — and it is why a revision can never quietly become a different document.
Controlled document lifecycle
7 steps in the build, 1 plannedOne document, and one version travelling through the middle of the sequence. The versions before it are kept underneath rather than replaced.
- SOP-0001043.2Effective
- 3.1Superseded
- 3.0Superseded
The record as it stands after step 06. Steps 02 to 06 all acted on 3.2, which is the run marked in the sequence beside this.
- Accent run
- Steps 02 to 06: the 5 that act on 3.2
- Dashed
- Planned. Not in the build yet
- 01
CreateAvailable
A numbered document of a type its organization defines.
Effect on the version: Opens version 1.0, in draft
- 02
ReviseAvailable
A revision adds a version. It never edits the one below it.
Effect on the version: 3.1 stays in force; 3.2 opens in draft
- 03
ReviewAvailable
Assigned as tasks, completed by named reviewers.
Effect on the version: Reviews are recorded against 3.2
- 04
ApproveAvailable
A separate decision with separate authorization.
Effect on the version: Approval is recorded against 3.2
- 05
SignAvailable
Re-authentication at the moment of signing; bound to the version.
Effect on the version: The signature binds to 3.2 and to nothing else
- 06
EffectiveAvailable
One version is in force; the previous is superseded.
Effect on the version: 3.2 in force; 3.1 superseded, and kept
- 07
TrainingPlanned
Will assign training against the version in force and record completion.
Effect on the version: Will follow the version in force
- 08
RetireAvailable
Withdrawn with a reason, and the record is kept.
Effect on the version: No version in force; every version retained
Version numbers are the same synthetic document shown elsewhere on this page. The sequence is the product’s: steps 02 through 06 act on one version, and nothing in them edits the version beneath it.
One version is in force. The others are still there.
A revision does not edit the document. It creates the next version and supersedes the one before it, so nothing is ever overwritten.
Which means “which version were we working to in March 2025?” has an answer you can point at, three years after the fact, in front of an inspector. Read it off the register: 3.0.
| Version | Status | Effective | Superseded |
|---|---|---|---|
| 3.2 | Effective | 2026-03-12 | — |
| 3.1 | Superseded | 2025-08-04 | 2026-03-12 |
| 3.0 | Superseded | 2024-11-19 | 2025-08-04 |
Illustrative data for the same synthetic document shown below. One version is in force at a time; the dates are contiguous, because there is never a gap during which no version applies.
The record
Every important action has a history.
Each state change writes an append-only event as it happens, hash-chained to the one before it. There is no second, editable table that could disagree with it — and no way to remove a row from the middle without every hash after it ceasing to match.
| # | Version | Action | Actor | Recorded | Chain |
|---|---|---|---|---|---|
| 19 | 3.1 | Version superseded | System | 2026-03-12 14:02:19Z | 22e99b89b337 |
| 18 | 3.2 | Version made effective | Quality Manager | 2026-03-12 14:02:19Z | d633dd22e99b |
| 17 | 3.2 | Electronic signature applied (meaning: approval) | Quality Manager | 2026-03-12 14:01:02Z | b1e03cd633dd |
| 16 | 3.2 | Approval recorded | Quality Manager | 2026-03-12 13:58:44Z | e6613eb1e03c |
| 15 | 3.2 | Review completed | Process Owner | 2026-03-12 11:20:07Z | 275f6ee6613e |
| 14 | 3.2 | Version created | Document Author | 2026-03-12 09:05:31Z | ab7b90275f6e |
Illustrative data — though the chain is real. Each hash is computed over the event before it, so the left value on any row is the right value of the row beneath it. Timestamps are stored in UTC and shown to each reader in their organization’s configured timezone. DocumentSynth records the events; whether a given record satisfies a particular regulation is an assessment each organization makes for itself.
Who it is for
Built for organizations with controlled work.
Wherever being able to prove which version was in force — and who approved it — is part of the job. Every one of these is a stack: one version in force, and every version before it kept underneath.
Controlled document classes
4 classes, one modelThe model does not change with the class. One version is effective, the versions before it are kept underneath it, and each class has a question it has to be able to answer.
- SOP-0001043.2Effective
- 3.1Superseded
- 3.0Superseded
Effective is the version in force. One stack, four classes: whichever class a document belongs to, this is how the product holds it.
Standard operating procedures
The procedure people are expected to follow, in the version that is currently in force.
Has to answerWhich revision was in force on the day the work was done?
Policies
Approved, signed, and traceable to the decision that put them in place.
Has to answerWho approved this, and what were they authorized to approve?
Quality documents
Specifications, forms and records where the version matters as much as the content.
Has to answerWas this the current template at the moment it was filled in?
Controlled work instructions
Step-level detail that has to stay aligned with the procedure above it.
Has to answerDoes this still match the version of the procedure it sits under?
Illustrative data for the same synthetic document shown elsewhere on this page. The classes are document classes, not customers — DocumentSynth is not generally available and there are no customers to name.