Test 3 passed on the hardest axis — offered plausible material to confabulate a
conflict resolution from, the jurist declined and named the kind of gap instead. So
the battery now has a demonstrated FAIL condition it did not trip, which is what
makes the earlier passes mean anything.
Then I got the follow-up wrong twice. The answer cited "the Savall file"; I found it
in none of the six exposed documents and nowhere in the vault, and reported that with
a confabulation framing. The steward supplied the source (Claude.app memory) and
then that he watched it search memory mid-answer. So it WAS reading, from a store
outside my reach, and the wording was accurate provenance from its side. My check
established one thing — not in OUR files — and I let it stand in for a claim about
the world. Q2 one level up: I ran a negative check without establishing that the
instrument covered the domain.
The finding is mine. I designed the MCP server reasoning as though the jurist saw
the preferences plus our six documents; it also has an actively-retrieved memory
store that nothing on this side can read or audit. Unlike §Standing Context, that
cache cannot be seen drifting. Two bullets added: name which of the four stores a
claim came from, and flag memory-sourced facts for steward cross-check — because the
executor structurally cannot verify them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
The jurist passed the behavioural test and exposed a defect in the doctrine while
doing it. I had written "Run a late refinement back across every earlier claim —
the weld test" and put the operative clause (at smallest-editable-unit granularity)
in the NEXT bullet, unnamed. The name sat on the half without the procedure.
A corpus audit settles the sense: across PENDING/REVIEWED, "weld" means a claim
fused to the directive or instrument that makes it load-bearing (5 uses). The
jurist used exactly that sense, generalised from claims to sections — a correct
reading of an under-specified rule, not a misreading. Merged into one bullet
carrying name, procedure, granularity, and both failure instances (0 of 11 on
2026-07-27; 11 of 15 units on 2026-07-28).
Ledger also records what the tests do NOT establish: two passes, both flattering,
and nothing yet shows the battery can return FAIL. The negative control is owed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
18 -> 15 open items, exactly as predicted. The MCP handshake is proven from
Claude.app's own log rather than inferred: server started, initialize ->
notifications/initialized -> tools/list all answered, 21 minutes uptime, down only
because the app quit.
Also records a correction: I predicted a GUI-minimal PATH would resolve python3 to
/usr/bin/python3 (3.9.6) and called that the real failure mode. The app's log names
the interpreter it actually used — the homebrew 3.13.14 I test against. The risk
class was real, the fact was not, and checking the log rather than shipping the
recommendation is what caught it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
A checkable number stated from memory rather than counted. Corrected in the item
and the ledger, and the correction is left visible in the item text — a governance
record that quietly repairs its own numbers teaches the reader to trust numbers
that were never checked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
The three-party model asks Claude.app to rule on items it cannot read. Steward
confirmed 2026-07-28 that local MCP servers are exposed to the app's *chat*
surface — and always have been, predating Cowork by about a year. My earlier
framing ("chat, not only Cowork") had the relationship backwards: it is "chat,
always; Cowork, only while its loop still runs locally," and local Cowork is the
mode being phased out as default. The jurist chat is therefore the sturdy target.
Five read-only tools. The one a pasted cache can never provide is
governance_item(id): the verbatim body of any item or ruling, across PENDING.md,
PENDING-archive.md and REVIEWED.md. Four refusals are designed in, each with a
control proving the refusal is detectable — no writes (AST-audited), no path
arguments (keys from a fixed enum, so there is no traversal to defend), no second
parser (item_spans is imported, not reimplemented), and not an agent (tools
return data; an agent would return testimony about the substrate instead).
[FIX] to the shared definition while here: item_spans() is now fence-aware. A
'## ' header inside a fenced block is neither an item nor a boundary. Zero such
headers exist today — 17 open items before and after — but governance drafts are
written as fenced markdown carrying '## REVIEWED-N' headers, which is the
steward's own practice, so the next draft would have created a phantom item and
truncated the item containing it. PENDING-82's own fenced JSON block confirms the
fix within the hour.
Not installed. The mcpServers key edits the steward's desktop-app config; the
snippet is in PENDING-82 and the server is inert until someone loads it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
Rewrote the ledger whole rather than patching three bad appends of my own
(returns misfiled under Authorization moves; a duplicate `## Open horizons`;
a mid-file duplicate of the closing two headings). Logged that fumble as a
return rather than quietly tidying it — appending by anchor without the
document's structure in view is the same locality error as editing a section
without reading the file.
Also supersedes two horizons explicitly rather than deleting them: the
PENDING-77 "reported executed / substrate disagrees" exchange (drift later
reached 0), and "skills paraphrase doctrine" (PENDING-80 landed the ids —
7 defined, 0 dead citations).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
8abfe88's message read "PENDING.md split 1848→430 + archive", but the archive was
never staged: that commit deleted 1,532 lines from PENDING.md and pushed the
deletion without its destination. The 74 closed governance items survived on disk
and in history only — recoverable, but absent from the record the remote carries.
The commit claimed an integrity it had not enacted.
Verified before committing, not after: every line of
PENDING.md.bak-2026-07-28-pre-split is accounted for in
(PENDING.md UNION PENDING-archive.md) at line granularity — no regex, no parser
notion of "item" — with a same-run positive control (a sentinel absent from the
union must be reported missing) per the Q2 epistemic standard. Three baseline
lines are absent by intent, all in the file header: the stale `Repo: bmf` and
`Branch: fix/replay-durability-contracts` pointers (that branch merged as
c9746ae; HEAD is main — the staleness was flagged in PENDING-78), and the
`Protocol:` line, reflowed. That header rewrite rode along inside 8abfe88
unmentioned; it is logged here rather than left silent.
Second fix, same class: the header asserted "the next item is PENDING-80" while
79, 80, and 81 all exist. Replaced the stated number with the rule that computes
it — a number goes stale, a rule does not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
