diff --git a/scripts/tests/mutation_harness_lib.py b/scripts/tests/mutation_harness_lib.py
index eec28b06e..5b5e89f9a 100644
--- a/scripts/tests/mutation_harness_lib.py
+++ b/scripts/tests/mutation_harness_lib.py
@@ -124,15 +124,17 @@ class Claim:
 
     `outcome` is `RED` or `GREEN`, and the GREEN direction is why this is not just another `Mutation`.
     A `MUTATION` row always claims a red, so the harness only ever had to recognise one. Prose does
-    not, and the corpus carries the other direction too: `.gitea/workflows/review-verdict.yml` says of
-    one arm that disarming it alone reddens nothing, `scripts/check-doc-narrative.py` says removing
-    its `/dev/null` arm reddens no test, and `scripts/tests/hook_fire_isolation.py` says deleting a
-    dead branch left that branch's own test green. Each is a claim that a mutation is NOT noticed,
-    and the rule "declare it or do not write it" is unsatisfiable for them unless the harness can
-    execute a negative. A GREEN entry therefore carries NO `expect`: there is no failing run to read a
-    diagnostic out of, and the three things that could make a green vacuous — a run that errored, a
-    run in which nothing passed, and a proof that never reaches the mutated clause at all — are
-    checked in `verify_claim` instead.
+    not, and the corpus carries the other direction too: `.gitea/workflows/review-verdict.yml`,
+    `scripts/check-doc-narrative.py` and `scripts/tests/hook_fire_isolation.py` each name a mutation —
+    an arm disarmed on its own, an arm removed, a dead branch deleted — and assert that nothing
+    notices it. How each of those sentences words its outcome is deliberately not repeated here: a
+    restatement is a second copy of an outcome, free to drift from the site while the entry that
+    executes it stays green, which is the drift a `Claim` exists to close. What they share is the
+    shape — a claim that a mutation is NOT noticed — and for that shape the rule "declare it or do
+    not write it" is unsatisfiable unless the harness can execute a negative. A GREEN entry therefore
+    carries NO `expect`: there is no failing run to read a diagnostic out of, and the three things
+    that could make a green vacuous — a run that errored, a run in which nothing passed, and a proof
+    that never reaches the mutated clause at all — are checked in `verify_claim` instead.
 
     THE THIRD OF THOSE IS WHAT MAKES A GREEN READABLE, and it needs its own declaration. A red is
     self-checking: a proof that ignores the mutated file stays green and `verify_mutation` refuses it,