Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Four patterns from Chapter 8, four fixes:

  • A. Deciding from the abstract alone (missed papers)

  • B. Falling for the wrong kind of “retrieval” (wrong suggestions)

  • C. Suggesting the same paper again (wasted attention)

  • D. Putting numbers in the reason that aren’t in the paper (misleading reasons)

None of the fixes is hard to write. What I’m careful about is the order: one fix at a time, and after each one I re-measure everything, including the 24 labeled papers from Chapter 4 that v1 already handled well. A fix that repairs this week and quietly breaks last week is a trade I’d rather know I’m making.

Chapter 9 of 12 · Continuous Calibration

Where we left off: We know v1’s four error patterns, and that fixes can interfere with each other.

What we fix now: Apply one fix per pattern, re-measure after every step on both the real week and the labeled week, and catch a fix that breaks something.

By the end, you can:

  • decide when a step should be fixed code (a workflow) instead of the model’s choice

  • apply fixes one at a time with a scorecard, and spot a regression

  • explain why a system can look better on every metric you track and still get worse

Four fixes, one per pattern

PatternFixWhere the fix lives
A. Decided from the abstract aloneFull-text step: after a quick screen of the abstract, any paper that isn’t clearly off-topic gets its full text read, alwayscode (a fixed workflow step)
B. Wrong kind of retrievalGuideline in the prompt: give the model Chapter 4’s labeling guideline, word for wordprompt
C. Suggested againMemory: remember what was already suggested and skip itcode
D. Invented numbersGrounding check: run Chapter 8’s invented_numbers on every reason; withhold any reason that failscode (a guardrail)

Fix A is the one I thought about longest. In v1, the model decided whether to read the full text, and it almost never did, which caused both A and B. So I take that choice away from it. If a step should happen every time, plain code can do it, the same way every time. The model keeps the judgment calls; the code keeps the routine.

That makes the scout less of an agent in the Chapter 1 sense, and I’m fine with that. I’d rather have a fixed workflow with a model at the few points that need judgment than a free agent that skips the step that matters. Roughly how I decide:

Use plain code when...Let the model decide when...
the step should always happenthe right step depends on what it just saw
the rule is known and exactthe input needs interpreting
a mistake would be expensivea mistake is cheap and caught later

My default is the least autonomous design that solves the problem. I only hand a decision to the model when I can’t write the rule.

The quick screen also helps with Chapter 8’s cost worry. Clearly off-topic papers (proteins, translation, tokenizers) stop after one cheap look at the abstract, and only the plausible ones pay for the full text.

Now the scout with four switches, one per fix, and a scorecard with everything I know how to measure so far: precision and recall on the real week and on the labeled week, repeated suggestions, reasons with invented numbers, and model calls per paper.

That’s v1’s baseline in one row: 0.62 and 0.62 on the real week, 0.80 and 0.80 on the labeled week, three repeats, two of eight suggested reasons with an invented number (inv), nothing withheld yet (held), and just over two model calls per paper.

Fix A: the full-text step

Recall on the real week jumps to 1.00: the legal paper, the coding agent and the meeting summaries all get found once the scout reads how they work. The labeled week improves too, since P09 and P17 were the same pattern. Model calls go down, from 2.05 to 1.70 per paper, because off-topic papers now stop after one screen.

Precision on the real week is only 0.80, though. The video recommender and the sleep study are still suggested; reading the full text wasn’t enough for those. The model needs the rule.

Fix B: the guideline in the prompt

Code completion with repository context, and the coding agent that reads the docs first. Both are relevant under my labels, and both are about code, not papers or web pages. The guideline says “documents”, and the model, now reading the guideline very literally, decided code files don’t count.

That’s a regression: a fix for one pattern broke a case that worked before. I only saw it because I re-ran the labeled week. On the real week alone it was a small recall dip, easy to shrug off.

The fix is to make the guideline say what I meant all along:

Both coding papers are back, the labeled week is at 1.00 and 1.00, and the real week is at 0.89 precision and 1.00 recall. One wrong suggestion is left: the sleep study, where a language model really was used, just not on documents. I’m leaving it. Writing a rule for one paper is how guidelines turn into a pile of special cases.

Fix C: memory

Repeats drop to zero, and calls drop again, because a remembered paper is skipped before any model call. The trade-off: remembering by title means a genuinely updated version of a paper won’t come back either. For my reading list that’s fine. For a news scout it wouldn’t be.

Fix D: the grounding check

Four of nine suggestions now arrive without a reason. The guardrail did its job, since nothing false reaches the reader, but the underlying problem got worse. Reading full texts gave the model more material, and it now misquotes numbers in twice as many reasons as v1 did: 300 papers instead of 212, 5 benchmarks instead of 3, 40 points instead of 14, 80 percent instead of 70.

Precision and recall, the numbers v1 shipped on, improved at every step and never looked at the reasons. The guardrail hid the problem from the reader, and my metrics hid it from me. Before I can say this scout is better, I need a number for the thing I now know I care about.

Quick check

Before moving on, answer for yourself (no peeking ahead):

  1. Why is the full-text step fixed code instead of an action the model chooses?

Check your reasoning ▸

Because it should happen for every plausible paper, and when the model chose, it almost never did. A step that must always happen doesn’t need judgment, so plain code does it reliably and predictably. A strong answer adds that the model still makes the actual judgment (relevant or not); the workflow just guarantees it has the right material first.

  1. How did the regression on code completion show up, and what would have happened if we’d only measured the real week?

Check your reasoning ▸

Labeled recall dropped from 1.00 to 0.90 after adding the guideline, and comparing before and after showed exactly which paper was newly missed. On the real week alone, we’d have seen a small recall dip on one paper and could easily have missed that it was a systematic side effect of the new rule. A good answer says the labeled set works as a regression test: it protects cases you already got right.

  1. Fix C (memory) remembers suggestions by title. Name one situation where that’s the wrong behavior.

Check your reasoning ▸

When a paper is updated with meaningful changes, like new results, and you’d want to hear about it again. Remembering by title treats every re-post as a duplicate. A strong answer says every fix encodes a decision, and it’s worth writing that decision down so you can revisit it.

  1. After all four fixes, precision and recall are better than ever. Why isn’t the scout clearly better?

Check your reasoning ▸

Because reasons with invented numbers doubled, and the guardrail now withholds four of nine reasons, so the reader gets less information. Precision and recall only score verdicts, so they never saw this. A strong answer says a system is only “better” on the dimensions you measure, and you need to measure everything the user actually receives.

  1. The grounding check withholds false reasons. Why isn’t that a complete fix for pattern D?

Check your reasoning ▸

It hides the symptom instead of reducing the cause: the model still invents numbers, and now suggestions arrive without explanations. It also only catches digits, not claims like “doubles” or “the first”. A good answer says guardrails are a safety net, and you still want the model itself to make fewer mistakes, which you can only track if you measure it.


You can now: apply fixes one at a time with a scorecard, move always-needed steps out of the model’s hands and into a workflow, catch a regression with the labeled set, and see a failure that no existing metric measures.

But one problem remains: the fixed scout looks better on every metric we track, while its reasons got worse. The next chapter adds metrics for what we now know matters, fixes the reasons at the source, and then answers the question from Chapter 3: has the scout earned the next setting on the dial?

Next → Chapter 10: New Metrics and Earning Autonomy