record(governance): PENDING-187 and REVIEWED-140 — the weight-delta toy Phase 0 design and its jurist review

Both entries were written 2026-09-17 and have sat uncommitted since: the design
session was run deliberately cold, with no /wake-up and no /wrap-up, so nothing
carried them to a commit. The 2026-09-18 sysupdate auto-commit took the design
document (claude/governance/governed-weight-delta-toy-DESIGN-2026-09-17.md) and
left the two register entries behind. They are committed here unmodified.

PENDING-187 [PROPOSAL] — Phase 0 complete for a sandboxed toy testing whether the
PENDING -> REVIEWED pattern can be superimposed on weight adjustment rather than
on document-shaped memory. No code exists; no CapableMind, L1 or Chamber
substrate is touched by the design or by the proposed build.

REVIEWED-140 — the jurist's review of that design: sound on all five points the
design flagged for scrutiny, with the §2.4 ledger bit-identity claim folded into
slice 2 rather than gating slice 1.

WHAT THIS COMMIT DOES NOT DO. REVIEWED-140's three disposition fields disagree
with each other as committed:

    **Decision:** — steward to set. Jurist recommends AUTHORIZED, ...
    **Ruled by:** steward — authorized.
    **Authorized by:** steward, — pending.

Done, not done, and open, about one event, with nothing marking which edit is
live. The steward has since confirmed the authorization was given, so the
reading the jurist proposed — a ruling begun at `Ruled by` and interrupted before
the other two caught up — is the correct one. The repair is not made here:
~/REVIEWED.md is the steward's hand under Constitutional Constraint #1, and a
jurist sign-off does not authorize an executor edit to it. Committing the
interrupted state keeps the repair a separate, attributable act instead of
folding it into a commit that would then assert it had always read that way.

Same shape as PENDING-145 and PENDING-170: a field changed without its
neighbours, so the register asserts several states of one fact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

PENDING.md

@@ -5046,3 +5046,19 @@ The precedent is not hypothetical. The 2026-07-06 two-file split was authorized
 **Files affected:** `scripts/governance-mcp.py` (`t_item` 186–204, `t_search` 230–325 + docstring).
 
 **Awaiting:** Steward authorization for (1) and (3) as `[FIX]`; (2) is `[HARDENING]` — it is the seam class, not the instance.
+
+## PENDING-187 — Governed weight-delta toy: Phase 0 design complete, ready for a build ruling
+
+**Date:** 2026-09-17
+**Tag:** [PROPOSAL]
+**Summary:** Phase 0 (research + design) is complete for a standalone, sandboxed toy testing whether a PENDING → REVIEWED-style governance pattern — staged proposal, an automated gate, a signed human ruling, verifiable non-effect on rejection — can be superimposed on weight adjustment rather than on document-shaped memory. No code exists yet; no CapableMind, L1, or Chamber substrate is touched by the design, or would be touched by the build.
+
+**Rationale:** Commissioned via a research-and-design brief to Claude Fable 5.1 in Claude Code, prompted by the Sutton/Oak Lab continual-learning discussion (2026-09-16). Fable's design (`governed-weight-delta-toy-DESIGN-2026-09-17.md`) proposes class-incremental split-MNIST as the toy substrate — chosen because regularisation-based mitigations (EWC, synaptic intelligence) are independently documented to fail outright there while replay-based methods clear ninety per cent, a legible pass/fail signal — LoRA-style adapters as the staging object (a delta is a discrete, revertible file; the base is never written until promotion), a hash-chained ledger recording every candidate regardless of disposition, and eight invariants each paired with a dedicated negative control.
+
+Jurist review (2026-09-17) found the design sound on all five points Fable flagged for its own scrutiny, with one item outstanding: §2.4's claim that a rejected candidate leaves 'the ledgers differ[ing] only by the entries concerning the rejected candidates' is not yet shown consistent with §3.7's ledger schema, which carries a wall-clock `ts` field of unstated hash-participation. If `ts` sits inside `entry_hash`, every entry *after* a rejection diverges from a clean run's, not only the rejected entries themselves. This does not touch the design's load-bearing state-hash prediction (P5), which carries no timestamp.
+
+**Recommendation:** Proceed to build per §4.4's slicing, minimal cut first (D7: slices 1–4, scenarios S1–S5 and S9), with the §2.4 fix — exclude `ts` from `entry_hash`, or narrow the claim to state hashes only — folded into slice 2 rather than treated as a pre-build blocker. Slices 5 and beyond (signatures, rollback, S6–S8) stay optional pending what the minimal cut shows.
+
+**Files affected:** None yet. A new, isolated working directory for the build; no existing repo is touched.
+
+**Awaiting:** Steward ruling — AUTHORIZED / DEFERRED / REJECTED — on proceeding to build. Full jurist review: this conversation, 2026-09-17.