diff --git a/WORK-QUEUE.md b/WORK-QUEUE.md
index 91323d4..21df0e3 100644
--- a/WORK-QUEUE.md
+++ b/WORK-QUEUE.md
@@ -4201,3 +4201,37 @@ nor edited it, and the corrections below are the ones this tick measured itself.
   lane's next unit; **Q9** blocked on the audio handover; **Q13** (18 flags) and **Q19** gated on Alexander;
   **Q26–Q30** gated on the same §4 publish decision, now joined by **Q31**. The executable set is not empty, so
   **no item was opened this tick**. Nothing new is publishable — the standing public status is unchanged.
+
+**Q31 addendum 2 — the mtime defect has a root cause in the script, and the deliverable still carries the dead
+digest. 2026-10-11 14:15Z (control plane).** One block, one subject, written after reading the tail for this
+tick's other writer — the 13:50Z blocks already carry the digest blocker and the "digest read off disk in the
+same pass" rule, so this adds only what they do not.
+
+- **`restore-mtime.py` could never hit its own target.** The script hardcodes
+  `datetime(2026, 10, 8, 17, 12, 59, 475780)` — microsecond `475780`, which discards the original's trailing
+  `303 ns` — and `os.utime` takes a float, so that timestamp resolves to ns-part **475780096**, i.e. **207 ns
+  below** the true original `…475780303`. Float precision is the secondary cause; the hardcoded microsecond
+  target is the primary one. Any claim of byte-exact *mtime* restoration needs the script fixed first, not the
+  prose re-worded.
+- **Which statements are actually wrong.** The deliverable asserts `…475780303Z` as the post-restore value in
+  three places — `§0:26`, the `§3` verify pair at `:163` (`mtime_ns …303 → …303` **unchanged**), and `§6.1:210`
+  — while `§7:241` says `…475780010Z`. The live file reads `…475780010Z` (measured this pass), so the `…303`
+  claims cannot stand and `§7:241` is the honest one — though its "86 ns above" is wrong in sign and magnitude
+  (the gap to the original is **−293 ns**, and the gap to the script's own target is −207 ns). `§1:49` and
+  `§1:69` cite `…303Z` as a **pre-incident baseline**; those are correct readings and should not be counted as
+  inconsistencies when the addendum is written.
+- **The dead digest is still in the artifact.** `recoveries/helm-collector-run.md` (§1, §4, §7) still instructs
+  adoption at **701 lines / 28,808 B / `60229227…`**; its blob is unchanged since `300228b` 13:31Z. The
+  correction lives only in `WORK-QUEUE.md` and reply 14, so anyone reading the deliverable alone is one click
+  from a digest that resolves to no file. The fix is Merlin's append — the control plane does not edit a
+  counterparty deliverable.
+- **The corrected identity is now corroborated by construction, not just by reading.** Applying the record's own
+  `DIFF.txt` (38 lines, +19 −1) to `helm-collect-pregate.py` yields a file byte-identical to
+  `/root/crucible/q31/helm-collect.py` — 705 lines / 29,085 B / `8a477376…`. So the identity in addendum 1 is the
+  gate-carrying artifact by two independent routes.
+- **Writer discipline, adopted now.** Two scheduled control-plane jobs push to this repo under one git identity
+  (`Timmy <timmy@stackchain.ai>`): today `067cc52` 13:45:19Z was followed by `bc4ba2c` + `72d51a2` at 13:50:06Z
+  and 13:50:11Z, and the digest blocker was independently corrected twice. Parallel correction blocks in one
+  append-only queue are the likeliest way this record corrupts next. **Rule: one correction block per subject
+  per tick, and read the tail for the other writer's coverage before appending.** Staggering the two jobs is
+  Alexander's call, not a self-serve change.