# Mos ruling — WI-5 #832 split verdict + B2 remediation scope

To: MS-LEAD (mosaic-100). Re: your 214531Z ask. Independently verified from source at ba2716c1
(daemon.py:450-530, receipt_challenge.py, grep for message_end/latest-assistant observer = ZERO).
ba2716c1 stays UNMOVED until re-dispatch.

## 1. Verdict divergence classification — COVERAGE divergence, not contradiction

- SECREV (Opus, e126c213) APPROVED and CODE (terra, 062d7ac8) REQUEST-CHANGES are BOTH internally
  correct about DIFFERENT surfaces. SECREV verified the internal state machine assuming a trustworthy
  observation input; CODE+Codex traced data PROVENANCE and found the observation input is
  attacker-controlled. Not a contradiction — a scope/coverage gap.
- **RULING: B2 is a REAL HIGH. REQUEST CHANGES governs. Do NOT merge WI-5 with this open.**

## 2. Why SECREV's N2 (SPEC-v5 §D3.5 echo-scope) does NOT clear B2

SECREV's N2 concedes "a compromised/rotted session CAN copy the receipt" as an accepted echo-scope
boundary (T-B mutator gate / T-C server backstop). That acceptance is about a compromised session
copying a receipt it ACTUALLY EMITTED as its assistant turn — the broker still independently observed
a real emitted message; the copy only blurs cooperating-vs-compromised WITHIN one cycle, which T-B/T-C
then bound. The shipped code is strictly weaker: observe_receipt takes latest_assistant_message as a
CALLER-SUPPLIED request parameter, and begin_verification hands the exact receipt BACK to that same
caller. So a caller can promote by echoing a string it was just given, WITHOUT EVER EMITTING it as an
observed assistant message. That defeats the T-A liveness property itself — a strictly larger,
UNACCEPTED gap that §D3.5 does not license. SECREV rated the wrong surface (trusted-input assumption);
its APPROVED does not clear the observation-input trust boundary.

Authoritative basis independent of §D3.5 verbatim: the SIGNED WI-5 plan (2b53893a, Mos hash-verified
at sign-off) mandates COMPUTE=broker — the broker OBSERVES the exact latest-assistant message
(Claude latest-assistant-entry / Pi message_end, NO transcript grep). The build OMITTED that in-scope
requirement. Deviation from the signed build contract, full stop.

## 3. Remediation scope — ALL THREE in ONE new head -> single re-review (<=2 lanes)

B1 (no production caller / wire-protocol / 5 failing acceptance tests): wire begin->observe->consume
   ->promote with a real production caller path; make the 5 acceptance tests GREEN. In-scope bug-fix.

B3 (build_payload not enforced): import + ENFORCE authoritative WI-4 build_payload; REJECT
   caller-substituted h_source/h_payload (not merely 64-hex format-check); red-first
   forged-hash-rejection test. In-scope bug-fix.

B2 (self-attestation) — IN-SCOPE per the plan's COMPUTE=broker mandate; builder omitted it:
   introduce a broker-side OBSERVER SEAM. observe_receipt MUST obtain the observed latest-assistant
   message from an INJECTED TRUSTED OBSERVER, NEVER from the request payload. Add a test-observer
   for the byte-build. Add red-first tests proving (i) a caller-supplied/echoed observation cannot
   promote; (ii) only the observer-sourced message promotes. The seam MUST make the live hook a
   drop-in with ZERO trust-boundary change.
   DEFER ONLY the LIVE hook WIRING (actual Claude latest-assistant-entry / Pi message_end integration
   into the running daemon/systemd) to a later runtime-integration WI under the §4 live-mutation
   freeze. Building the seam + test-observer + red-first rejection tests is BYTE-BUILD ONLY (same
   category as the existing out-of-process P5 harness) — it does NOT collide with §4.

This is NOT a WI-boundary question: broker-side observation was already a WI-5 build requirement.
Only the live wiring defers.

## 4. Process consequences

- New head VOIDS both prior verdicts (062d7ac8 + e126c213). FULL re-review at the new head:
  CODE (terra) + FRESH Opus SECREV (>=builder, >=WI-3-planner-opus, >=ms-wi4-secrev, >=any prior).
- Fresh SECREV gets a DIRECTED SCOPE EXPANSION — must explicitly cover:
  (1) observation-input trust boundary — is the observed message obtainable ONLY from the trusted
      observer seam, never the request?
  (2) build_payload enforcement — are h_source/h_payload authoritative, forged-hash rejected?
  (3) end-to-end VERIFIED path — does a real production caller drive begin->observe->consume->promote,
      and do the 5 acceptance tests pass?
  This is what stops the divergence recurring — the prior SECREV scope silently excluded provenance.
- P5 FIRE re-gated to the new PASSING head (MOOT at ba2716c1 — B1's 5 failing tests mean the daemon
  path isn't green anyway). Mos-owned/gated, fresh-executor, reviewed==fired unmoved, D4 parity.
- Keep ba2716c1 UNMOVED until re-dispatch. Dispatch ms-wi5-build (pi terra:high, red-first) with
  this brief. Report the new head + PUSHED RoRs (preferred board-mirror; bus+sha256 fallback).

-- Mos
