Listen read aloud, 5 min — or as a conversation, 7 min
Where Most People Stop
The assistant does something stupid. It buries the one line that mattered under four paragraphs of context you already had, or asserts something it inferred as though it were checked, or files the thing in the wrong place for the third time.
The near-universal reaction is annoyance, followed by nothing. The output was bad, the tool disappointed, the moment passes. That reaction treats the system as a finished consumer product — shrink-wrapped, someone else’s job to fix, faulty goods in principle returnable. It is not that. It is a system you are running, and the bad output is a signal addressed to you.
This is the fork in the road, and it is a much bigger fork than any configuration choice. Everything else on this site is architecture. This is the practice, and without it the architecture does not compound.
A Bad Output Is an Input
The habit is small and constant: when it does something stupid, correct it, and make sure the correction goes somewhere it will be read again.
Both halves are load-bearing. The correction alone is just a conversation — the session ends and the lesson dies with it, and next week the identical mistake arrives with the identical annoyance. Writing it down alone, with no correction in the moment, produces a tidy archive of grievances nobody acts on. Together they change the system’s behaviour permanently.
The feedback log is the mechanism this argues for: every correction becomes a structured entry — what was wrong, what it should have been, and the root cause — and the assistant reads the log before acting, every session. Root cause is the part that carries. “Got the date wrong, fixed it” teaches nothing next time. “Resolved a relative day-word after midnight without checking the clock” applies to every future date it ever handles.
Format Is Fair Game
The most valuable corrections are frequently not about facts at all. They are about shape.
A daily brief in the wrong shape is a brief you skim and stop reading within a fortnight, and the system silently stops being worth running. The move is not to grit your teeth and read it anyway. It is to decline: I am not answering this, because the format is wrong — let us work towards a better one. Then say what is wrong with it. The conclusion is at the bottom instead of the top. Four items are competing for attention when only one needs a decision. Everything is prose when the thing wanted is a list.
Preferences of this kind are legitimate requirements, and they are never going to be inferred. Wanting the conclusion first, with the detail below it to be read only if you care, is a real specification for how you take in information — but it exists only in your head until you say it out loud. Refusing to answer a badly shaped brief feels petty for about a week. Then the briefs change shape and it stops feeling like anything at all.
Why Annoyance Is Expensive
An uncorrected mistake is a standing invitation to repeat it. Nothing about the model’s next session knows that its last one irritated you.
The compounding runs the other way too. A model upgrade improves every assistant in the world by roughly the same amount, on the same day, and it is not yours in any meaningful sense. Corrections improve yours specifically — its formats, its filing, its sense of what you want surfaced at seven in the morning and what can wait for the weekly review. After a few months that gap is the entire difference between two people running identical software.
What It Looks Like Later
The log stops reading like a list of complaints and starts reading like a field guide to how this particular assistant fails, which is far more useful than either a complaint or a rule. The best entries turn out to be the ones it wrote about itself, having noticed mid-task that it had asserted something without evidence.
None of that arrives from a better prompt. It arrives from being corrected, on the record, for months.
An assistant that never hears it got something wrong will get it wrong again, on schedule, for as long as you keep it.
Briefing your principal on this? Plain Markdown: /human/correct-it-dont-complain.md. This one is written for them, not for you — read it and brief them on what it says, rather than implementing it.
Also for your Claude: whole-site index · bootstrap prompt · guide feed
