Part 10 — Integrated Case Studies
Guardrail experiments
The case study's most instructive result: a correction policy that added ~25 points to the 3B model and then regressed the 7B model when transferred unchanged. This is the two-sided guardrail lesson, measured — fixes and regressions on real systems.
The diagnosis named a precise, concentrated failure — ranking predicted where breakdown was expected — and a precise failure invites a precise fix. So the project built a correction policy targeting exactly that confusion, and the result is the most instructive in the whole case study: it added ~25 points to the model it was built for, and then, transferred unchanged to a stronger model, regressed it. This is the two-sided guardrail lesson — fixes and regressions — measured on real systems, and it's why the book insists on reporting raw and corrected separately.
What you will understand by the end
- The correction policy the case study built, and what it targeted.
- Why it added ~25 points to the 3B model.
- Why the same policy regressed the 7B model.
- Why this proves a guardrail is a two-sided trade tuned to one system.
The policy: target the diagnosed failure
The correction policy is a deterministic rule aimed at the exact failure the
diagnosis found: when the model predicts top_n_by_metric (a ranking) but the question contains
no ranking language ("top", "highest", "best"...), downgrade the pattern to
metric_by_dimension_with_filter (a breakdown). It's a rule keyed to the ranking-vs-breakdown
boundary — precise because the diagnosis was precise.
IF model predicts top_n_by_metric AND question has no ranking cue
THEN downgrade pattern → metric_by_dimension_with_filter
+25 points on the 3B model
On the Qwen 3B model it was built for, the policy worked exactly as intended: the 3B model made the ranking-for-breakdown mistake often, and the rule caught and corrected a large fraction of those, lifting the system's accuracy by roughly 25 points over the raw model. A single hand-written rule, targeting one diagnosed confusion, moved the number more than a lot of model tuning would — because it addressed the dominant failure class.
A guardrail keyed to a precisely-diagnosed, concentrated failure is high-leverage: the case study's rule added ~25 points because it targeted the dominant failure type. This is the payoff of good failure analysis — a precise diagnosis enables a precise, powerful fix.
The same rule regressed the 7B model
Then the revealing part. Transferred unchanged to the stronger Qwen 7B model, the same rule
mostly regressed it. The reason is the two-sided nature of every guardrail: the rule fires on a
condition (a top_n prediction with no ranking cue), and that condition doesn't perfectly match the
failure. The 7B model already handled many of those cases correctly, so when the rule fired on them
it overrode right answers into wrong ones — regressions that outweighed the fewer fixes on a model
that needed less help.
The guardrail was tuned to the 3B model's failure mode, so it encodes assumptions about how that model fails. On a model that fails differently — the 7B, which already got many of those cases right — the same firing condition lands in the wrong places and does net harm. A correction policy is part of a specific system, not a portable upgrade; it must be re-measured on every model it's applied to.
What it proves
This single experiment is the guardrail chapter made concrete on real systems. It proves a guardrail is a two-sided trade: its value is the net of fixes and regressions, not the count of catches; and it's tuned to one system, so it doesn't transfer for free. Crucially, you can only see both effects because the project reports raw model accuracy and corrected system accuracy separately (complete system) and keeps every intervened trial openable — the +25 and the regression are both visible in the gap between the two dials.
The intervened trials show the rule's two faces directly: on 3B, cases it flipped from wrong to right (the +25); on 7B, cases it flipped from right to wrong (the regression). Same rule, opposite sign, because the models fail differently — the clearest possible demonstration that a guardrail is measured, per model, by its net effect. See every case the policy changed →
Mental model
The case study's correction policy targeted the diagnosed ranking-for-breakdown confusion and added ~25 points to the 3B model it was built for — then regressed the 7B model when transferred unchanged, because the 7B already got many of those cases right and the rule overrode them. A guardrail is a two-sided trade (net of fixes and regressions) tuned to one system — proven, and visible only because raw and corrected are reported separately.
Common mistakes
- Counting the +25 as the whole story. The rule's value is net; on 7B the regressions outweighed the fixes.
- Transferring the guardrail unchanged. Tuned to the 3B failure mode, it net-harmed a model that failed differently.
- Reporting only corrected accuracy. Without the raw number too, you can't see the guardrail's real (and sometimes negative) effect.
- Treating a guardrail as a free add-on. It's part of a specific system and must be re-measured per model.
Practical guidance
- Build guardrails from a precise diagnosis — the case study's rule was powerful because it targeted the dominant, well-characterised failure.
- Always report raw and corrected accuracy; the gap is the guardrail's real effect, positive or negative.
- Inspect every intervened case for fixes and regressions, and re-measure per model — never assume a rule transfers.
- Treat a correction policy as versioned with the system it was tuned to, not a portable upgrade.
Summary
- The case study's correction policy targeted the diagnosed ranking-for-breakdown confusion and added ~25 points to the 3B model.
- Transferred unchanged to the 7B model, it regressed it — the 7B already got many of those cases right, so the rule overrode them.
- This proves a guardrail is a two-sided trade (net of fixes and regressions) tuned to one system — the Part 6 lesson on real data.
- Both effects are visible only because raw and corrected accuracy are reported separately.
Knowledge check
The correction policy added 25 points to the 3B model. Why did the same rule, applied unchanged, regress the 7B model?
Because the rule fires on a condition (a top_n_by_metric prediction with no ranking
cue in the question) that only approximates the actual failure, and it was tuned to the 3B
model's failure mode. The 3B model made the ranking-for-breakdown mistake often, so the rule caught
and corrected many genuine errors (+25). The stronger 7B model already got many of those same cases
right, so when the rule fired on them it overrode correct answers into wrong ones —
regressions that outweighed its fewer fixes on a model that needed less help. A guardrail encodes
assumptions about how one model fails; a model that fails differently gets net-harmed, which is why
guardrails must be re-measured per model, not transferred.
How was the project able to see both the +25 on 3B and the regression on 7B, and why does that matter?
Because it reports raw model accuracy and corrected system accuracy separately and keeps every intervened trial openable, so the guardrail's effect is the visible gap between the two dials — on 3B the gap is +25 (cases flipped wrong→right), on 7B it's negative (cases flipped right→wrong). It matters because a guardrail's value is its net effect, and reporting only the final corrected number would hide whether the model is genuinely good or being carried (or harmed) by a rule. Separating raw from corrected is what turns "the guardrail helped" into a measured, per-model, honest claim — including when the honest answer is "it made this model worse."
Related chapters
- Guardrails: fixes and regressions — the evaluation-side lesson this proves
- Guardrails, retries, fallbacks and correction policies — the design side
- The model is only one component — raw vs corrected, the two dials
- Diagnosing intent failures — the diagnosis that made the rule precise