A Correction You Make Twice Is a Missing Rule
The third prompt in our Freedom Ag module 4 opens with this line:
You just got something wrong, and I do not want to correct it a third time. Turn it into a permanent rule.
Most people treat a bad AI output as a bad prompt. They rewrite the prompt. They add more context. The next session, they do it again. The same thing goes wrong. They correct it again. They've been in a loop for three months.
The loop exists because the correction didn't go anywhere. It fixed the current output and changed nothing about the next one.
The Difference Between Correcting and Fixing
A correction is local. You say "don't use that tone" and the current chat adjusts. The next chat starts fresh.
A rule is permanent. It lives in the business file, which loads automatically in every project, every Cowork session, every time Claude opens. You never say that thing again.
The prompt converts the first into the second.
The Underlying Mistake, Not the Surface Slip
The prompt asks Claude to identify the underlying mistake before it writes anything. Not what the output said. Why it said it.
If Claude told a customer a delivery date nobody gave it, the surface slip is the wrong date. The underlying mistake is that it filled a gap instead of asking. That's the thing a rule needs to prevent: not "never say this specific date," but "never state a delivery date not in the source material, put a [CONFIRM: ...] placeholder instead."
The rule has to be that specific because a vague rule doesn't prevent anything. "Be careful about facts" is not a rule. "Never state a price, availability, or delivery date that isn't in what I gave you" is a rule.
What the Prompt Produces
The output is four things in order: the underlying mistake named in one sentence, one rule that would have prevented it, which section of the business file it belongs in and whether it replaces an existing line or gets added underneath, and the finished section in a code block you can paste over the old one.
The last step matters. Getting a rule back as plain text and then having to find where it belongs in the file is friction. A code block you can paste directly over the old section removes that friction. The rule goes in or it doesn't. There's no middle state where you mean to add it and don't.
The prompt also asks Claude to be honest if this is a one-off that doesn't deserve a rule. A file full of rules for things that happened once is a file nobody trusts. If the mistake was context-specific and wouldn't plausibly happen again, the prompt should say so.
Why This Is the Maintenance Workflow, Not the Setup
Module 4 has three prompts. The first builds the file through a structured interview. The second attacks it and finds the gaps before they cost you anything. The third keeps it current.
The third prompt is the one that actually changes how the file works over time. The interview produces a reasonable first draft. The pressure-test catches what the interview missed. But the file only gets genuinely useful after real corrections, specific to your real work, have been converted into rules that prevent the same mistake from happening again.
Isaac has run a business file like this for about a year and a half. It has accumulated hundreds of specific instructions from real corrections. The instructions from month one are not the instructions that matter. The ones that matter came from sessions where something went wrong, and the correction went somewhere.
That's the only thing that makes the file worth having. Not the interview. Not the initial pass. The habit of converting corrections into rules instead of typing the same correction twice.