A proposal for the five MARY-REUSE questions Lane L6 left open

Date: 2026-09-24 Status: proposed Supersedes: none Superseded-by: none — current

Context

irina/FANOUT.xml Lane L6 (“MARY-REUSE”) posed five <must_answer> questions about IRINA’s relationship to mary-wiki’s console-roster governance model. irina/SYNTHESIS.md synthesised v1’s six lane returns and answered the first of the five in passing, as its C4 contradiction (“roster placement, and a name collision”) — a NO SLOT finding, with a named complication (FIDO/ROLAND sits proposed, gated on DEC-APEX-0004). irina/SYNTHESIS.md §7 (“What MARY actually lends — disciplines, not schemas”) did further preliminary work on the third, fourth and fifth questions, without labelling them as L6 answers. Nothing in the corpus has stated a position on all five, individually, in one place.

irina/IRINA-SCOPE-FANOUT-2.xml — the ratified v2 fan-out that IR-001..018 actually executed against — carries zero references to MARY (confirmed: grep -c MARY irina/IRINA-SCOPE-FANOUT-2.xml returns 0). L6 was not carried forward. That is consistent with the north star’s own framing: the “alongside MARY” question was descoped in the v1-to-v2 re-narrowing, not answered and not ruled out.

This document is not that re-opening. It is a cheap starting point for one, should FLIGHT choose to authorise it: a reasoned candidate stance on each of L6’s five questions, built on §5/§7 of irina/SYNTHESIS.md rather than repeating that reasoning, and checked against mary-wiki’s own docs/APEX-MAP.md rather than against this brief’s summary of it. It proposes nothing to ratify by itself — see Status, below, and the countersign discipline in docs/decisions/2026-08-10-countersign-gates-closed-status.md.

Sources read for this pass

irina/FANOUT.xml (Lane L6, “MARY-REUSE”) — the five questions as posed.
irina/SYNTHESIS.md §5 (contradiction C4) and §7 (“What MARY actually lends”) — the preliminary reasoning this proposal builds on.
irina/IRINA-SCOPE-FANOUT-2.xml — confirmed zero MARY references.
~/code/workspace/mary-wiki/docs/APEX-MAP.md — read directly for the CAPCOM charter line, the FIDO/ROLAND entry, and DEC-APEX-0004’s status, rather than trusting this brief’s paraphrase of any of them.

Proposal — one stance per L6 question

Each of the five is answered independently. None is resolved by appeal to “the others agree” — a distinct stance per question was a stated failure mode to avoid.

1. Console-roster slot — is IRINA a console, a god, an ASCAN, or NO SLOT?

Candidate answer: NO SLOT, and the proposal is to ratify that finding rather than re-litigate it. irina/SYNTHESIS.md §5/C4 already argues this from the roster’s own distinctions: IRINA is not a god (gods are unspeakable; she is addressed directly), not an ASCAN (her acts are ASCAN-shaped but her scope is not bounded the way an ASCAN’s is), not a console (consoles act on the facility; IRINA acts on the control plane that governs the facility — a containment inversion, not a matter of degree). mary-wiki’s own registry entry already says the same thing in a different vocabulary: petrova-codes’ registration in that repo’s terms is profile: strict, fleets_allowed: [] — machine-readable confirmation that no agent, IRINA included, is admitted to operate inside mary-wiki today.

The complication C4 names — FIDO/ROLAND (DEC-APEX-0004, confirmed proposed (activate when fleet ops go live) in mary-wiki/docs/APEX-MAP.md line 54) chartered for “fleets, trajectories, convergence” — is real but does not change the answer. FIDO is a mary-wiki-internal annex specialist, sealed behind @rocky/contracts, speaking only through that wall, governed by Kvasir. IRINA is not a fleet inside mary-wiki’s own ROCKY/RALPH/KAHN domain; she is an external control-plane process that happens to share a subject-matter neighborhood with FIDO’s charter. Activating FIDO and admitting IRINA are not the same act and this proposal takes no position on whether FIDO should activate — that is entirely mary-wiki’s own governance, untouched by petrova-codes by design (per this repo’s ownership-boundary convention: petrova-codes governs mary-wiki like any other consumer and nothing more).

Stance: NO SLOT stands. No new roster entry, no FIDO activation as a side effect of this proposal.

2. CAPCOM collision — does IRINA-as-dispatcher violate the “sole voice loop” charter?

mary-wiki/docs/APEX-MAP.md line 115 confirms the charter as read: “CAPCOM | WAZOWSKI | Sole voice loop for dispatch | active.” That is a claim about dispatch inside mary-wiki’s own apex, not a claim about every dispatch occurring anywhere in the fleet — DW-APEX-08 (line 77) makes the boundary explicit: “No Odysseus-resident (cabin) agent acquires an apex identity, a callsign, or a door. Cabin tools stay in the cabin; real dispatch exits via CAPCOM.” That rule governs agents resident inside mary-wiki’s own Odysseus/cabin topology reaching for apex identity. IRINA is not Odysseus-resident; she is a petrova-codes process that, per SURFACES in the brief, never calls into MARY today (DARK boundary — no code, doc, or RPC crosses it).

Stance: no collision exists today, because the surfaces don’t touch. The collision becomes live only if a future design has IRINA dispatch work that lands inside mary-wiki — e.g. a PR against mary-wiki, or an act routed through mary-wiki’s own agents. If that is ever proposed, the correct shape (consistent with §7’s routing duties, below) is for IRINA to hand such a dispatch to CAPCOM as the sole voice loop, never to emit it directly against mary-wiki. This proposal does not authorise IRINA to dispatch into mary-wiki in any form; it merely notes the rule that would apply if someone later asks for that.

3. Envelope coupling — should IRINA’s acts be Task Envelopes?

irina/SYNTHESIS.md §7 already reasons through this under “Adapt, don’t adopt”: the Task Envelope’s P0–P3 field is the only existing near-miss for an autonomy ceiling anywhere in the corpus, so the idea is worth having, but importing docs/envelope.schema.json literally would couple PETROVA operations to mary-wiki’s decision-governed runtime contract across a change-rate mismatch, and stamping an envelope is CAPCOM’s chartered act — an IRINA-stamped envelope would be either forged (claiming CAPCOM’s stamp) or self-issued (which §7’s hazard paragraph separately rules out: an agent that decides its own ask-condition holds a fraction of the gate).

Stance: adapt, don’t adopt — this proposal reaffirms §7’s position rather than reopening it. If a seam-class ceiling for PETROVA verbs is ever carried (SYNTHESIS §1.1 already found no such field exists today — FR-003 “is today prose with no mechanism”), it should borrow the discipline — a named issuer, a trace id, a declared level, refusal as an outcome not an error — and define it as a first-class PETROVA field, not as a borrowed envelope.schema.json import. That is future work for petrova-codes alone; it requires no mary-wiki change and does not touch irina/FANOUT.xml or the ratified v2 scope.

4. Duty routing — which candidate IRINA duties are already chartered elsewhere?

This is the one question §7 already answers completely and explicitly, in its “Duties to ROUTE, not absorb” table. This proposal does not re-derive that table; it adopts it as the answer to L6’s fourth question and restates its conclusion for traceability:

EECOM owns filing findings and stated contradictions — IRINA emits the trace, never writes docs/findings/ herself, never resolves a conflict.
FAO owns FLIGHT’s timeline (briefs, cadences, MET) — IRINA emits status; FAO composes.
BOOSTER owns heavy/retryable execution, idempotency, retry, rollback.
PAO owns anything outbound, fail-closed INTERNAL by default.
FLIGHT owns every ratification, never delegated.

Stance: adopt §7’s routing table as the answer. No duty on that list is proposed for IRINA to absorb. The one open item is procedural, not substantive: today IRINA has no live channel to emit a trace that any of these chartered consoles could receive, because the MARY boundary is DARK. Building that channel is exactly the “alongside MARY” work this whole document exists to make cheap to authorise, not something this proposal does on its own authority.

5. Intelligence reuse — what in MARY is genuinely reusable, not just structural?

§7’s “Reuse as-is” list already answers this with specifics: CAPCOM’s stamping discipline as a rule (named issuer, trace id, declared level, refusal as outcome); DOOR-* record discipline (no endpoint without a record — SYNTHESIS calls out that IRINA holding her own ad-hoc endpoint list is the failure this discipline prevents); FR-017 (a blocking check needs its own admitting decision); PUB-SPEC’s fail-closed INTERNAL default; and two epistemic habits — “refuse vs prevent is an empirical distinction, not a label” and “distrust a document’s prose about itself, re-derive from the tool or the tree.” §7 also names what not to take: bin/checks-registry.json as a record (16 real checks, zero PREVENT primitives — copying the pattern inherits the vacuity), and MARY’s residue-chasing reflex without its missing stop rule (SYNTHESIS’s own drain- time stop rule in §2 is presented as the corrective IRINA already has that MARY does not).

Stance: adopt §7’s reuse list as the answer, with one addition surfaced by this pass’s direct read of mary-wiki/docs/APEX-MAP.md. DW-APEX-04 (line 73) — “Annex agents… communicate only through versioned contract schemas. An annex payload crossing the wall without schema validation is drift” — is a second reusable discipline in the same family as DOOR-* and FR-017: any future IRINA↔mary-wiki channel (were one ever built) should be schema-validated at the wall, the same way @rocky/contracts validates ROLAND’s. This is offered as an addition to §7’s list, not a contradiction of it, and it commits nothing — no such channel exists or is proposed here.

What this proposal is not

Not a ratification of anything above. Status: proposed. No section here authorises code, an RPC, a schema change, or a new MARY-facing surface.
Not an edit to irina/FANOUT.xml, irina/SYNTHESIS.md, or irina/IRINA-SCOPE-FANOUT-2.xml — all three were read-only sources for this pass.
Not a reopening of “alongside MARY” as a new fan-out. Per the brief’s own framing, only FLIGHT can authorise that. This document’s job is to make that authorisation cheap to grant, amend, or refuse — not to grant it.

Alternatives considered

Leave L6 permanently closed by omission (the status quo since v2 dropped it) — rejected as the default outcome of inaction, not as a reasoned answer. The north star’s own HANDOFF section already flags that “18/18 closed” says nothing about MARY; leaving the five questions unanswered indefinitely lets that silence keep reading as resolution.
Answer all five with one combined verdict (“MARY is out of scope”) — rejected as the vague-consensus shape this document was explicitly asked to avoid. Each question has a different mechanism (roster taxonomy, charter collision, schema coupling, duty ownership, discipline transfer) and collapsing them loses the two places (questions 2 and 5) where the answer is conditional rather than flatly negative.
Fully re-derive C4 and §7 from scratch instead of citing them — rejected: the brief specifically asked this node to build on that preliminary reasoning, not repeat it; duplicating it here would also risk drifting from the source under irina/, which stays canonical.

Consequences

If FLIGHT ratifies this proposal as-is: L6’s five questions get a standing answer in docs/decisions/, citable independently of irina/SYNTHESIS.md’s prose (which is itself scoping output, not a specification, per its own front matter). No code or schema changes follow directly — every “stance” above either reaffirms existing findings or explicitly declines to authorise new work.

If FLIGHT amends it: the natural amendment points are question 2 (if a future design does want IRINA dispatching work that lands in mary-wiki) and question 4 (if FLIGHT decides to open the channel that would let IRINA emit traces to EECOM/FAO/PAO for real).

If FLIGHT rejects it: L6 stays formally unanswered and “alongside MARY” remains the dormant thread the north star describes it as — this document changes nothing about that state until signed.

References

irina/FANOUT.xml — Lane L6 (“MARY-REUSE”), the five questions as posed.
irina/SYNTHESIS.md — §5 contradiction C4 (roster placement), §7 (“What MARY actually lends — disciplines, not schemas”).
irina/IRINA-SCOPE-FANOUT-2.xml — ratified v2 scope, zero MARY references.
mary-wiki/docs/APEX-MAP.md — CAPCOM charter (line 115), DW-APEX-08 (line 77), DW-APEX-04 (line 73), FIDO/DEC-APEX-0004 (lines 54, 118).
docs/decisions/2026-08-10-countersign-gates-closed-status.md — the countersign discipline this document follows: unchecked box, Status: proposed, never self-ratified.

Sign-off

Subagent: mary-alongside-scope-proposal node (session 2026-09-24)
Human: FLIGHT — that this stance on each of L6’s five questions is accepted, amended, or rejected, and (if accepted) whether “alongside MARY” should be reopened as a new fan-out on this basis.