Teach it, then verify it
Derived from: the corrections corpus I maintain for my own build — one file per rule, each carrying the reasoning behind it, all loaded into every session automatically.
Two motions. Nothing in the default workflow makes you do either.
First: never accept an AI claim that touches your expertise without checking it. It will be fluent and confident when it's right, and fluent and confident when it's wrong. Your expertise is the only test that distinguishes them. Early on, a tool I was building produced a worked answer to an engineering problem and then graded its own answer "correct" — the number was wrong, and one of the forces was pointing the wrong direction. I caught it in about four seconds, not because I'm good at AI, but because I'd spent years on that exact kind of problem. The real question that moment raises isn't "how did it get that wrong." It's: what about every answer it's given me in the areas where I couldn't have caught it?
Second, and this is the half people skip: institutionalize the correction. Don't take the fix and move on — write the rule down so the system can't make that mistake again. Otherwise you re-argue the same correction every week, and you're the only thing standing between the AI and the same error, forever.
The format below is the one that made the difference for me: one file per rule, and every rule carries its why. A rule without its reasoning gets misapplied at the first edge case — the AI follows the letter and misses the point. A rule with its reasoning gets applied correctly to situations you never anticipated.
The template
-------------------------------------------------------------------------- ONE FILE PER RULE. Keep them short. Load all of them into every session. -------------------------------------------------------------------------- name: short-hyphenated-slug description: one line — enough to know whether this rule applies right now [THE RULE, stated as a rule. One or two sentences. Say what to do, not what happened.] **Why:** [THE SPECIFIC INCIDENT, and what it cost. Name what was actually wrong, not "it made a mistake." This is the field that makes the rule survive contact with a situation you didn't anticipate.] **How to apply:** [WHAT TO DO DIFFERENTLY, concretely enough to follow without judgment calls. If there's an anti-pattern, name it.] -------------------------------------------------------------------------- WORKED EXAMPLES — three of my real ones, generalized -------------------------------------------------------------------------- name: no-speculation-as-fact description: Don't state an unverified cause as fact — verify first When explaining what changed and why, verify against the actual source before asserting a cause. Mark genuine speculation AS speculation. **Why:** I was told a change in the output "was almost certainly" caused by a specific restructure. It was stated as fact. It was wrong — nothing had changed there; the real cause was something else entirely. I spent time reasoning from a false premise before catching it. **How to apply:** For any claim about cause, check the actual record first. "I don't know yet, let me check" is always acceptable. "Probably X" is acceptable if labeled as a guess. A confident wrong cause is not. --- name: check-the-source-not-your-memory description: Read the actual definition before using a name or value Before using a name, constant, field, or value from the system, read its real definition. Do not write it from memory or infer it from context. **Why:** Plausible-looking names were invented that didn't exist anywhere in the system. Everything looked right and nothing worked, and the invented names then propagated into a planning document, so the error outlived the original mistake. **How to apply:** Look it up first, every time. The five seconds of checking is always cheaper than the debugging. --- name: push-back-when-you-have-reasons description: Don't fold the moment I disagree — I need the expertise When I push back on a recommendation, don't automatically accept it. Re-evaluate honestly. If my pushback contains information you lacked, update and say which part changed your mind. If it doesn't, make the case again. **Why:** I'm the domain expert; I rely on you for the expertise I don't have. Folding the instant I disagree removes the exact value I'm here for. Mutual challenge is the point, not deference. **How to apply:** Never open with "you're right" and no reasoning. Either "reversing — the piece I missed was X" or "I still think Y, and here's the tradeoff you'd be accepting."
The graduation rule. A correction starts in this file. It graduates out when it becomes something stronger: a line in the permanent documentation, a check the system runs automatically, or a test that fails if the mistake recurs. When it graduates, delete it here and note where it went — the file is a working set, not an archive. If a rule keeps getting violated despite being written down, that's the signal it needs to become a check rather than a sentence.
Adapt it to your field
This tells your AI to interrogate you rather than answer for you — which is the whole point, and the part a generic template can't do. The Copy button below takes the prompt and the template together, so you can paste once and start talking.
Help me build a corrections file for the AI mistakes that matter in my domain, and set up the loop that keeps it working. My field: [YOUR FIELD] What I'm building: [WHAT YOU'RE BUILDING] What going wrong looks like: [WHAT GOING WRONG LOOKS LIKE] Step 1 — Predict the failures. Before I give you any examples, tell me the five kinds of claims where an AI is most likely to be confidently wrong in my specific field, and where a non-expert would not catch it. Be concrete: name the actual concepts, units, standards, regulations, or rules of thumb that get mangled. Then tell me, for each, what the wrong answer would cost if it shipped. Step 2 — Interview me. Ask me for corrections I've already had to make. For each one, don't just record it — ask me WHY it was wrong, in the terms my field uses, until the reasoning is written down well enough that someone outside my field could apply the rule correctly to a new situation. Step 3 — Write them in this format: name, one-line description, the rule, **Why:** with the specific incident and cost, **How to apply:** concretely. One rule per entry. Keep each under 120 words. Step 4 — Set up the loop. Tell me exactly how to feed this file back into every session I run, and give me a two-line summary I can paste at the top so the AI knows what the file is. Then tell me which of my rules should skip the file entirely and become an automatic check instead, and what that check would be. Do not invent corrections you think I probably have. Ask.
The first motion — verifying — only protects you where you happen to look. The second — writing the rule down with its reasoning — is what makes the system get better instead of just not getting worse. For a company whose entire institution is one person, that written record is the institutional memory, and it's the only asset that compounds while you sleep.