Rules Do Not Work. Guardrails Do.

I gave my AI one instruction. Dark text on white, never light gray, because the documents I produce get printed and read at a kitchen table. It reads that line at the start of every single session. It has never once argued with it.

Then it handed me a client document with gray body text, on the one page whose entire purpose was to be printed.

I caught it. I sent it back. It was fixed in four minutes. Then I did the arithmetic on what those four minutes actually cost, and the number is not four minutes. It is the time to spot it, the time to describe it, the time to check the fix, and the confidence I lose that anything else in the document is right. Nobody selling you an AI tool will tell you about that number.

The promise

Every course, every consultant and every tool vendor sells the same fix. Write better rules. Build a system prompt. Give the model a style guide, a brand sheet, a list of things never to do. The pitch is that once the rule is written down, the problem is handled.

I believed that. I have built a substantial library of rules over months of working this way. Brand colors. Writing standards. Which logo file is current. How documents get filed. Every one of them written in plain language, sitting in a file the tool loads before it does anything.

What actually happens

I asked my own AI to explain the failure, and the answer was more useful than another apology. A rule sitting in a memory file is context. It gets read at the start, and then it competes with everything else in front of the model at the moment it is producing work.

When it was writing the styling for that document, the immediate pattern was strong. Gray subheadings look refined on a screen. Every design reference it has ever seen agrees. My rule was one sentence read twenty minutes earlier. The local pattern won.

That is not laziness and it is not the model disagreeing with me. It is how the thing works. And once you understand it that way, the fix stops being “write the rule more forcefully” and becomes something else entirely.

Rules versus guardrails

Here is the distinction that changed how I work, and it is worth more than any prompt template you will ever be sold.

A rule is a fact you store. It is read, then it competes for attention, and it loses to whatever is directly in front of the model when the work is being produced.

A guardrail is a check that runs. It executes before anything ships, it fails loudly, and it does not care what anybody remembered twenty minutes ago.

I went back through one long working day and sorted every mistake by which kind of protection was supposed to catch it. The result was not close.

Everything caught before it reached me was caught by something that ran. A check that counted the images on a page and compared it against the images actually published, which found 137 missing. A check that added up the items in a gift package and compared the total against the one printed on the page. A check that counted records before and after a file operation and noticed one had gone astray.

Everything that got through to me was governed by a rule written in prose. The contrast rule. The rule about not using files from an archived folder. The rule about never reusing an image I had already rejected. All three were written down. All three were broken on the same day.

So we built the guardrail

I told my AI to stop writing rules and build the thing that checks. It now runs a pre-flight before anything is deployed or put in front of me. Nine checks. Every single one of them is a rule that was actually broken on real work, converted into something that executes.

Font colors too light to print. Punctuation that violates the writing standard. Any file loaded from an archived folder. Any referenced image that does not exist. Any asset I had previously rejected. Any package whose total does not equal the sum of its parts. Any pop-up that disagrees with the card it opened from. Missing letterhead. A broken app install.

If any check fails, the run stops. Not a warning. A stop.

Silent failures cost you money for months. Loud failures cost you an afternoon.

The part I did not expect

It flagged something that turned out to be fine. An image I had rejected as a category tile, which is still a real product the client sells and belongs in her catalog. The check was reading “rejected” too broadly.

That mattered more than the failures it caught. A guardrail that flags legitimate work gets switched off inside a week. So we made it precise: rejected as a feature image is a different thing from removed from the business entirely. It now knows the difference.

Then it flagged something neither of us could resolve, a question about whether a particular photograph belonged in one gallery but not another. That is a judgment call, and no script settles it. It surfaced the question and stopped. That is also correct behavior.

Then it happened to this article

I have a rule about American spelling. It has been in the system for months, and I have raised it more than once, in plain language, more than one way.

Reading the draft of this article, I found the word behaviour in the paragraph directly above. British spelling, in an American document, in the piece arguing that written rules do not hold. It reads correctly there now only because a person caught it, which is the whole problem.

So we ran the same kind of check we had just built for the client, this time against my own files. It found British spellings in 13 documents. Eight of them were in this article alone.

The rule was never the problem. It was clear, it was written down, and it was read at the start of every session. It was simply never checked against anything before the work went out.

Spelling is mechanical. A machine evaluates it without an opinion, which by the test in the next section means it never belonged in a rule in the first place. It is a scan now, and it runs before anything ships.

I am leaving this in rather than quietly correcting it, because it is the cleanest proof of the argument I have. The article about rules failing failed by its own rule.

Where the line sits

Not everything can be a guardrail, and pretending otherwise is its own trap.

Mechanical things belong in the check. Colors, fonts, punctuation, dead links, totals that must reconcile, files that must exist, assets that must not come back. Anything a machine can evaluate without an opinion.

Judgment stays with you. Whether a cake photograph is ugly. Whether a gift package reads like a birthday when it is supposed to read like a graduation. Whether the tone of a paragraph is right for the person receiving it. No script decides those, and you should not want one to.

That is not a limitation of the technology. That is the correct division of labor, and knowing which side of the line a problem sits on is most of the skill.

What to ask

If you take one thing from this, take the question. The next time you tell an AI system a rule, or somebody sells you a tool that promises to follow your brand standards, ask this:

If the answer is that the tool will remember, you have bought nothing. You have bought the feeling of having solved it, and you will keep paying for that feeling in corrections you make yourself, one at a time, forever.

If the answer is that it fails the build, refuses to publish, or stops before it reaches you, then you have bought something real.

The tool is genuinely capable. In a single day it rebuilt a task board from a live API, cut 57 megabytes of images down to under 2, found a bug that made a page unusable on a phone, and built the very guardrail that catches its own mistakes. That is real work and it is fast.

But capability and reliability are not the same purchase. Capability comes in the box. Reliability is something you have to build, and it is built out of checks that run, not rules that are remembered.