Document control software
Document control software for organizations that have to prove it.
Document control is the practice of keeping a document’s current version, approval and history provable rather than assumed. This page is about what to require of a system that does it, and how DocumentSynth answers each requirement.
Why this becomes urgent
Uncontrolled documents fail quietly, and then all at once.
Nothing looks wrong until somebody asks a question the record cannot answer.
- Two people are working to different revisions of the same procedure, and both believe theirs is current.
- A document was approved in an email thread that has since left the company with the person who sent it.
- A signature is attached to the document rather than to a version, so it now applies to text the signer never read.
- An auditor asks which revision was in force on a date, and the honest answer is assembled from file timestamps and memory.
None of these are failures of diligence. They are what happens when the system storing the documents has no concept of a document being in force.
What to require
Eight things to ask any vendor, including this one.
The useful question is never whether a system displays something. It is whether the system permits the alternative. A vendor who answers “it is configured not to” is describing a policy; a vendor who answers “it cannot” is describing a control.
A document identity that survives its content
The testAsk what happens to a reference from a training record or another procedure when the document is revised. If the reference breaks, the number was really a filename.
DocumentSynthA document carries a number, a type its organization defines, and an owner. Revising the content does not change any of them, so a reference made years earlier still resolves.
Revisions that add versions instead of replacing them
The testAsk whether an approved version can be edited. Not whether the interface offers it — whether the system permits it at all.
DocumentSynthA revision adds a version; it never edits one. A version that has been signed is not altered afterwards, and the version it replaces is marked superseded rather than removed.
Review and approval as separate, attributable decisions
The testAsk whether reviewing and approving are the same permission. If one person can do both without that being a deliberate configuration, the distinction is cosmetic.
DocumentSynthReview and approval run as workflow on the document itself, assigned as tasks to named people. They are two decisions with distinct authorization, not one step with two labels.
Signatures bound to the exact version signed
The testAsk what a signature is attached to. A signature on a document rather than on a version is a signature on whatever that document later becomes.
DocumentSynthA signature records who signed, the exact version and its content hash, the meaning of the signature, the statement accepted, and how the signer authenticated. Signing requires re-authentication at that moment — an open session is not treated as consent.
One version in force, and a way to prove which
The testAsk what was effective on a date two years ago, and watch whether the answer is read from the record or reconstructed from it.
DocumentSynthOne version is effective and the rest are superseded, each carrying the date it took that state, and the database enforces that only one can be effective at a time. "Which version applied in March last year" is read off the register rather than reconstructed. A version becomes effective when its approval completes; scheduling a future date is not supported.
A history that was not written afterwards
The testAsk whether a row can be removed from the middle of the history, and whether anyone would be able to tell.
DocumentSynthEvery state change writes an append-only audit event as it happens, hash-chained to the one before it. There is no second, editable table that could disagree, and removing a row breaks every hash after it. The chain can be verified through the product.
Isolation you can describe to somebody who asks
The testAsk how the system decides which organization a request belongs to, and how many places enforce it.
DocumentSynthEach organization gets an isolated environment at its own address. Which environment a request belongs to is decided from that address before anyone is authenticated, and it is enforced again independently in the database.
Training tied to the version people were trained onPartly planned
The testAsk what happens to training records when a procedure is revised. This is where document control most often stops being real.
DocumentSynthDocumentSynth keeps the version history that training records have to attach to, and signatures are already bound to specific versions.
PlannedAssigning training to people and tracking their completion against an effective version is planned. It is marked planned on the plans table, and it is not in the product today.
The distinction that matters
Document management and document control are not the same purchase.
They look alike in a demonstration. They diverge the first time somebody has to prove something.
Document management software
- Stores, searches and shares files well
- Version history is a convenience for authors
- Approval is a workflow you can configure, or an email
- Permissions decide who can open a file
- The latest upload is the one people find
- History is what the platform happened to log
Document control software
- Manages documents whose current state has to be provable
- A version is a record; the previous one stays and is marked superseded
- Approval and signature are recorded acts, bound to a version
- Permissions decide who can move a document through its lifecycle
- One version is effective; the rest cannot be mistaken for it
- History is append-only evidence, written as things happen
Neither column is a criticism. A document management system that is doing its job is doing a different job, and most organizations need both — often the same team keeps general content in one and controlled documents in the other. What makes a document controlled goes into the distinction at length.
Regulated environments
Designed for work that gets inspected.
Pharmaceutical, biotechnology, clinical research and medical device organizations carry the heaviest version of this problem: the document is not the deliverable, the evidence is. Training has to attach to the version people were trained on, multi-site working multiplies the ways a superseded copy stays in circulation, and an inspector’s questions are about dates.
DocumentSynth implements the mechanisms those quality systems are built on: immutable versions, one effective version enforced in the database, review and approval as separately authorized decisions, signatures bound to the version and content hash that was signed, and an append-only, hash-chained audit history with a verification the product exposes.
To be exact about what that does and does not mean: DocumentSynth records the events. Whether a given record satisfies a particular regulation is an assessment each organization makes for itself, usually as part of its own validation activity. DocumentSynth is not sold as a certified, validated or pre-approved system, and no vendor can supply that on your behalf. Document control in pharmaceutical and clinical organizations covers the practical side.
Questions
What people ask before they shortlist.
- What is document control software?
- Software that manages documents whose current version, approval and history have to be provable rather than assumed. It differs from document management software in what it refuses to do: an approved version cannot be edited, a superseded version cannot be mistaken for the current one, and the history cannot be rewritten after the fact.
- How is it different from a shared drive or SharePoint?
- A shared drive can be organized well, and many are. What it cannot do is refuse — refuse to overwrite an approved version, refuse to let an unapproved revision become the copy people find, or refuse to lose the record of who decided what. Document control is mostly made of refusals.
- Does DocumentSynth support electronic signatures?
- Yes. A signature records the signer, the exact version and content hash, the meaning of the signature, the statement accepted and how the signer authenticated, and it requires re-authentication at the moment of signing rather than relying on an open session.
- Is DocumentSynth suitable for regulated environments?
- It is designed for them: the mechanisms it implements — immutable versions, attributable approval, signatures bound to a version, and an append-only hash-chained audit history — are the ones regulated quality systems are built on. DocumentSynth records the events. Whether a given record satisfies a particular regulation is an assessment each organization makes for itself, usually as part of its own validation activity.
- Does it handle training records?
- Not yet. Assigning training and tracking completion against an effective version is planned, and is marked planned on the plans table. What exists today is the part those records have to attach to: a version history where the version someone was trained on is still identifiable after the procedure has been revised.
- What does it cost?
- Pricing is not published yet. DocumentSynth is sold as one subscription for an organization, billed monthly, with capability levels rather than contract lengths — you can move up a level when you outgrow a limit, and nothing is sold as a separate add-on.
Next steps.
DocumentSynth is being prepared for availability and every request is reviewed by a person. Submitting the form does not create an environment or an account.