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.

REVIEWED.md

@@ -3449,4 +3449,28 @@ register-integrity check was built for (2026-08-07, REVIEWED-87 overwritten by i
 here: anchor register citations to symbols or content rather than line numbers** — the reasoning that makes `source_has()` assemble its needle from parts. A
 line number in a placed ruling is a claim with a half-life measured in days.
 
-**If AUTHORIZED:** Proceed. Future citations of code in this register carry a symbol or a quoted fragment; a bare `file:line` is to be read as provisional.
+**If AUTHORIZED:** Proceed. Future citations of code in this register carry a symbol or a quoted fragment; a bare `file:line` is to be read as provisional.
+
+## REVIEWED-140 — PENDING-187 — Jurist review of the Phase 0 design: sound, one item folded into build rather than gating it
+
+**Date:** 2026-09-17
+**Decision:** — steward to set. Jurist recommends AUTHORIZED, condition folded into slice 2, per PENDING-187's Recommendation.
+**Ruled by:** steward — authorized.
+**Drafted by:** jurist (Claude.app), at the steward's instruction, 2026-09-17.
+**Authorized by:** steward, — pending.
+
+Fable's own §8 asked the jurist to attack five points; each is answered, then two independent checks and one further finding.
+
+- **F1 (staging vs proposer-side mitigation) is a fair re-derivation, not a dodge.** The brief itself conflated two functions in one sentence — 'candidate mechanisms for staging... EWC as a soft-protection mechanism' — and F1 corrects the brief's error rather than evading its comparison.
+- **§3.5's voiding rule is deliberately asymmetric, and correctly so on the axis it covers.** It over-voids on unrelated state transitions (by design — a round-trip to the same hash should not silently reactivate an old signature) and under-covers a narrower case: two candidates can be staged and gated against the same protected set with neither promoted, so a later report can reveal something relevant to an earlier, still-`AUTHORIZED` ruling without voiding it, since `CANDIDATE_STAGED`/`GATE_REPORT` aren't state-changing. Logged as a limit, not a defect to fix now.
+- **The `holds` table (§5): row 2 ('no effect until ruled') is honest, not flattering** — the asymmetry is architecturally enforced (compare-and-swap on an immutable base) against conventionally observed (discipline, not proof), a real difference. **Row 1 is the decorative one** — true near-tautologically for anything built as stage-then-rule. **Row 4 may be understated**, contingent on a fact the jurist cannot check from here: whether `PENDING.md`/`REVIEWED.md` commits are atomic per entry. If not, the document register's append-only-ness is closer to a norm than a chain, and the toy's ledger is the stronger of the two without being marked as such.
+- **Proportion: mostly right-sized; the predicted bias shows in what got specified, not in what the build commits to first.** The object model and eight invariants aren't excess for this steward. Nine scenarios and full signing infrastructure are generous for a toy, but §4.4's own slicing already gates exactly that behind 'extended'.
+- **One further finding, not among the five asked:** §2.4 check 4's ledger bit-identity claim is inconsistent with §3.7's `ts` field as written — detailed in PENDING-187 above.
+
+**Independent verification**, by a different route than the design's own (search, not the `ar5iv` fetch it used):
+1. The class-incremental collapse the whole toy setup rests on — regularisation methods failing outright on split MNIST, replay-based methods clearing ninety per cent — is corroborated across independent sources. Not re-derived digit-for-digit; a second witness on the finding, not a repeat of the first.
+2. SageMaker's three-value registry status (`Approved`/`Rejected`/`PendingManualApproval`), used in F5's not-novel claim, is confirmed against AWS's own current API reference.
+
+**If AUTHORIZED:** Hand PENDING-187 and this entry to the executor to begin build at slice 1. The §2.4 fix is scoped into slice 2, not a gate on slice 1's start.
+
+**If DEFERRED or REJECTED:** conditions or reasons are the steward's to state; none are drafted here, since the jurist's own recommendation is to proceed.