This is Issue #1 of Build a Business that Learns, focused on AI-powered business growth and automation.

AI related content not your cup of tea? Stop the Thursday AI newsletter.

You wrote the rule for your AI tool down.

You told the tool to use this rule. You told it again on Tuesday.

Thursday's draft came back without it.

So you corrected it a third time, and somewhere in the back of your head a small tally went up by one.

I did the same thing to myself last week. I want to show you the exact place my reasoning broke, because it is the place most competent people break.

I argued against building a system I needed

I was deciding whether one of my own repositories should carry a standing set of checks.

I said no.

The reasoning felt airtight. I spent decades as a software architect. I know every rule that repository has, because I wrote most of them. Adding a system to enforce rules I already know is bureaucracy.

Then I read the repository's own history.

Four superseded drafts of a sales page had reached the live site. Two pieces of forbidden markup had been shipping site-wide for months.

I knew every rule those breaks violated.

Not one of them was a knowledge gap.

The test I was using was the wrong test

"Can I already do this?" feels like the right question. It is not. It sorts on capability, and capability was never the thing that failed.

Here is the sort that works.

The gap	What it sounds like	What closes it
Capability	"I do not know how to do this"	Learning it
Consistency	"I know exactly how, and it still does not happen every time"	A standard that gets checked on every pass

Every one of my four was in the second row.

That is the row where "I already know how" stops being a reason to skip the system and becomes the evidence you need one.

The domain here is mine. The shape is not domain-specific. Swap the repository for your client emails, your proposals, your course scripts, and the sort runs identically.

Why the prompt document did not fix this

You have a prompt document. Mine was on version seven too.

It was written as a capability aid. It tells the tool how to do the thing. It describes.

It never checks.

Describing and verifying are two different objects, and they fail in different ways. A description gets read when the tool happens to read it. A check runs whether anyone remembered it or not.

That is why corrections stop persisting after about a week.

The rule you wrote was correct. It just never had anything to run against.

The part that mattered more than the decision

I reversed myself and built the checks. That is the boring half.

The half worth copying is what I did with the wrong reasoning.

I did not delete it. I wrote it into the file that governs the next decision of that kind, with the reason it was wrong stated plainly: "the owner can already do this" is not a reason to skip a system. It is a reason to check whether the failure is capability or consistency.

A deleted mistake teaches nothing and comes back on a schedule.

A recorded one turns into a rule that costs less than the mistake did.

That is the difference between a business that keeps notes and a business that learns.

Run the sort on your own three

Open the last three things you shipped and then had to correct.

Write one word next to each. Capability, or consistency.

If all three land in the same row, you already know what you are actually building.

Then send me the one that surprised you. Hit reply. I read every one.

Excelsior,

Pierre/
Founder, Curio Chat Academy

P.S.: That tally in the back of your head is real data. It is just stored in the worst possible place.

P.P.S.: If your email inbox is out of control or too laborious to maintain, I can help you with this. Find out how here .