Explainer
Who's Allowed to Touch Clause 14?
The Gap
Policy by Politeness
On paper, the governance already exists: legal owns the liability clauses, engineering owns the technical chapters, and after the pens-down date nobody edits anything. In practice, the document is a Word file on a shared drive, and every one of those rules is enforced by politeness. Anyone with the file can edit anything in it; the freeze is a calendar entry; and when a late change surfaces after approval, the investigation runs on memory and email archaeology.
This isn't a people problem. It's a tooling gap: files have one permission — open or not — while responsibility in a real organization is divided by section, by phase, and by role. A workflow that can't express that division can only ask nicely.
The Mechanism
The Org Chart, Made Executable
In a structured system, the document is made of managed parts — which means permissions can attach where responsibility actually lives. The legal sections accept edits only from the legal role; everyone else sees them read-only with commenting open. The pens-down date is a workflow state that locks the version at the deadline; a genuine emergency goes through an authorized unlock that is itself recorded. And underneath it all runs an audit trail at the granularity of the change: who touched clause 14, when, in which version, under whose authority.
We've run this machinery for years for a national rules body whose documents carry legal force — where “who changed what” is a question regulators may ask with a deadline attached. But the pattern pays anywhere many hands touch one document: reviewers stop re-reading what couldn't have changed, owners stop guarding their sections by vigilance, and the guardrails that shape the content also fence who may shape it. Governance stops being hope with a style guide, and becomes a property of the system.
FAQ
Questions We Hear
What is role-based document editing?
Permissions that attach to parts of a document, not just the file. A policy manual might give the legal team exclusive edit rights over the liability sections, technical owners their own chapters, and everyone else comment-only access — enforced by the system at the level of sections and clauses. In a file-based workflow the equivalent 'rule' is an email asking people not to touch things, which works until it doesn't.
What is a pens-down date and why does it need enforcing?
It's the moment a document freezes for approval or publication — after which nothing may change. In shared-drive workflows pens-down is a request, and the classic failure is a well-meaning late edit that reopens review or, worse, ships unreviewed. In a structured system pens-down is a state: the workflow locks editing at the deadline, exceptions require an explicit unlock by someone authorized, and the unlock itself is recorded. The date holds because the software holds it.
What should an audit trail actually record?
Who changed what, when, in which version, and under what authority — at the granularity of the change, not the file. 'Document modified by J. Smith, Tuesday' is file-system metadata, not an audit trail. A real trail lets you ask: who edited this clause between review and publication? Who approved the exception to the freeze? For regulated publishers those are compliance questions with deadlines attached, and the trail is the difference between answering in minutes and reconstructing from email.
Doesn't all this control slow the work down?
It slows down exactly one thing: unauthorized changes. Everything else speeds up, because reviewers stop re-checking sections that couldn't have changed, legal stops re-reading chapters outside their scope, and nobody burns a week reconciling a late edit discovered after approval. Control that maps to how responsibility is actually divided isn't bureaucracy — it's the org chart made executable.
Get In Touch
Governance or Hope?
If your edit rules live in emails and your freezes live in calendars, the enforcement gap is real and fixable. We configure the roles with your editorial owners.