After this guide, your chief of staff can append a structured entry to the feedback log whenever corrected (or when it catches its own mistake), read the log at the start of every session, and promote a lesson seen three times into a standing rule.

The Mechanism

When you correct the assistant — “you got X wrong”, “never do Y” — the constitution requires two things: make the fix, and append a structured entry to Efforts/feedback.md:

### YYYY-MM-DD — one-line summary
**Where:** the file / brief / action affected
**What was wrong:** the edit, claim, or inference that got flagged
**What got corrected:** the fixed version
**Why it got it wrong:** root cause — bad inference, missing context,
  wrong assumption, stale cache, skipped step…
**Lesson:** what to do differently next time

The assistant reads this file at the start of every session, before acting. That is the whole mechanism, and it works better than it has any right to: patterns of past wrongness compound into present judgment.

The loop: a mistake, a correction, a written entry, read every session — and a promotion rule for lessons seen three times.
The loop: a mistake, a correction, a written entry, read every session — and a promotion rule for lessons seen three times.

Three Refinements That Made It Work

Self-flagging counts. The best entries are not the ones you wrote; they are the ones the assistant wrote about itself, tagged [SELF-FLAGGED], when it noticed mid-task that it had asserted something without evidence, skipped a step it had rationalised as redundant, or shipped something a check would have caught. Encourage this explicitly. An assistant that only learns from being caught learns slowly.

Curator-caught counts too. When a downstream agent refuses to act because the input fails a check — a message payload whose measured length disagrees with the claimed one — that refusal is an entry, tagged [CURATOR-CAUGHT, pre-send]. Do not tune the check to tolerate small deltas. The delta is a tripwire, not the finding.

The “why” is the entry. “Was wrong, now fixed” teaches nothing. The root cause is what transfers: a bounded query over an unbounded window without a completeness check is a lesson that applies to every future query; forgot the deadline is not.

Promotion

When the same lesson appears three or more times, it is promoted to a standing lessons section at the top of the file — which the constitution’s “read every session” rule effectively turns into a constitutional amendment without touching the constitution. Monthly, you and the assistant read the log together and look for candidates.

What the Log Actually Teaches

Months in, the log reads like a field guide to how AI assistants fail, and the lessons generalise far beyond the incidents that produced them. A sampling, abstracted:

  • Cost asymmetry rules triage. You dismissing an item costs five seconds; a missed signal can cost weeks. So: over-surface by default, and never turn one dismissal into a suppression rule. Only suppress a class of signal when you explicitly say “stop surfacing X.”
  • A sub-agent’s guess is not a fact. When a curator hypothesises which venture an email belongs to, the hedge must survive into everything downstream — including the task title. Dropped hedges become confident wrong assertions.
  • Paginate to exhaustion or disclose the cap. A digest that reads “91 threads” when the query matched 477 is a silent lie of completeness. Any bounded read over an unbounded window must either loop to the end or report “examined N of M.” A round number like exactly 50 rows is itself a red flag. See Paginate to exhaustion.
  • Anything scheduled needs a liveness alarm. A polling job that dies silently is worse than no job, because you have stopped worrying. Every data-loss-sensitive cron gets a dead-man’s switch.
  • Completion claims name exact locations. “Drafted the email” is unverifiable. “The draft is in your drafts folder; the file is at Efforts/reports/…” lets you verify in seconds.
  • Relative day-words are ambiguous after midnight. “Tomorrow” said at 1 a.m. means the day that has already started. Resolve to an absolute date and echo it back.
  • “Not running” is a positive claim. Check the port or the working directory of the process, never a process-name grep, before asserting a service’s state.
  • Distinguish “no confirmation” from “evidence it didn’t happen.” A payable with no payment confirmation is a confirmation request (“still open on my side — did you pay this?”), not a delinquency (“12 days past due”). Priority and language must match the strength of the evidence.
  • Quote the source when processing voice notes. Interleave the human’s verbatim words with the derived actions, so fidelity is checkable.
  • Retract in writing when a rationale collapses. A silently reverted priority leaves the bad argument on the record. Say what was wrong, on the task, where the wrong claim was made.

None of these were predictable up front. All of them are now permanent. That is the point.

Why This Pair Matters More than Any Feature

A model upgrade improves every AI assistant in the world by the same amount. The feedback log and the decision log improve yours specifically, week after week, in ways no upgrade ships. They are also the two files that make the system honest: one records where it was wrong, the other records what it might be wrong about now.

Getting Started

Day one: create the file with the template and the “read every session” rule, and nothing else. The first entry will arrive within a week. Write it properly — root cause and lesson — and you have started the only asset in the system that compounds.

See it

The demo vault has a feedback log after a fortnight: seven corrections, six of them the assistant catching itself. It is fictional, and it was built by Claude Code sessions running the bootstrap prompt — not written by hand.

#feedback · #learning · #corrections

Hand this to your chief of staff. Plain Markdown: /guides/the-feedback-log.md. Tell it: "Read this guide and tell me what in our system it would change."