Change control was docs-as-code before Git
For eight years I wrote controlled documents for a vaccine manufacturing site: more than 100 of them, thousands of pages, every page subject to rules about how it could change. No document changed without a request. No change went live without named reviewers signing off against defined criteria. Every revision recorded who, when, and why, forever. Retired documents were stamped obsolete but never deleted.
Then I started working in Git, and the feeling was unmistakable. I had been doing docs-as-code the whole time. The pharmaceutical industry just calls it document control, runs it on heavier tooling, and enforces it with inspectors instead of merge checks.
The mapping
| Pharmaceutical document control | Docs-as-code equivalent |
|---|---|
| Document control system (single controlled source) | Git repository as the single source of truth |
| Draft or redline copy | Branch |
| Change request with justification | Pull request description, linked issue |
| Routed review with named approvers | Required reviewers, protected branch |
| Review criteria per document type | PR checklist, style guide enforced by lint |
| QA gate before issuance | CI: lint, link check, build must pass |
| Effective date and version number | Merge, tag, release |
| Controlled copies at point of use | Deployed site, always current |
| Revision history with reasons | Commit and PR history |
| Periodic review schedule | Scheduled CI runs catching rot and dead links |
| Obsolete stamp, never deletion | Deprecation notice, redirect, preserved history |
The mapping is not a metaphor. It is the same control objectives implemented twice: one current truth, reviewed changes, recorded reasons, recoverable history.
What pharma does better
Three disciplines from the regulated world transfer directly, and most documentation teams would feel them immediately.
Review is a named responsibility with criteria. A controlled document lists its reviewers by role, and each role checks defined things: technical accuracy, quality impact, regulatory fit. Nobody "approves" by scrolling. Docs teams that adopt this, even informally (this PR needs one SME for accuracy and one writer for style), stop shipping reviewed-in-name-only pages.
Every change answers "why" at the moment it happens. A change record without a justification is not a valid change record. Six months later, nobody wonders whether the timeout value changed for a reason or by accident. Commit messages and PR descriptions can carry the same weight, but only if the team treats "update docs" as the empty justification it is.
Single source of truth is enforced, not aspired to. In a controlled environment, an uncontrolled copy of a procedure is a finding, and people are trained to check the effective version before using it. The docs-as-code parallel is ruthless deletion of shadow copies: the wiki page that restates the README, the PDF export in a shared drive. One source, linked from everywhere, or the copies drift apart and disagree.
What Git does better
Honesty runs both ways; I would not rebuild document control on its legacy tooling by choice.
Diffs. Pharmaceutical review means reading a redline against the previous issue, often assembled by hand. git diff produces a perfect, line-level redline for free, every time. The first time I saw one, I thought about the hours of my life spent making them manually.
Cheap branches. In heavy document control, drafts are scarce and serialized because the workflow makes them expensive. Branches cost nothing, so exploration costs nothing, and two rewrites can proceed at once without a collision.
Automation as a reviewer. A style guide that depends on human vigilance is a suggestion. Vale enforcing a style guide on every pull request is a standard. Machines catch the mechanical failures, so human review can spend itself on meaning, which is the part machines still cannot judge.
Speed as a feature. Document control optimizes for control and pays in latency; a typo fix can take a week to issue. Docs-as-code keeps the gates but collapses the ceremony: the same review rigor can clear in an hour when the diff is one line.
The synthesis
The teams that get documentation right, in my experience from both sides, run the pharmaceutical control objectives on the software toolchain: one source of truth, named review with criteria, reasons attached to changes, history that never lies, and gates that machines enforce so humans can think.
That is what this site is. Every page you are reading moved through a pull request, was linted against a published style guide, had its links checked, and deployed only after the gates passed. Nobody made me build it that way.
I did not have to learn documentation rigor when I moved to docs-as-code. I had to learn YAML.