a rule is not real until it has a check

I have a style rule at my company. No em-dashes in anything that goes out to a customer. The reasoning is not complicated. That punctuation mark renders inconsistently once text gets copied into an email, a chat message, or a plain-text field, so a sentence that looked fine in the document I wrote it in can turn into something broken by the time a customer actually sees it.

The rule had been written down for months. My team knew about it. I had even built an automated check that scanned for the mark and stopped the work when it found one. I considered that the end of the story.

the violation that shipped anyway

Then an em-dash showed up in copy that shipped straight to a customer.

I could have blamed the rule and moved on. Instead I went looking for the actual cause, and the answer was more useful, and more embarrassing, than a vague excuse would have been.

The rule was fine. The check was not everywhere the rule was supposed to be.

I had built the check to run against one slice of what we write, the internal process documents and planning files. It never ran against product copy, the actual words a customer reads on a screen. The rule covered everything we publish. The check covered a fraction of that. Nobody noticed the gap. I think that's for the same reason gaps like that tend to go unnoticed: a check that is silent looks identical to a check that was never needed.

a rule is not the same as its enforcement

That is the moment I stopped treating a rule and its enforcement as the same thing.

A rule that lives only in a document is a wish. At my company, people read it, nod, agree with it, and then drift, not out of bad faith but because a document has no power to stop anyone from doing anything. It just sits there being correct while the work moves on without it. The only way I have found to make a rule real is to build something that checks for the violation and stops the work, or at least flags it, the moment it shows up. If nothing enforces a rule, that rule is a preference I am hoping people remember on a busy day.

auditing every standard I had written

The question I ask now, whenever I write a new rule for my company, is not whether people understand it. It is what proves, automatically, that the rule was followed. If I cannot answer that question, I do not consider the rule finished. I consider it a draft of a rule.

Recently I went back through every standard I had written and asked exactly that. How we format writing across the company. The specific words we avoid in marketing copy because, from what I've seen, they sound like every other company's marketing copy. How commit messages get written when code changes. How project folders get organized so nothing gets lost six months later. Some of those already had a check behind them. A few had a check that only covered part of what the rule actually said, the same shape of gap that let the em-dash through. I closed those.

not every check works the same way

Not every check works the same way, and that difference matters. Some of them stop the work outright. If a banned word shows up somewhere it should not, nothing moves forward until it is fixed. Others only raise a flag and let the work continue, because the rule behind them is closer to a strong suggestion than a hard line, and I would rather live with an occasional ignored warning than a block that gets in the way of writing that was actually fine.

I want to be honest about where this stops working, because it does stop working somewhere. A check can tell me a banned word is present. It cannot tell me whether a sentence is actually clear, whether a piece of copy will land with the person reading it, or whether a decision behind a design was the right one. Those stay judgment calls. No check I build is going to make them for me, and I do not want one that tries. Automating the mechanical part of a rule does not replace judgment. It protects it, by making sure judgment gets spent on the parts of the work that actually need a person thinking, instead of getting burned re-catching the same forgettable mistake every time it shows up again.

what a clean check actually buys you

A clean result from a check does not mean the work is good. It means the floor is guaranteed. Once nobody has to remember to scan for the em-dash by hand, the actual attention that goes into whether a piece of writing works can go toward the writing itself, not toward proofreading for a rule that should have been automatic from the start.

That is the full shift for me. I used to think writing a rule down was most of the job. Writing it down is the easy half. A rule is not real until something checks for it everywhere the rule is supposed to apply, and it stays real only for as long as I keep asking where else it might not be checked yet.