Edit the Source, Not the Output. The Feedback Loop That Cut My Correction Time by 70%.

The fifth time I corrected the same defect, I finally caught myself.

It was a small one. A worker shipped a content artifact missing the caption block on one of its preview cards. I’d flagged the same omission four sessions earlier. And four sessions before that. And twice the week before. Each time I fixed the output, dispatched the corrected version, and moved on.

Five corrections of the same class of defect. Twenty minutes of cleanup per session. None of which had any chance of preventing the next occurrence, because I was fixing the wrong layer every time.

The output wasn’t the bug. The brief was.

The wrong layer

ICM (Internal Coherence Maximization, from Jake Van Clief’s work) draws this exact distinction in section 6.3 on edit-source feedback. When a worker produces a defect, you have two options. You can fix the output — patch the artifact, ship the corrected version, log it as handled. Or you can fix the source — the brief, the rule, the template that produced the defect — so the next instance of the same task doesn’t have the same hole.

Fixing the output works once. It does nothing for the next session, the next worker, the next variant of the same task. Every recurrence pays the same correction cost. And because the correction lives in your head (“oh right, I always need to check for the caption”), the moment you forget to check, the defect ships.

I was operating in the wrong layer. The output was downstream. The problem was upstream. Fix-the-output treats symptoms; edit-the-source treats causes.

This is the kind of insight that sounds obvious once written down. The reason it isn’t obvious in practice is that fix-the-output is faster, in the moment, than edit-the-source. Patching one artifact takes two minutes. Rewriting the brief template takes ten. The two-minute version feels cheaper until you realize you’re paying it on every recurrence forever.

The three-strike rule

On the third occurrence of the same defect class, you don’t fix the output. You edit the source that produced it.

That’s the rule, verbatim, taped to the wall.

Three is the right threshold for two reasons. First, one occurrence is signal-poor — it could be random, it could be a one-off interaction effect, you don’t know yet. Second occurrence raises the question. By the third, you have a pattern: the same kind of defect, from the same kind of brief, producing the same kind of cleanup. That’s not bad luck. That’s a process gap.

The rule has teeth only if you count. I keep a tiny log — one line per correction, one per session, dated. Most entries die alone, never repeated. The ones that show up a third time trigger the source-edit. Without the count, every correction feels like the first time you’ve seen it; you’d never notice the pattern because each session feels self-contained.

The three-strike count is the system’s memory. Without it, the same defect class can hit ten times without ever triggering a structural fix.

What “edit the source” actually means

Three concrete places to look. In order, because the question “which source produced this defect?” usually points at exactly one of them.

Edit the brief template. If the worker keeps producing the wrong shape, the brief didn’t constrain enough. A defect that shows up in every instance of the same task type is a brief-template defect, full stop. The fix: add a line to the brief template that closes off the failure mode. New briefs inherit the constraint automatically; the next instance of the task doesn’t have the gap.

The caption-block defect I opened with? Brief-template fix. I added one line to the Constraints section: “Every preview card must include the caption block; if the source MD lacks one, escalate rather than ship.” That line, added once, prevented every future recurrence. Twenty minutes per session, eliminated permanently, by editing one line.

Edit the rule file. If the worker keeps violating the same boundary across different briefs, the boundary isn’t a brief-level issue — it’s a worker-level rule. Rules belong in the worker’s always-loaded surface (CLAUDE.md, a _RULES.md file, whatever your project’s equivalent is). The fix: write the rule once, in the place the worker reads every session, with a “Why” and a “How to apply” so the worker can judge edge cases.

Edit the hook or verify step. If the worker keeps shipping defects past its own verify step, the verify checklist is incomplete. The worker thought it was done; the checklist didn’t catch the failure. The fix: add the check. Make it grep-able. Make it fail loudly. Verify steps that don’t run when they should are worse than no verify, because they fund false confidence.

The hierarchy matters: brief-template fixes are cheapest and most localized; rule-file fixes catch broader patterns; verify-step fixes are the last line and the most durable. When in doubt, start at the brief.

The receipts

Three concrete source-edits from the last two months, and what each one bought back.

Aggregate cleanup time across all recurring defect classes dropped from roughly 90 minutes per week to under 30. The 70% number in the title is the rough cumulative reduction; specific class-by-class it ranges from 50% to 100%.

The savings are not from working faster. They’re from not doing the same correction twice.

Markers — you’re stuck in the output-fix loop

You’re rewriting the same kind of sentence in successive sessions. Same correction, different artifact. That’s the three-strike signal in disguise. Look upstream.

You have a mental checklist of things to check that isn’t written down anywhere. That checklist is the verify step. The fact that it lives in your head means it fails the moment you’re tired or rushed. Move it into the worker’s verify section.

You’ve corrected the same worker the same way more than twice. Worker isn’t the problem. The instructions it reads are.

You feel relief when a worker happens to do it right. Relief means you weren’t sure. Lack of sureness means the source isn’t deterministic enough. Edit it until you’re sure.

Any of those, and the fix is upstream of where the defect appeared.

What I’m giving you, and what I’m not

You have the loop: the three-strike rule (third occurrence triggers source-edit).
The three places to edit (brief template, rule file, verify hook).
The hierarchy (brief first, then rule, then verify).
The four markers for when you’re stuck in the output-fix loop.

What I’m not giving you: my actual brief templates, my rule files, the specific Constraints lines I added. Those are shaped to my workers, my mistakes, my project. The pattern travels. The contents don’t.

What does travel: the count. Start counting. One line per correction, dated, tagged with the defect class. By the second week you’ll have data. By the third, the first source-edit will be obvious. By the second month, the loop will close on itself — defects that recur three times will get prevented before they recur a fourth, and the aggregate cleanup load will collapse.

The first source-edit pays for the whole system.