Bridge-Card Sign-Off Plan — v4 Patch List

Date: 2026-05-12 Source: consolidates Reviewer Z (full review held in maintainer's working notes; not on disk in this repo) + Claude's structural critique Target: plan v3 → plan v4 Status: adopted; v4 plan superseding artifact at wiki/.audit/bridge-card-signoff-plan-v4-2026-05-12.md In-repo path: wiki/.audit/bridge-card-signoff-plan-v4-patch-list-2026-05-12.md

Reading guide

Each patch entry contains:

Land: §N of plan v3 where the patch applies
Defect: what's wrong in v3
Fix: proposed concrete change
Source: Z (Reviewer Z) | C (Claude) | both
Priority: critical (correctness; pilot unsafe without) | high (methodological; results may mislead) | medium (clarity/robustness)

Patches are ordered by §N for in-place editing.

§2.1 — Tool allowlist

Defect. "Read-only tools (Read, Grep, Glob, Write)" is incoherent — Write is not read-only. Prompt-scoping Write to a per-agent subdirectory is behavioral enforcement; a misbehaving subagent can write outside its directory, and §3.5 / §7 isolation properties depend on the boundary holding.

Fix. Pick one and specify:

(a) Drop Write from reviewer subagents (I, A, B, C, D). Subagents return report text; main-thread writes to per-agent subdirectories.
(b) Keep Write + add a PreToolUse hook denying Write/Edit outside wiki/.audit/bridge-card-signoff/run-N/<role>/<agent-K>/, plus a no-overwrite rule for hypothesis-note files after the matching report file is written.

(a) is simpler but creates a main-thread write-path through subagent output (mild isolation cost). (b) is the cleaner answer if PreToolUse hooks are available in the Claude Code runtime — verify via code.claude.com/docs/en/sub-agents before adopting.

Replace v3's "Opus 4.7, read-only tools" phrasing with the chosen enforcement story.

Source: Z Priority: critical

§2.2 — Reviewer isolation vs card isolation

Defect. Plan invokes "dual context isolation" (math-olympiad terminology) but each reviewer agent handles 2-3 cards, so a reviewer carries judgment across cards in the same batch. The isolation is reviewer-from-peer-outputs, not card-from-sibling-cards-in-same-reviewer-session.

Fix. Pick one and document it:

(a) Weaken the claim. Rewrite §2.2 to say "reviewer isolation from peer outputs." Acknowledge cross-card information flow within a single reviewer's session as a deliberate trade (batching is cheaper; cross-card pattern recognition may aid #12 motifs-weight tipping detection).
(b) Pay the cost. Spawn 1 A + 1 B + 1 C per card: 15 reviewer agents + 1 I + 1 D = 17 invocations vs. v3's 8. True per-card isolation.

(a) is honest about what the procedure delivers. (b) is what the math-olympiad analogy actually requires.

Source: Z Priority: high

§3.5 + §5 — Anchor-string neutralization

Defect. v3's strip-pass removes "What it makes visible" prose and home-selection paragraphs but leaves anchor strings unchanged. Run3 cards contain anchor locators like silent-keys-2026-05-07.md §Source 2 tier-1 PASS row 3 verdict and work-test. Roles B and C see these labels and are cued toward the upstream verdict before they verify anything — the strip-pass closes prose-level leakage but not anchor-string-level leakage.

Fix. Add to §3.5 strip rules:

Anchor locators in evidence anchors are neutralized before being passed to Roles B and C. Strip tokens: PASS, FAIL, verdict, work-test, tier-1, tier-2, tier-3. Keep file path + section + row/line numbers.
Example: silent-keys-2026-05-07.md §Source 2 tier-1 PASS row 3 verdict → silent-keys-2026-05-07.md §Source 2 row 3.

Add to §5 (Role C protocol) as new item 0 (before existing item 1):

Silent-keys references are locators only, not evidential authority. Verify the cited row's content against extraction note + source page + raw. Do not infer evidential weight from PASS / verdict / tier labels — they may have been stripped before delivery to you.

Neutralization is mechanical (regex over the strip-pass file). Role A receives unstripped anchors (consistent with §3.5's existing treatment of Role A as evaluator of card prose).

Source: Z Priority: critical

§4.5 — MP-scholarship briefing non-exhaustiveness

Defect. The briefing names Dillon / Barbaras on flesh, Carbone / Toadvine on continuity-vs-rupture, etc. — but a curated list of schools is itself a position on which disputes are live. Role B's #10 / #19 firings will skew toward briefing-listed schools; cards encroaching on disputes outside the briefing get a quieter pass.

Fix. Append to the briefing block:

Non-exhaustive. This list names disputes considered prominent at briefing time. It is not a complete map of MP-scholarship contested zones. If you identify a contested interpretive question the card encroaches on that is not in this list, fire #10 or #19 with the school named explicitly, and flag the gap in your hypothesis note's "Convergence-update" field for v0d.7 briefing-update consideration.

Converts the briefing from "exhaustive whitelist" to "starter set with a reporting channel."

Source: C Priority: high

§7 — Two-tool-call enforcement spot-check

Defect. v3 acknowledges two-tool-call enforcement is "prompt-based, not harness-enforced." A subagent that ignores the prompt and revises its hypothesis-note retroactively produces a hypothesis-note trace that looks sequenced but isn't.

Fix. Add to pilot procedure: for at least one reviewer agent per role per run, main-thread cross-checks the agent's tool-call log timestamps against the hypothesis-note and report file mtimes. If the report file was written before the hypothesis-note was finalized (mtime ordering inverted), self-flag the agent's verdict as trace-integrity-suspect in adjudication.md.

For full enforcement: PreToolUse hook denying Write to *.hypothesis.md paths after the matching *.report.md path has been written (pairs with §2.1 (b) above).

Source: C Priority: medium

§11 — SIGN-OFF-WITH-NARROWING: signed apply scope

Defect. §11 says main-thread "narrows the apply-as scope per adjudicator's rationale, then writes sign-off line." It doesn't specify whether the narrowing is written onto the card or only into the adjudication note. If only the note, a future apply-mode agent reads the card's original (broad) Apply-as list plus the sign-off date and applies the broader scope.

Fix. Replace the SIGN-OFF-WITH-NARROWING ratification clause:

Main-thread writes two lines onto the card:
Approved by maintainer: YYYY-MM-DD
Signed apply scope: items [N], [M] only; see `bridge-card-signoff/run-N/adjudication.md#card-X`
Apply-mode agents MUST honor the Signed apply scope: line and ignore Apply-as items not enumerated there.

For full-scope SIGN-OFF (no narrowing), write Signed apply scope: all items so the line is always present and apply-mode agents can lint for its presence (presence becomes a precondition; absence blocks apply).

Update §12 (carve-out) to reference Signed apply scope: as the authoritative scope source rather than the card's original Apply-as list.

Source: Z Priority: critical

§11 ↔ §16 — Main-thread authority contradiction

Defect. §11 forbids main-thread from "reasoning into the adjudicator subagent's recommendation." §16 triggers the agent-teams debate when main-thread "finds the DEFECT report uniquely persuasive on re-read." The §16 clause is substantive adjudication by main-thread, which §11 forbids.

Fix. Rewrite §16's trigger as procedural-only:

Main-thread escalates (to user or to the agent-teams post-isolation debate) when ratification detects one of:

Invalid quorum application — adjudicator's recommendation does not follow §9 from the three reports

Missing Signed apply scope: line on SIGN-OFF-WITH-NARROWING

Cross-card dependency conflict surfaced by §11.5 that adjudicator did not address

Procedural inconsistency between adjudicator recommendation and per-card reports (e.g., adjudicator cites a pattern no Role-B report fired)

Main-thread does not escalate on substantive disagreement with the adjudicator's verdict. Substantive disagreement is not a procedural defect; the fresh-context adjudicator call stands. If main-thread's reading of a defect report differs from the adjudicator's, that is exactly the cognitive seam the adjudicator was introduced to close.

Keeps main-thread as procedural safety checker rather than shadow adjudicator. Consistent with §11.

Source: Z (rewrite) + C (concurs) Priority: critical

§11.5 — Cross-card dependency map construction

Defect. §11.5 assumes a dependency map exists ("for each apply-as item that cross-references another card by slug or by the déposer-style mechanism name") but doesn't say how the map is built. Auto-extracted by regex? Main-thread-curated before adjudication? If curated, main-thread is doing pre-ratification interpretive work, which sits awkwardly with §11.

Fix. Specify the construction rule:

The cross-card dependency map is auto-extracted by main-thread before adjudicator spawn, via regex over each card's Apply-as items, capturing (a) wikilinks to slugs matching other Pass-3 cards' Primary or Secondary home, and (b) named mechanisms whose introduction is attributed to another Pass-3 card. Extraction is mechanical; main-thread does not interpret or weight dependencies, only enumerates.

The map is passed to the adjudicator subagent as part of its input (per §11). The adjudicator decides how to weight dependencies; main-thread's §11.5 reconciliation applies the adjudicator's decisions mechanically.

Removes the "main-thread interprets dependencies" reading.

Source: C Priority: medium

§13.1 — Pilot success criteria: seeded controls

Defect. Run3's 5 cards are real cases with unknown ground truth. Criterion 1 ("at least one DEFECT FOUND") tries to test taxonomy bite but can be satisfied by accident, and 5-for-5 silent APPROVE could indicate either clean cards or under-firing taxonomy. The pilot can't distinguish those without controls.

Fix. Add two seeded controls to the pilot batch (7 cards instead of 5):

Seeded clean card — constructed to be unambiguously well-formed: single source, anchored, modest typed-connection, low-confidence framing, specific counter-test. If pilot fires DEFECT, taxonomy is over-firing.
Seeded planted-defect card — constructed with one known defect (e.g., #1a lexical laundering — secondary author's term presented as primary author's). If pilot fails to fire DEFECT on it, taxonomy is under-firing.

Seeded cards are flagged in the dependency map as seeded but adjudicator is blinded to seeding; the cards look like normal run3 cards through the pipeline. Main-thread reveals seeding only after adjudicator recommendations are written, then evaluates pilot calibration:

Seeded clean APPROVE + seeded planted-defect BLOCK → pilot calibration passes
Seeded clean DEFECT → taxonomy over-firing; revise
Seeded planted-defect APPROVE → taxonomy under-firing; revise
Mixed → ambiguous; investigate which pattern was probed/missed

Replaces v3's criterion 1. Real-card outcomes become evidence about the cards, not evidence about the taxonomy.

Source: Z Priority: high

§13.2 — Criterion 7 perverse incentive

Defect. Criterion 7 ("Human user does not override any per-card decision") treats user-override as pilot failure. But a user override can also be the system working — escalation surfaced a real issue the adjudicator couldn't catch from inside isolation. Treating all override as failure incentivizes tuning the system to suppress legitimate escalation signal.

Fix. Split criterion 7 into 7a + 7b:

7a — procedural override. Human user does not override any per-card decision on the basis of the procedural information main-thread had during ratification (quorum math, the three reports, the adjudicator recommendation). Override here = procedure failed.
7b — context override. Where user overrides on the basis of context only main-thread or user has (Pass 3 motivating prose, cross-session memory, recent ingest, this plan document, prior wikiwip state), the override is logged in adjudication.md under "user-context overrides" and does not count as pilot failure. Override here = procedure worked; escalation surfaced an issue that isolation cannot catch by design.

Pilot calibration tracks 7a / 7b separately. 7a failures revise procedure. 7b cases inform escalate-to-user thresholds in v0d.7 codification.

Source: C Priority: high

§15 — Front-load apply-mode non-authorization

Defect. §15 categorically states the plan "does not authorize apply-mode writes" — load-bearing scope statement living in the back of the document. A reader skimming v3 may miss it and read sign-off as also authorizing apply-mode.

Fix. Add a top-of-document scope clause immediately after the v3 changes note:

Pilot scope. This plan specifies a sign-off procedure to test in pilot form. Sign-off does not authorize apply-mode writes; the apply-mode-discipline / bridge-card-specific-calibration gate (currently outstanding per v0d.5 / v0d.6 wikiwip state) is a separate authorization. v0d.7 codification proceeds only after pilot success, and apply-mode authorization is a v0d.7 question, not a pilot-output question. See §15 for the full carve-out.

Do not weaken §15 itself. Z's proposed "unless user explicitly accepts successful pilot as the bridge-card-specific calibration" clause is rejected — §15's categorical denial is correct and the preface is a visibility patch only.

Source: Z (visibility) + C (rejecting Z's softening) Priority: medium

§16-17 — Agent-teams: verified, patch now

Defect. v3's §17 says teammates "auto-load skills from project/user settings, ignoring subagent tools: restrictions." Reviewer Z proposed a more precise framing. Verified against current Claude Code docs (code.claude.com/docs/en/agent-teams, fetched 2026-05-12):

Teammates honor a subagent definition's tools allowlist and model field ✓
Teammates do not inherit skills or mcpServers frontmatter from the definition ✓
Teammates load skills, MCP servers, and CLAUDE.md from project/user settings the same as a normal session ✓ (slightly broader than Z's framing — CLAUDE.md is in the loading set too)

Additional finding not in Z's review. Team coordination tools (SendMessage, task management tools) are always available to teammates regardless of any tools: allowlist restriction. The implication: if §16's escape hatch ever fires, A/B/C respawned as teammates have a peer-communication channel by construction. Whatever isolation the subagent-mode tools: allowlist enforced is invalidated for any teammate-mode invocation — not because of a bug, but because that's how agent teams work.

This means v3's §16 debate is not just "weaker isolation" — it is a fundamentally different mode where peer messaging is enabled. That has to be named explicitly in the patch, not glossed.

Fix. Replace §17's relevant clause with:

When a subagent definition is invoked as a Claude Code teammate, the teammate honors the definition's tools allowlist and model field but does not inherit the definition's skills or mcpServers frontmatter. Teammates load skills, MCP servers, and CLAUDE.md from project/user settings — the same as a normal session. Additionally, team coordination tools (SendMessage, task management tools) are always available to teammates regardless of any tools: restriction. The agent-teams debate is therefore not a clean-room continuation of sign-off review: it is a deliberate post-isolation adversarial debate with peer-communication enabled, running after the isolated subagent review has produced verdicts. Its outputs are not subject to the same isolation guarantees as the main pilot path.

Also rewrite §16's framing from "escape hatch for adjudication-deadlock" to "post-isolation adversarial debate with weaker isolation guarantees, used only on procedural escalation per §11/§16 fix." If the pilot or v0d.7 codification later finds that the weaker-guarantee mode adds enough net value to be worth keeping, document the trade-off explicitly in the v0d.7 schema-changelog.

Source: Z (technical, verified) + C (additional finding on coordination tools, reframing) Priority: ~~medium (verify) →~~ high (verified; patch now)

§18 — Interpretation-checker single-point-of-failure

Defect. A / B / C get 2 agents per role; I gets 1 subagent for the whole batch. If I has a systematic blindspot — e.g., consistently misses a non-trivial reading because the alternative requires context I lacks — that bias propagates to all 5 downstream A / B / C reads, since each reviewer reads the same map.

Fix. Pick one:

(a) Spawn 2 interpretation-checkers, both running independently on all batch cards. The map passed to A / B / C is the union of their alternatives, deduplicated by (Primary-home, Bridge-type, relation-spec) triple. Adds 1 agent invocation (9 instead of 8).
(b) Document why I's failure mode is qualitatively safer than A / B / C's. Candidate argument: I's output is adversarial context (more alternatives = more probes for A / B / C), so I's blindspot manifests as fewer alternatives in the map, which makes A / B / C's job easier but not more biased toward the card's stated reading. If this argument holds, the asymmetry is defensible. If it doesn't (e.g., if A / B / C use the map as authoritative scope for "what alternatives exist" rather than as a starter set), (a) is required.

(a) is the safer default. (b) is cheaper if the argument holds.

Source: C Priority: high

§20 — Confidence field: pilot inference rule + template delta

Defect. §20 defers the 11th confidence field to v0d.7 but says "Pilot procedure infers confidence from evidence-status field + counterpressure for adjudication purposes" — without specifying the inference. Adjudicator has to make a judgment call without an explicit field, which sits awkwardly with its mechanical-decisional role (§2.1).

Separately: the bridge-card template currently has Counterpressure (10 fields), no standalone Counter-test. Plan references both. Template-vs-procedure status is unclear.

Fix. Add explicit inference rule for pilot:

Pilot confidence inference rule (until v0d.7 codifies the field):

medium — evidence-status names ≥2 independent source-anchors AND counterpressure's counter-test is specific and falsifiable

low — single-source AND single-source-blocker present AND counterpressure's counter-test is specific

speculative — single-source AND (single-source-blocker absent OR counterpressure's counter-test is gestural / could-be-wrong-shaped)

If inferred confidence is ambiguous between two levels, adjudicator marks the card CONFIDENCE-AMBIGUOUS and recommends rewrite-with-explicit-confidence rather than sign-off.

Add template-delta clarity to §20:

v0d.7 template delta. v0d.7 codification adds two subfields to the bridge-card template: (i) confidence: medium | low | speculative, and (ii) counter-test: as an explicit subfield rather than inline within Counterpressure. For pilot, counter-test stays inline in Counterpressure per v0d.5; the inference rule above operates on the inline form.

Source: C (inference rule) + Z (template delta) Priority: medium

Summary table — patch ordering by priority

Priority	Patches	Pilot-blocking?
Critical	§2.1 Write enforcement · §3.5 + §5 anchor neutralization · §11 signed apply scope · §11 ↔ §16 contradiction	yes — pilot unsafe
High	§2.2 isolation honesty · §4.5 briefing non-exhaustive · §13.1 seeded controls · §13.2 criterion 7 split · §16-17 agent-teams reframing (verified 2026-05-12) · §18 interp-checker SPoF	yes — results uninterpretable
Medium	§7 two-tool-call spot-check · §11.5 dependency map construction · §15 visibility · §20 confidence inference rule	no — can land in v4.1

Four critical patches must land before pilot run. High-priority patches affect pilot interpretability — running without them gives ambiguous results. Medium can defer.

Rejected proposals (with rationale)

Z's "pilot vs calibration" preface as written — the "unless user explicitly accepts pilot outcome as the bridge-card-specific calibration" clause introduces an authorization path that §15 categorically denies. Replaced with §15-visibility-only patch.
Z's criterion 1 rename to "any substantive non-approval event" — broadens the signal and dilutes taxonomy-bite testing. Replaced with §13.1 seeded controls, which solves the underlying calibration problem more directly.
Z's §17 "skill-loading sharpening" — redundant; §17 already says subagent definitions are self-contained and the gate / taxonomy / verdict format are embedded in the prompt, not loaded from weave/SKILL.md. No edit needed beyond the agent-teams reframing in §16-17 above.
Z's claim that v3 doesn't address apply-mode-blocker — mis-cite. §15 categorically denies authorization. Front-loading the §15 scope clause is sufficient; no substantive scope change.

Open questions for Jeffrey

§2.1 choice (a) vs (b). Drop Write entirely, or keep Write + PreToolUse hook? Depends on whether Claude Code hooks are available in pilot runtime and whether you want main-thread to be a write-path for subagent text returns.
§2.2 choice (a) vs (b). Weaken the isolation claim or pay the 17-agent cost? Depends on how much you weight the math-olympiad analogy's literal transferability.
§18 choice (a) vs (b). Spawn 2 interpretation-checkers, or write the defensibility argument for the single-I asymmetry? (a) is cheaper to implement; (b) is cheaper to run.
§13.1 seeded-defect content. Which pattern to plant? #1a (lexical laundering) is the most testable and Cards 1, 2, 4 are already at risk for it, so a planted #1a creates calibration overlap. #18 (anchor underdetermination) or #19 (saturation-bridge) would test patterns that are less in-distribution for run3.
§16 keep-or-drop given verified isolation hole. Verification (2026-05-12) confirmed that teammates have peer-communication tools available regardless of tools: restrictions, so the agent-teams debate is a different mode from the main pilot path, not a continuation of it. Two options:
- (a) Keep §16 as documented post-isolation debate. Honest about the weaker guarantees; useful as an escalation tool for procedural deadlocks; complexity cost is two-modes-with-different-isolation.
- (b) Drop §16 entirely. Replace with "escalate to user" only. Simpler; avoids the cognitive load of two modes. The pilot is unlikely to need the escape hatch often enough to justify keeping it.

End patch list. After adoption decisions, regenerate plan as v4 with v4 changelog summarizing critical / high / medium adoption status and rationale for any rejected patches.

Adoption record (added at v4 land time)

All five open questions resolved by maintainer (2026-05-12) with Claude's adoption recommendations accepted:

§2.1 → option (b) — keep Write + PreToolUse hook (with pilot-prep smoke test required; fallback to behavioral enforcement if hook verification fails).
§2.2 → option (a) reframed — peer-output isolation explicit; cross-card view documented as taxonomy-informed methodological choice that enables #12 detection.
§18 → option (b) — single I subagent with starter-set prompt framing locking in safer reading.
§13.1 → planted-#1a-defect only (no seeded-clean control); seeded-clean rejected because wikiwip lacks ground-truth oracles for "clean card" calibration.
§16 → option (a) — keep documented-but-not-implemented for pilot, with verified isolation properties named explicitly.

Two maintainer-added patches landed in v4 outside Z's list:

§6 research scope discipline — replaced v3 hard caps with calibrated-budget + Scope-Mismatch self-flag at 10+ reads.
§7 hypothesis-note confidence tracking — Initial Confidence + Confidence Trace + Final Confidence fields; non-moving confidence becomes calibration signal for §10.

v4 plan at wiki/.audit/bridge-card-signoff-plan-v4-2026-05-12.md.