diff --git a/PENDING.md b/PENDING.md
index 2164b22..8683b20 100644
--- a/PENDING.md
+++ b/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.
\ No newline at end of file
diff --git a/REVIEWED.md b/REVIEWED.md
index 8b03ed5..3e40f95 100644
--- a/REVIEWED.md
+++ b/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.
\ No newline at end of file
+**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.
\ No newline at end of file