The validated core
Document control an auditor can take apart
Quality-management software has to be validated itself, so the core is deliberately small and slow-moving. Everything below is built to be examined — by a certification body, by a customer's supplier audit, by anyone who asks how you know.
01
Controlled documents & revisions
Numbering · revisions · effectivity
A document's life is an explicit, audited state machine — not a status field. The transition that matters most is automatic and atomic: when a revision becomes effective, its predecessor is superseded and withdrawn in the same event. At no instant are two revisions of the same document effective, and no point of use is left pointing at the old one.
- Configurable numbering schemes per site or document type
- Effectivity dates, not manual status changes
- Automatic withdrawal of the superseded revision
- Draft, review, approved, effective, superseded, archived
- Retention clocks and legal hold
- Clause mapping to ISO 9001 and API Spec Q1
02
E-signatures that survive scrutiny
Step-up re-authentication at the moment of signing
A signature is only worth what it binds. Doqumus binds four things at once: who signed, when they last proved who they were, what the signature meant (prepared, reviewed, approved, acknowledged) and the exact bytes they were signing. Executed signatures are never altered or detached — a mistake is corrected by a superseding record that shows both.
- Re-authentication forced at signing, not session reuse
- Authentication time and assurance level recorded
- Signature meaning captured explicitly
- Hash of the signed content bound into the event
- Corrections supersede — signatures are never edited
- No third party inside the validation boundary
03
Append-only, hash-chained audit trail
Anchored monthly to write-once storage
The event log is the source of truth for regulated state. Document status, signature validity and training completion are projections of it — always derivable, never authoritative on their own. Auditors can read the events themselves, not just verify that a hash matched.
Audit trail · 2026-08 partition
- #00412Revision approved9c1f…04ab
- #00413Signature executeda70e…5d12
- #00414Revision effective2b88…ff90
- #00415Predecessor withdrawnd415…7c33
Month head anchored · WORM
One value, stored where it cannot be changed. Check it and the whole month is proven untampered.
Each digest covers the one before it. Change any event and every digest after it stops matching — including the anchored head.
04
Read-and-acknowledge that proves training
Obligations raised by effectivity, not by reminder
“Everyone has been trained on the current revision” is a question with a precise answer, and it is a projection of acknowledgement events rather than a checkbox. When a document changes, the people it applies to are asked again — automatically, against that revision.
- Obligations created per role when a revision goes effective
- Acknowledgement binds person, revision and timestamp
- A new revision reopens the obligation cycle
- Prior acknowledgements marked against the superseded revision
- Shop-floor friendly on tablets and shared terminals
- Every person who needs an account has one — no seat licences
05
Immutable, content-addressed files
The bytes that were approved
A revision points at a hash, and the stored bytes hash to that value. Years later, the file an auditor downloads is provably the file that was signed — not a re-render, not a copy someone replaced.
- Every revision stored by content hash
- Write-once object storage with immutability policies
- Per-tenant encryption keys
- Deduplication within a tenant, never across tenants
06
A link graph, not a pile of records
Traceability · impact · evidence
Any controlled item or record can be related to any other: a revision to an NCR, an NCR to a CAPA, a CAPA to its effectiveness verification, a material certificate to the heat it came from. Relationships are first-class and audited, which is what makes traceability and impact analysis possible rather than manual.
- Typed links: affects, implements, caused-by, evidences, traces-to
- Links at document or revision level, explicitly
- Link creation and removal are audit-trail events
- The substrate for change-impact analysis and evidence packs
Document lifecycle
Six states, one of them automatic
The transition from effective to superseded is the one that fails in practice everywhere else, so it is the one the system owns outright.
01
Draft
Authored, or drafted by AI and promoted through the door
02
In review
Routed automatically per the approval matrix
03
Approved
All required signatures recorded
04
Effective
Reaches its effectivity date — automatically
05
Superseded
Withdrawn from every point of use, in the same instant
06
Archived
Retention clock runs; unmodifiable, marked not current
Beyond documents
Records modules on the same foundation
Document control comes first because it is what the audit turns on. The record modules build on the same event log, the same signatures and the same link graph — they are not a separate product.
Nonconformance & CAPA
Training records
Calibration & equipment
Suppliers
Internal audit
Material traceability
Configuration, not forks
Your numbering, your approval matrix, your terminology — on one codebase
Record types, workflows, approval matrices and numbering schemes are version-controlled definitions that we author and maintain for you. There is no visual workflow builder to get lost in, and there is no customer-specific branch of the product — which is exactly why every customer keeps getting the improvements, and why the validation package stays meaningful.
Start by finding out what you actually have.
A free program you run on your own machine counts what is really on your shared drive: how many documents, how many are copies of each other, how much is scanned paper. It sends us nothing. Reading it together is the step after that, when you want it.