record(governance): REVIEWED-140 ruled AUTHORIZED — the three disposition fields reconciled by the steward

The entry was placed 2026-09-17 with a ruling begun and interrupted: `Ruled by`
read "authorized" while `Decision` still read "steward to set" and `Authorized
by` still read "pending" — three states of one event, with nothing marking which
edit was live. The jurist pulled the live text, read it as an interrupted ruling
rather than resolving it from one field, and asked rather than picking the
reading that let the build proceed. The steward confirmed the authorization had
been given and placed the correction himself.

All three now agree: AUTHORIZED, ruled and authorized by the steward 2026-09-20,
drafted by the jurist 2026-09-17. `Date:` stays 2026-09-17 — the drafting date —
so the three-day gap between drafting and ruling stays visible instead of being
flattened into one.

The build is unblocked at slice 1 (D7 minimal cut: slices 1–4, scenarios S1–S5
and S9), with the §2.4 `ts`/`entry_hash` fix folded into slice 2.

Note on the sequence: the interrupted state was committed unmodified in 73c1c6e
before this correction, so both states are in the history and the repair is a
separate, attributable act rather than an entry that reads as though it had
always been clean.

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

REVIEWED.md

@@ -3454,10 +3454,11 @@ line number in a placed ruling is a claim with a half-life measured in days.
 ## 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.
+**Decision:** AUTHORIZED. Proceed to build per PENDING-187's Recommendation — minimal cut first (D7: slices 1–4, scenarios S1–S5 and S9) — with the §2.4 `ts`/`entry_hash` fix folded into slice 2 rather than gating slice 1's start.
-**Ruled by:** steward — authorized.
+
+**Ruled by:** steward, 2026-09-20, in chat.
 **Drafted by:** jurist (Claude.app), at the steward's instruction, 2026-09-17.
-**Authorized by:** steward, — pending.
+**Authorized by:** steward, 2026-09-20.
 
 Fable's own §8 asked the jurist to attack five points; each is answered, then two independent checks and one further finding.
 
@@ -3465,12 +3466,10 @@ Fable's own §8 asked the jurist to attack five points; each is answered, then t
 - **§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.
+- **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.
 
 **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.
+**Proceed:** 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. Tag any commit touching this work with `REVIEWED-140`.
-
-**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.