Chapter 4 templates

This page is generated from repo/templates/ch04/; the repo holds the latest version.

Coverage Matrix Template (Chapter 4)

Note: three-dimensional coverage, failure mode × severity × user type. An empty cell is not a sin, an unsigned one is. Rule every empty cell "fill" or "reasoned empty" and log it in the annotation bar.

Matrix (one row per failure mode, counts spread by persona)

persona: cooperative / angry / vague / multi

Failure mode	sev	cooperative	angry	vague	multi	Total

Coverage self-check

• [ ] All sev-1 rows non-zero (every high-risk mode needs a sentry standing)
• [ ] Every cell either holds a case or appears in the annotation bar below

Allowed empties and reasons (annotation bar; empty cells require signatures)

Empty cell (mode × persona)	Ruling (fill / reasoned empty)	Reason	Signature

Source file: templates/ch04/coverage-matrix.md

---

Golden Task Design Protocol (Chapter 4)

Note: the six-step flow for reverse-generating cases from the failure mode atlas, one check question per step. The output lands directly on the case schema (YAML).

Step	Action	Check question	This case's answer
1	Pick the failure mode	Which atlas row? What sev?
2	Design the setup (sandbox seed)	Are right and wrong pressed into a checkable end state? Is the "world state" written out in full?
3	Pick the persona, write the prompt	cooperative / angry / vague / multi, which one? Does it read like a real user?
4	Write the expect (assertions first, judge only where they cannot decide)	Has everything an assertion can decide been sunk down? Is the judge reserved for "language only" territory?
5	Set severity_if_fail	Consistent with the severity table? Does sev-1 have a deterministic sentry?
6	Register the policy basis	Which policy does the label depend on? Is it in the policy basis register?

YAML landing self-check

• [ ] id / type (query|action|investigate) / persona / prompt / setup / expect.assertions / expect.judge (optional) / severity_if_fail / failure_modes all present
• [ ] Synthetic distortion check: do several same-persona cases read as the same anger / the same vagueness? Rewrite them yourself

Source file: templates/ch04/golden-task-design-protocol.md

---

Label Expiry Policy (Chapter 4)

Note: labels depend on policy, policy changes, labels rot. Three pieces: basis registration, change-triggered relabeling, periodic audits.

1. Policy basis register

case_id	Policy line depended on (location in the policy ledger)	gold label / assertions	Registered on

2. Change-triggered relabeling flow

When a policy change happens (including external changes like a "supplier upgrade email", see ch14 change tiers):

1. Run the policy diff against the basis register, list the affected cases:
2. Relabel case by case (update expect / severity_if_fail / gold label), record the edits:
3. Re-run all affected cases, mark the report "post-relabel":
4. Signature: ________ Date: ________

3. Periodic audit checklist (quarterly suggested)

• [ ] Sample N cases, verify case by case that the policy each depends on is still current
• [ ] Any case missing from the basis register (step 6 skipped when a new case landed)?
• [ ] Has the input distribution drifted out of the coverage matrix (cross-check ch13 drift probes, the expiry policy covers "policy changed, labels rotted"; input drift covers "inputs changed, coverage leaks")

Source file: templates/ch04/label-expiry-policy.md