What Document Control does

Document Control manages the life of SOPs, work instructions, specifications, forms and policies so that only the current approved revision is in use, every change is reviewed, approved and signed, the affected people are trained, and the history is ready for an audit. It replaces the controlled-document tools a business usually pays for: MasterControl Documents, Veeva Vault QualityDocs, Qualio, Intelex Document Control and Ideagen, and also a SharePoint library used as a controlled library. The module specification cites market overviews of these platforms as its sources ^[6][7].

The word that matters is controlled. A procedure on a shared drive can be edited by anyone, copied into an email, printed and left in a binder, and nobody can say afterwards which version a person followed on a given day. A controlled document answers that question from the record.

What is in, and what is not

• In: document types, numbering, metadata and ownership; the revision lifecycle from draft to review to approval to effective to superseded to obsolete; review and approval routing with Part 11 e-signatures; periodic review, controlled distribution, read-and-understood and controlled print; training triggers to M07 on a new effective revision; a register of external documents such as standards and regulations.
• Out: uncontrolled wiki and knowledge content (M17, the internal knowledge variant); engineering drawings and CAD release (M14 PLM); and the change control decision workflow (M08). A revision can point at a change control record, but the decision to make the change is made in M08.

Ten capabilities in three tiers

Each capability carries a tier. MVP must exist for a business to cancel its incumbent tool with confidence. STD is parity with mainstream tools, what a buyer expects in a demo. BIC marks best-in-class differences, such as those made possible by AI. MVP and STD are required for the course; BIC is advanced work.

The standards, and what each one is used for

Types, numbers and ownership

Every document belongs to a document type (table doc_doc_type). The type sets the numbering prefix, the review period in months, whether training is required and in which mode (read and understood, a course, or none), and the approval route. The document inherits those rules, so a rule is changed once on the type and not on every document.

Each controlled document has an owner, a person in the spine's core_person, who is accountable for it, and may belong to a site. Its confidentiality is one of public, internal, confidential or restricted. A document number is unique in the business, and the number sequence issues it.

Nine tables on the shared spine

Every table in the module starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. The module has no people table, site list, role list or file store of its own: it points at core_person, core_site, core_job_role, core_attachment and core_e_signature. Its own tables share the prefix doc_.

The document header has a status of its own: draft, in_review, approved, effective, superseded or obsolete. Its confidentiality is public, internal, confidential or restricted. A distribution row names a person, a job role or both; a row for nobody would mean nothing.

The life of a revision

A document does not change; it gets revisions. Each revision has a label made of a major and a minor number. By the convention used in this course, 1.0 is the first effective revision, 1.1 is a small change and 2.0 a big one. Each revision carries the source file, a change summary, a pointer to the change control record if there is one, and a sha256: a fingerprint of the file, computed on the server, that changes completely if one byte of the file changes.

Because the revision cannot be changed after submission, redline compare is possible: the reviewer sees the exact difference between the effective revision and the one in review, and the change summary says why. An AI assistant can draft that summary from the redline, and flag conflicts with related documents, but a person approves what it writes.

Routes: serial, parallel and reject

Each document type carries an approval_route, a JSON list of steps. Every step has a number (step_no), a role and the reviewer. Steps with the same number run in parallel, and a step opens when every lower step is done, so one shape covers both serial and parallel routing. On submit, one doc_review_task is made for each step. Only the open step gets a due date.

{ "steps": [
  { "step_no": 1, "role": "reviewer" },
  { "step_no": 1, "role": "reviewer" },
  { "step_no": 2, "role": "approver" },
  { "step_no": 3, "role": "qa_approver" }
] }

A decision is approve, reject or comment. A reject must give a reason, enforced by the database: a check refuses a reject with empty comments. A rejected revision returns to draft and keeps its tasks as history: any task of that round still pending is closed, so it leaves the inbox. Resubmitting opens a new round, recorded in ext.round, and the inbox shows only the current round's tasks.

Signatures: name, time, meaning and a link

An approval is signed. 21 CFR Part 11 asks for three things about a signature ^[1]: section 11.50 says a signed record shows the printed name of the signer, the date and time, and the meaning of the signature (for example review or approval); section 11.70 says the signature is linked to its record so it cannot be copied to another. Section 11.10 asks for secure, time-stamped audit trails of changes.

The module meets them this way. At the moment of signing the person types their password again (re-authentication, so a screen left open cannot sign). The server writes a core_e_signature with the signer, the meaning, the record type and id, the date and time from the server's clock, and a record_hash equal to the revision's sha256. The screen shows the printed name, the date and time and the meaning beside the signature. The meaning is one of the words the spine's check constraint allows (authored, reviewed, approved, verified, performed, released, rejected, acknowledged); this module uses reviewed, approved and acknowledged, and puts the signer's role in the signature's comment, for example qa_approver: approved_for_withdrawal.

Training before effective

When a revision is approved, someone has to learn what changed. The document type says how: read and understood (the reader acknowledges the revision, signed with the meaning acknowledged), a course (an assignment in M07, Training and Competence), or none. The approval step expands the distribution: one doc_distribution row for each person who holds each job role mapped to the document. ack_required is true on those rows only for read and understood; for a course the M07 assignment is the training, and for none nothing is required. The rows for job roles are the mapping only and are never acknowledged. The domain event trn.assignment.completed, which the module consumes, tells it when a course is done. In this course the scheduler does not wait for the event: at the effective date it reads trn_assignment and trn_completion directly.

The scheduler then guards the effective date. It counts the required trainees against the ones who have finished: the acknowledged rows for read and understood, or the completed M07 assignments for a course. When nobody is required, the revision becomes effective on its effective date. If everyone has, in one transaction it marks the old revision superseded, marks the new one effective, sets effective_revision_id on the header, sets the next review date, and publishes doc.revision.superseded and doc.revision.effective. If anyone is missing, the revision stays approved and the owner gets an action item naming who.

Distribution, print and review

• Acknowledgement. Each distribution row records when the person acknowledged the revision and the signature they made. The read-and-understood list shows who has not.
• Controlled print. A controlled copy is made from the revision's PDF/A copy (the source may be a Word file, which cannot be stamped page by page) and stamped with CONTROLLED COPY, a copy number, the document number and the revision label, and a doc_controlled_print row records who printed it, when and where. A reader's ad-hoc print is stamped UNCONTROLLED COPY with the print time and writes no row. The stamp is made on the fly, so the stored file and its hash stay untouched.
• Reconciliation. When a revision is superseded, any controlled copy not yet reconciled is collected. The administrator marks each reconciled, setting reconciled_at and reconciled_by, and the list of copies still out is on the admin screen.
• Periodic review. The type sets how often a document is reviewed, for example every 24 months. Each effective revision has a pending doc_periodic_review. The owner completes it with an outcome: no_change (the next review is scheduled), revise (a new draft revision starts) or obsolete (the QA approver signs an approval marked approved_for_withdrawal, the revision is withdrawn and the document becomes obsolete). A review past its due date raises doc.review.overdue once, with an action item for the owner and, after a delay you set, for the QA approver.

Archive and prove it

For long-term keeping, each revision gets a PDF/A copy when it becomes effective. PDF/A is the family of PDF forms standardised as ISO 19005 for long-term preservation of electronic documents ^[1]. The copy is stored as a core_attachment, linked by pdfa_attachment_id, and its hash is kept with the source's hash. A free converter such as LibreOffice can render it, and a free validator such as veraPDF can check it; run them as a job in your own CI or on one computer. A paid conversion service is the other way, and its price is read from its own page before you choose it. Imported effective revisions get their copy in one run after the import, and the archive check reports an effective revision with no PDF/A copy separately from a hash that does not match.

How long records are kept is a separate decision. Take the period from your regulator, your customer contracts, or ISO 15489-1 ^[2] and the control of records in ISO 13485 ^[5] if they apply, and write which source set it. Do not guess a number.

Three KPIs and three tests

Count a small fixed seed by hand and make the KPIs on the administrator's setup page, /documents/admin, agree. If they differ, fix the query, not the count. In the lab seed, review cycle time is 7, 8 and 2 days for the three approvals, so the median is 7.

Moving from the old tool

Export the documents with their metadata and revision history (CSV plus the files). Historical revisions arrive as superseded, with their original effective dates; the current revision arrives as effective. Never re-sign history. Signatures made in the old tool are kept as text and as the tool's own signature report, not recreated, because a new signature would claim a decision nobody made. Imported effective revisions create no training assignments, or an import would assign every course at once. Store every file once and compute its sha256 while storing, and set the numbering so new documents continue after the highest old number. Run old and new side by side for at least a week, compare, cut over, and cancel the old subscription only after its final export is safe.