Content Governance: 3 Tests a Rule Must Pass

Every regulated publisher I've worked with owns the same two documents. There's a style and compliance guide, long, competent, written by somebody who has since left. And there's an incident log, which is the record of things that went out and shouldn't have.

The documents are rarely wrong. That's the uncomfortable part. You read the incident, you go back to the guide, and there's the rule on page eleven, correctly stated, in bold. Nobody failed to know it. Nothing stood between a writer at four o'clock on a Friday and the publish button.

So the organisation improves the document. Adds a section, runs a training, bolds the important part. Six months later there's a fresh entry in the incident log and the same meeting happens again, with different people, about a rule that was already written down.

Prose Cannot Fail a Build

That loop is what content governance exists to break, and the reason it keeps failing is that most organisations have built the documentation half and none of the enforcement half. What follows is the enforcement half. What makes a rule real, which rules can be made real, and how to find out in an afternoon whether the ones you've got would stop anything at all.

A style guide describes intent. A control stops the thing happening. They're different objects, and in regulated markets telling them apart is most of the job. The phrase content governance gets stuck on both, which is a big part of why the distinction goes missing.

An auditor doesn't ask whether your team knows the rule. They ask what happens when somebody doesn't follow it. If the honest answer is "an editor would probably catch it", you haven't got a control. You've got a hope with a headcount attached.

The test for whether a rule is real: can it fail? If nothing breaks when the rule is broken, the rule is advice.

Why This Scales So Badly

Every new market adds rules. Every new rule adds review load. Review load is human attention, human attention is the most expensive and least reliable thing in the system, and it degrades exactly when volume peaks.

Which is to say at launch, when the regulator is most likely to be looking and the people who wrote the standard are busiest doing something else. The failure is structural rather than cultural, and no amount of training touches it.

The 3 Tests a Rule Must Pass

Take any rule in your content governance documentation and run it through these three. A rule that fails any one of them is a document, whatever the header says.

1. Does it run before publication? A nightly audit tells you what you already published wrongly. That is a report, not a control, and the difference is whether the reader saw it.
2. Does it block? A warning is a style guide with extra steps. If the pipeline continues after the rule fires, the rule is advisory and will be treated accordingly by the third person who meets it at five o'clock.
3. Is it scoped to what changed? A gate that blocks an internal-link fix because of prose written two years ago is not protecting anything. It is stopping work, and it will be switched off inside a month.

Most governance programmes I've inherited pass the first, fail the second, and have never thought about the third. And the third is what kills them, because a control somebody disabled is worse than no control at all. It still shows up on the compliance register as present.

Move the Rule Into the Pipeline

The alternative is unglamorous. Take each rule that carries legal consequence and ask one question. Can this be checked mechanically? A surprising number can.

Jurisdictional restrictions can. If a page is scoped to Ontario, a validator can assert that no bonus or promotional inducement appears anywhere in the body, because the provincial regulator prohibits it and the check is structural rather than interpretive.

Disclosure requirements can. Mandatory blocks, age statements, operator licence references, links to support services. All of those are presence checks, and a presence check is trivial to automate and impossible to forget.

What Still Needs an Editor

Some rules can't be automated, and pretending otherwise is its own failure. Whether a review is fair. Whether a comparison misleads by leaving something out. Whether a piece of copy is technically accurate and practically deceptive. Those need a person.

The point of automating the mechanical checks isn't to remove the editor. It's to stop spending their attention on things a script does better, so there's some left for the things only they can do, which are also the things that actually get you into trouble.

What Can Be Mechanised, and What Cannot

The top half is where a script earns its place. The bottom half is what the hours freed by the top half should be spent on.

How to Build One

The order matters more than the tooling, and getting it wrong is why most attempts stall in month two. Here's the sequence I use.

1. Read the incident log first. Not the style guide. The log tells you which rules have actually been broken, and those are the ones worth automating. Everything else is speculative.
2. Write the rules that can fail. For each incident, state the rule as an assertion a machine could evaluate. If you cannot phrase it that way, it belongs with the editor and should be labelled as such rather than pretended into the automated set.
3. Build the cheapest possible check. A twenty-line script that catches the top three failure types beats a platform evaluation that takes a quarter. Ship something that blocks this week.
4. Wire it in before publication, not after. This is the step teams skip because post-hoc auditing is easier to retrofit, and it is the step that decides whether you have a control.
5. Scope it to the diff. Check what the edit touched. Report pre-existing problems separately, on their own schedule, as their own piece of work.
6. Add a rule every time something goes wrong. This is what makes the system compound. Every incident becomes a line in a file, and the same failure cannot recur.

Step six is the whole return on the exercise. A style guide gets worse with age because it piles up rules nobody reads. A checked standard gets better with age, because every addition is enforced from the moment it lands.

What Actually Goes in the Standard

The usual objection at this point is that it all sounds abstract, so here's the contents page of a real one. Four files, each doing a job the others can't.

The Voice and Pattern Rules

The longest file, because it carries the most rules. Banned words and phrases, structural patterns that signal templated writing, punctuation conventions, the voice the brand uses and the voice it doesn't, and the numeric bands that describe healthy prose. Sentence length variance, reading ease, paragraph density.

Most of that is mechanically checkable, which is why it's written in that form. A rule phrased as "write naturally" can't be enforced by anything. A rule phrased as "average sentence length between fourteen and twenty-two words" can be enforced by four lines of code, and it means something close enough to the first version to be worth the trade.

The Fact Discipline

Separate, because it fails differently. What counts as a source, and in what order. When a claim needs two independent sources rather than one. Which claim types fail safe, meaning they get dropped rather than published, when nobody can verify them in the same working session.

This file also carries the volatility ratings. Which facts need re-checking every thirty days, which every quarter, and which get settled once and never revisited. Without that, a standard quietly rots into a set of claims that were true when somebody wrote them.

The Fix Protocol

Repairing a live page is a different job from writing a new one and fails in different places, so it gets its own document. What order to work in, what to verify before touching anything, what to re-verify afterwards, and the explicit rule that a fix isn't done until somebody has confirmed it on the rendered page rather than in the file they edited.

The Site Brief

Short, and the one people forget. What this property is, who reads it, what's already settled and can't be reopened, and the specific traps that have already caused a problem once. Every entry in it exists because something went wrong.

Splitting them matters more than it sounds. One monolithic guide gets read once, at induction, by somebody who then works from memory for two years. Four short files with distinct jobs actually get opened, because you know which one holds the answer.

One Rule, End to End

Following one rule through the whole system makes the argument better than any amount of theory, so here's one that came out of a real incident.

A page went out for a market where promotional inducements are banned in advertising, carrying a bonus offer in the body copy. Nobody was careless. The writer had worked three other markets that week where the same offer was mandatory, the reviewer read for accuracy and the offer was accurate, and the rule banning it sat correctly stated in a compliance document both of them had read at some point during onboarding several months earlier.

What the Old Response Would Have Been

Circulate a reminder. Add a line to the induction deck. Ask reviewers to pay particular attention to market-specific promotional rules. Every one of those depends on a human remembering something at the exact moment they're busiest, which is the condition that produced the failure in the first place.

What Went In Instead

An assertion. On any page in the restricted market set, the body must contain no promotional inducement, matched against an explicit list of terms drawn from the regulator's own language. It runs before publication, it fails the build rather than warning, and it's scoped to the blocks the current edit touched.

Writing it took about twenty minutes. It's fired several times since, always on a page where somebody competent was moving fast between markets, and it has never once been the subject of a meeting.

The Part Worth Noticing

The rule didn't get better. It was correctly stated in the document the whole time. What changed is that enforcement stopped depending on somebody's memory and started depending on nothing at all, and that shift is the whole discipline in one example.

How to Audit Your Own in an Afternoon

You can find out whether your content governance is real without hiring anybody, and the exercise is uncomfortable in a productive way. Five steps, half a day.

1. Pull the last ten incidents. For each one, find the rule in your documentation that already covered it. Count how many were covered. In every operation I have audited the answer has been most of them, which settles the knowledge-versus-enforcement question immediately.
2. Pick your three most important rules and ask what happens mechanically when somebody breaks one. If the answer describes a person noticing, write "no control" next to it.
3. Count the blocks. Across the last hundred published pieces, how many were stopped at each review stage? A stage that has never stopped anything is not a stage.
4. Try to break it deliberately. Take a draft, insert a clear breach of your most important rule, and push it through the normal process. Tell one person, so it does not actually publish. What happens next is your real answer.
5. Time the recovery. When something does go out wrong, how long between publication and someone knowing? If the answer is "when a customer told us", your detection is external and your governance is nominal.

Step four is the one people resist and the only one that gives you certainty. Everything before it is guesswork about a system nobody has tested, and a control that's never been exercised is a claim rather than a fact.

What a Good Result Looks Like

The deliberate breach gets stopped, before publication, by something automatic, with a message naming the rule. Nobody has to interpret anything and nobody calls a meeting. The time between the breach going in and something catching it should be measured in seconds.

A merely acceptable result is a human catching it at review. That's a control, and it's the one that degrades under volume, so treat it as a finding rather than a pass.

Why Content Governance Programmes Fail

Four failure modes, and I've watched every one of them at close range.

The Gate Nobody Scoped

Covered above, and the most common by a distance. A gate that blocks unrelated work gets permission to be bypassed, then gets bypassed by default, then gets deleted in a tidy-up eighteen months later by somebody who reasonably assumes it was dead code.

The Platform Bought Instead of a Decision Made

A content governance platform can enforce a rule you've written. It can't decide what the rule is, and that decision is the expensive part. Teams buy the platform to dodge the decision, then find the platform asking them the same question back with a licence fee attached.

The Standard Nobody Owns

A rulebook with no named owner goes out of date at exactly the speed the market moves. In regulated verticals that's fast, and a stale rule enforced mechanically is worse than no rule, because it manufactures confidence nobody has earned.

The Review That Was Always Theatre

Sign-off by a person with no authority to say no isn't review. If legal has never once blocked a piece, either your copy is remarkable or the step is decorative, and the compliance register records it as a control either way.

But this one's easy to test and almost nobody does. Pull the last hundred pieces and count how many got stopped at each review stage. A stage with a zero next to it is either unnecessary or broken, and both answers are worth having.

The AI Part

Everything above predates the current tooling and would be worth doing without it. But AI changes the arithmetic in one specific way. It removes the natural rate limit that used to protect you.

When a team could produce eight pieces a week, editorial review scaled fine. When the same team can produce eighty, review becomes the bottleneck, and the pressure to clear that bottleneck lands on exactly the checks keeping you out of trouble. Organisations don't decide to lower their standards. They decide to go faster, and the standard is what gives.

Which Cuts Both Ways

The same tooling that puts the volume up also makes the checking free. A rule written as a script runs on eighty pieces as cheaply as on eight, which makes governance the one part of the operation that scales without costing anything.

That's the argument for doing this now rather than later. The volume is arriving whether the controls do or not, and ungoverned generation produces exactly the output an auditor is trained to find.

So the interesting question about AI in regulated publishing isn't what it can write. It's what you've built to catch it. A content operation with generation and no gates isn't a modern content operation. It's the old one with the brakes off.

Questions I Get Asked

What Is Content Governance, Exactly?

The set of rules deciding what can be published, plus the mechanism that enforces them. Most organisations have the first half and call it governance. The enforcement half is what makes the term mean anything.

Do I Need a Platform?

Not to start, and buying one first is the classic mistake. Write the rules, build the cheapest check that blocks, and find out what you actually need. A platform bought before you know the answer is an expensive way of putting the decision off.

Who Should Own the Standard?

One named person with the authority to say no, sitting in editorial rather than legal. Legal defines the constraint, editorial encodes it, and if nobody's named it belongs to nobody inside a quarter.

How Long Does This Take to Set Up?

A first version that blocks on the three most common failures takes a week. The full standard takes as long as the decisions take, which is the honest answer. The writing is fast. The agreeing is slow.

What If Our Rules Are Genuinely Subjective?

Then label them subjective and send them to a person, which is a perfectly good outcome rather than a failure. The damage comes from treating a judgement call as though it were automated, because then nobody's doing it at all.

Does This Work Outside Regulated Industries?

Yes, though the stakes change the sums. Outside regulated markets a bad page costs credibility rather than a penalty, so the same mechanism is worth building with less rigour. The three tests apply unchanged.

What If Legal Will Not Let Us Automate Anything?

Their objection is to automated judgement rather than automated checking, and those are two different proposals. Nobody's suggesting a script decides whether a comparison is fair. Present content governance as a machine enforcing the decisions legal has already made and the objection tends to evaporate in the same meeting.

How Do We Stop the Standard Going Stale?

Attach it to the incident log rather than to a review calendar. A quarterly review of a document nobody has consulted produces cosmetic edits. A rule added the week something breaks produces a standard that tracks reality, and the log tells you when that is.

Can This Coexist With Freelancers and Agencies?

It works better with them than without. A written standard is the most useful thing you can hand an external supplier, and running their deliveries through the same checks tells you inside a month which suppliers are worth keeping. That is a separate argument I have made at length.

What It Costs

Three inputs, and being honest about them is the difference between a plan and a pitch.

The decisions come first and cost the most, in the sense that they consume senior attention rather than budget. Somebody has to say what the rules are, and where the rules are genuinely contested that conversation is slow because it should be.

Then the Writing, Which Is Fast

A standard covering the top twenty failure types is a day's work once the decisions exist, and it is a day rather than a fortnight precisely because the hard part already happened. A team that finds this stage slow has skipped the previous one and is making the decisions inside the document, which is the wrong place for them and the reason the draft keeps stalling.

Then the checking, which is smaller than people expect. The script behind this site is 124 lines and it enforces an eleven-thousand-word standard. Most of it came together in an afternoon and it grows a few lines at a time whenever something new goes wrong.

Against What It Saves

One avoided regulatory incident pays for the entire exercise several times over, and that is before counting the editorial hours currently spent on checks a machine does better. The difficulty is that avoided incidents are invisible, which makes this a hard thing to build a business case for and an easy thing to regret not building. Nobody gets promoted for the breach that did not happen.

The Objection Worth Answering

A reasonable person reads all of this and says: our content is not formulaic enough to check mechanically, and a system of assertions will flatten the writing into something that passes tests and says nothing.

It is a real risk and I have watched it happen. A standard applied without judgement produces prose that clears every band and reads like a form, which is a failure mode with its own article. The answer is not to abandon the checks. It is to write them as a floor rather than a target, and to keep one rule above all the others saying that no score may override a fact or wreck a sentence that needed to be that way.

Mechanical Checks Are Not the Standard

The distinction that resolves it: the checks are a subset of the standard, not the whole of it. They catch the failures that are cheap to describe and expensive to miss, and they say nothing about whether the piece is any good.

A team that mistakes passing for succeeding will produce exactly the flattened output the objection predicts. That is a management failure rather than a tooling one, and the fix is to keep an editor whose job is explicitly the half no script touches.

Where to Start Tomorrow

Open your incident log and your style guide side by side. For every incident, find the rule that already covered it, and there will be one for most of them. That exercise takes an hour and it settles the argument about whether your problem is knowledge or enforcement.

Then take the three most frequent failures and write a check that blocks them before publication. Not a report, not a warning, and not a training session. Something that stops the page going out, scoped to the part of the page that changed.

And Then Leave It Alone for a Month

Resist extending it. The temptation after the first three checks work is to encode everything, which produces a gate so broad that it blocks unrelated work and gets switched off. Let it run on three rules, see what it catches, and add the fourth when an incident asks for it.

Content governance built that way survives, because every rule in it can point at the thing it exists to prevent. Built the other way, as a comprehensive framework designed in advance, it becomes another long document nobody reads, which is where this article started.