Documents as Code.
Technical writers made this move a decade ago: documentation as plain text in version control, built and checked by the same CI as the product. Business documents are the harder, more valuable version of the same idea.
The docs-as-code movement.
Through the 2010s, documentation teams walked away from binary formats and CMS silos. Docs became Markdown next to the code, changes became pull requests, CI caught broken links and style violations, and the published site became a build output. Anne Gentle’s Docs Like Code put a name on the practice in 2016, and large documentation platforms run this way today.
The movement proved that writing survives contact with engineering tooling, and that writers benefit from it: reviewable changes, real history, and a publish pipeline nobody operates by hand.
Business documents raise the stakes.
A tutorial that goes stale wastes a reader’s afternoon. A business document that goes stale misleads a decision: charters carry objectives and spending authority, requirements carry commitments to build, risk registers carry known dangers and their owners, and approvals carry accountability.
That is why checking business documents means more than linting prose. Whether a sentence is well-formed matters less than whether the requirement it states traces to a business reason, is verified by a test, and still passes the criteria it was approved against.
What structural validation takes.
The reference approach gives every document kind a machine-checkable shape, so a validator can treat a charter the way a test suite treats a module.
Judgment stays prose. The objective’s wording, the mitigation’s reasoning, and the lessons in a review are written by people; the grammar covers identity and claims so the machine can hold them steady.