Organizer Rehearsal Operability Map

For current project truth, defer to `docs/STATE.md` and `docs/PHASE_PROGRESS.md`. This map is an orientation aid, not a source of truth: it reads the already-merged generated evidence surfaces (route inventory, icnctl command inventory) and the capability matrix, and translates them into "what can safely be shown to an organizer, what is fixture-backed, what needs a steward/operator, and what must not be claimed yet." It changes no behavior and grants no readiness. The claim-discipline rules behind these distinctions (forbidden collapses such as wired route ≠ organizer-ready) are collected in `claim-boundaries.md`.

Purpose

The organizer-rehearsal milestone (#1746) frames the gap plainly: the kernel can prove, the NYCN package can rehearse, and the missing piece is the participation surface between them. The vertical institutional spine (#2141) names the path that surface must eventually carry:

package → domain → policy → binding → process/action → receipt → surface → evidence/export

This map does not build that surface. It uses the two mechanical evidence surfaces that landed in the route/CLI-inventory lane — the generated route inventory (#2112) and the generated `icnctl` command inventory (#2113) — to answer, for an organizer rehearsal:

1. What can be shown to organizers now?
2. What is fixture-backed / demo-only?
3. What requires a steward/operator rather than a non-technical organizer?
4. Which routes support the surface at L1 only?
5. Which icnctl commands are relevant but still unknown / needs local verification?
6. What must not be claimed?
7. What are the smallest next slices to make the rehearsal operable?

It is deliberately conservative: where the generated inventories prove only that a declaration exists, this map says so and points at the capability matrix for the places where stronger, recorded proof exists.

How to read the evidence (two layers, do not conflate)

This map draws on two different kinds of evidence, and keeping them apart is the whole point:

• Generated inventories (declaration evidence, proof level L1). The route inventory and `icnctl` command inventory are mechanically generated from source. They prove a route macro / registration site or a clap command declaration exists at a snapshot commit — nothing more. Every entry is uniformly L1 / unknown / needs local verification. A declaration is not evidence of correctness, auth, mounting, live wiring, tests, or organizer-safety.
• Capability matrix (recorded-proof evidence, L0–L8). The proof-level taxonomy and capability matrix records, per rehearsal capability, the strongest honest proof that has actually been observed (e.g. an L4 one-command local proof loop, an L5 live daemon path), each tied to a merged PR.

Rule used throughout this map: a route or command is cited at L1 (declaration only) unless the capability matrix records a higher proof level for that specific path, in which case the higher level is cited with its matrix row. When the two disagree, `docs/STATE.md` wins (per the source-of-truth map).

All status labels below come from the existing vocabulary in the source-of-truth map (implemented, implemented but partial, feature-gated, fixture-backed, gateway-backed, docs-only / design-direction, package-local, private-boundary, unknown / needs local verification). No new status vocabulary is introduced.

Current evidence surfaces

What is safe to show now

These are real and may be presented honestly to organizers, bounded to the recorded proof level. Each row pairs the organizer-facing thing with the generated declaration evidence and the recorded proof.

What is fixture-backed

fixture-backed (matrix row 7, L2) — demonstrated through committed fictional fixtures only; no live daemon behind them. Show these as rehearsal artifacts, never as live participant state:

• The organizer rehearsal shell in demo mode (web/pilot-ui/fixtures/icn-organizer-demo/, web/member-shell/).
• The shell's ?mode=demo Review Preview, standing, and Action Card panes. Review Preview renders the contract wrapper and canonical-matched pending-publish rows with disabled choices; it records no decision and performs no mutation (#2237).
• The fictional NYCN fixture institution used by the appliance image and the rehearsal packet.
• The pending-publish summary contract example (urn:icn:contract:pending-publish-summary:v1) — a read-model contract with a validating fictional example (matrix row 6, L2), now rendered by Review Preview from a mechanically matched browser fixture; no producing endpoint binds to it yet.

Demo fixtures prove UI rendering and contract shape. They do not prove live participant state, live federation, production readiness, or formal pilot status (per the source-of-truth map, "Demo fixtures vs live state").

What requires steward/operator handling

These are not for a non-technical organizer to run. They require a steward/operator with a local build and a terminal, and most are gateway-backed (need a running daemon/gateway) — a higher bar than the inventory's L1 declaration. The commands below are cited at L1 (declaration exists) from the command inventory; their operation is unknown / needs local verification except where the capability matrix records a proof loop.

The milestone's definition of done is explicit: a facilitator shows the workflow without asking organizers to run a terminal command, and a steward can reproduce the same path from fixtures with existing local commands (#1746). This map keeps the two roles separate by construction.

What is not organizer-ready

Per the show-readiness map red lines and the capability matrix, the following must not be presented to organizers as finished or ready:

• An operable, integrated organizer participation surface. The surface joining the live proof loop to the rehearsal shell is the open milestone (#1746); L7 (partner/organizer rehearsal) is OPEN (matrix row 10). The shell is L2, not L7, precisely because the accessibility/privacy bar and the live participation surface are not yet met.
• Private organizer/member/sponsor data handling. Disclosure enforcement is design-only (L1, matrix row 9). Rehearsal privacy today is by exclusion (fictional fixtures, repo-safe-by-construction packets), not by an enforced boundary — private-boundary.
• Multi-person interaction. The appliance proves a single-actor loop (matrix row 11); two-member action flow and any QR node-claim ceremony are future lanes, not built.
• The other two action-card source paths. signal_rule and obligation_lifecycle are RFC-gated (#1646) and not emitted — show three of five, not five of five.
• A formal NYCN pilot, live federation, or production readiness. None of these are claimable (red lines, show-readiness-map).

Route evidence used (L1 declarations unless matrix cites higher)

From the generated route inventory. Every entry is L1 / unknown / needs local verification as proven by the inventory; the "stronger proof" column points to the capability matrix where a recorded proof exists.

Reminder: OpenAPI presence proves a path is documented, not served; a served route does not prove it is public-safe (runtime-surface-map).

CLI evidence used (L1 declarations unless matrix cites higher)

From the generated `icnctl` command inventory (162 default-build commands; 1 feature-gated; 0 unparsed). All entries are L1 / unknown / needs local verification; role is a curated navigation heuristic, not a safety assertion.

The 1 feature-gated command (icnctl id upgrade-pq, cfg(feature = "post-quantum")) is not in the default build and is not part of the rehearsal path.

Nonclaims

This map:

• Does not mark the organizer rehearsal ready (L7 is OPEN, #1746).
• Does not claim a formal NYCN pilot.
• Does not claim production readiness.
• Does not claim live federation.
• Does not claim Phase 2 completion.
• Does not claim route runtime correctness from route declarations.
• Does not claim CLI runtime correctness from clap declarations.
• Does not ask non-technical organizers to run terminals.
• Does not introduce any private NYCN/organizer/member data (fictional fixtures only).
• Does not alter route behavior.
• Does not alter icnctl behavior.
• Does not start A2e enforcement cutover.
• Does not affect #2082.

Next slices

The smallest claim-safe steps that move the rehearsal from "evidence exists" toward "operable," each a candidate child of #1746 / #2141:

1. Identify the minimal rehearsal path — pin the single end-to-end story (standing → action card → discharge → receipt → evidence) to the specific routes/commands above, so facilitator and steward read from one path.
2. Map the steward/operator commands needed — promote the steward-only icnctl set above into a per-command status pass (the #2113 follow-up): which are gateway-backed and proven, which remain unknown / needs local verification.
3. Map the routes/surfaces rendered to the organizer — confirm which /gov/me/* read models the shell actually renders, and bound each to its recorded proof (not its L1 declaration).
4. Run the human accessibility pass — Review Preview clears automated Playwright/axe checks, but screen-reader, 200% zoom, external contrast-tool, and non-mouse/assistive-technology evidence remain owed before any organizer-ready claim.
5. Produce a no-terminal facilitator path — join the fixture-backed Review Preview → Standing → Action Cards → receipt/evidence story into a walkthrough a facilitator can show without a terminal, with the accessibility/privacy checklist applied as a gate. This remains below the #1746 definition of done until an organizer-oriented walkthrough is actually recorded.

Where to read deeper