Chapter 13 — Practice-on-your-own solutions

Why the same artifact scored differently. Three reasons dominate in practice:

1. Different reference for «correct.» Your colleague reviewed the dashboard against «does it look defensible?» You reviewed it against «can I trace each claim to a specific data point?» The Evidence Chain diagnostic (Diagnostic 2) fires under your reference and not under theirs, because «defensible-looking» is not the same as «evidence-linked.» This is the most common source of scoring drift: the diagnostics assume a shared definition of what an oracle is, and reviewers who have not aligned on that definition score the same artifact differently.
2. Different calibration of the telemetry-trio thresholds. Chapter 13’s thresholds (acceptance rate > 0.95, verification prompts = 0, time-to-acceptance < 30 seconds) are illustrative calibration points, not clinical cutoffs. Your colleague’s team may have calibrated to a laxer threshold based on their Copilot literacy; yours may be calibrated tighter. Same session, same three numbers, different verdicts because the thresholds differ.
3. Different exposure to the session that produced the artifact. Your colleague may have been present for the CSAR loop that built the dashboard and remembers watching the analyst verify one of the claims; you saw only the artifact. Diagnostics 1 (Ambiguity burden), 3 (Telemetry trio), and 4 (Repair-loop maturity) can only be scored honestly with session-level context; without it, they default to «can’t tell» which each reviewer resolves differently. If the artifact ships without a defensibility bundle, this asymmetry is almost guaranteed.

The escalation move. Score together. Sit with the colleague, open the artifact and the session notes side by side, and walk each diagnostic one at a time: «what specific evidence would fire this diagnostic; can we find that evidence in the artifact or the session record?» Resolve the reference-and-calibration disagreements in the specific case rather than in the abstract. If the joint pass still produces different scores, that is a signal to iterate, not ship: the fact that two competent reviewers cannot agree on whether the artifact is defensible is itself evidence that the artifact is not defensible yet. The defensibility bundle from Chs 9–12 exists to make this joint-scoring conversation possible in the first place; if it wasn’t attached, that is the upstream fix.

Meta-observation. Disagreement on diagnostic scores is data, not noise. The threshold Chapter 13 names (three or more yes-answers = vibe charting) is a floor for firing the conversation, not an oracle for settling it. Two reviewers who repeatedly disagree by two or more yeses on the same shipped artifact indicate a team-level calibration gap; that gap is worth closing before it produces a shipped decision that neither reviewer can defend.

The reasoning for a discard call. Chapter 13 defines discard as «rebuild from Crystallize,» not «delete and walk away.» The discard call is justified when the artifact’s upstream context has been lost to the point that iterating on the current draft would cost more than starting from a fresh Crystallize pass. Three signals justify that call in this problem:

1. Two failure-mode patterns at once. The four patterns Chapter 13 catalogs (hallucinated insight, misleading default, over-styled output, confidently-wrong narrative) are each expensive to unwind on someone else’s work. Two firing simultaneously means the failure is not localised to one visual — it runs through the report’s framing. Iterating on the framing while inheriting the framing itself is the most common way an inherited-report iteration produces a worse artifact than a fresh start would.
2. Three forcing-function violations. Each forcing function (predict-before-reveal, evidence requirement, restatement-before-action) is a load-bearing gate. Three violations at once means none of the automation-bias corrections landed on the original session; the whole verification apparatus was skipped. Repairing an artifact whose verification apparatus was never engaged is much harder than authoring one where it is engaged from Crystallize forward.
3. Session context has left the building. The original author is gone. You cannot ask them why a specific measure was chosen, what the audience’s intended decision was, which verification steps they intended but skipped. Chapter 13’s repair loop depends on session-level information that no longer exists. A discard-and-rebuild lets you recreate the session context in a form you can actually verify against.

What to say to the manager. Frame the discard as a cost decision, not a craft decision. Something like:

«I ran the Chapter 13 checks on the inherited report and it hit two failure-mode patterns and three forcing-function violations at once. That combination means the original session skipped verification through-and-through, and the framing itself carries the failures — not just one visual. To iterate on this by Friday, I would need to invent the session context to verify against, which is riskier than authoring a fresh version. I can produce a defensible one-page draft against a clean Crystallize pass in the same time; iterating on the inherited draft would cost more and still ship with the framing failures baked in. I recommend we discard the inherited draft, run a 20-minute Crystallize pass together now to lock the audience and the decision, and I’ll have a defensible one-page draft in your inbox tomorrow morning.»

Two things this framing does. First, it names the specific evidence (two patterns, three violations, missing session context) rather than an abstract quality claim. Second, it converts discard from a delay into a faster path to defensible ship. Managers accept discard calls readily when the alternative is honestly named and the fresh path is scoped concretely; they reject them when the discard reads as perfectionism.

Meta-observation. The hardest part of a discard call is not making the technical case; it is defending the extra Crystallize time against the Friday deadline. Chapter 14’s decision-boundary framing (recommendation vs decision artifact) is the upstream discipline that keeps discard calls from feeling reckless: if the artifact’s role is decision artifact, the escalation from iterate to discard is not a preference — it is what the role requires.