Proof-Level Taxonomy and Capability Matrix

For current project truth, defer to `docs/STATE.md` and `docs/PHASE_PROGRESS.md`. This map adds a shared proof-level vocabulary and a capability matrix for the current organizer-rehearsal path. It is a claim-boundary aid, not a new source of truth. For how these proof levels feed the broader claim-discipline rules (forbidden collapses, inventory/PR checklist, two firewalls), see `claim-boundaries.md`.

This map exists for issue #1796 and directly supports the organizer-rehearsal milestone #1746. ICN now has many overlapping readiness states — implemented, partial, fixture-backed, local proof loop, live daemon proof, K3s/devnet proof, design-only, stale, aspirational. Without shared proof language, a contributor, facilitator, reviewer, or agent can accidentally over- or under-claim. This doc gives everyone the same words so the current demo/rehearsal state is honest, legible, and reusable.

It answers, for each capability: what is real, what is fixture-backed, what runs locally, what has live-daemon proof, what is partner-rehearsal-ready, what is not production, what privacy boundary applies, and which issue/PR owns the next step.

Proof-level taxonomy (L0–L8)

Proof levels are claim-boundaries, not moral rankings. A higher level is not "better" and a lower level is not "bad" — the level states how much evidence backs a claim so the claim does not outrun the proof. A schema-only contract at L1 may be exactly the right maturity for its purpose; calling it L5 would be the error.

Levels are not strictly cumulative across axes: a capability can have a live path (L5) on a single node while its multi-node story (L6) is unproven, and a contract can be schema-validated (L2) without ever touching a daemon (L5). State the level that matches the strongest honest evidence, and note the gaps.

Relationship to the existing status vocabulary

This taxonomy does not replace the implementation-state vocabulary in `project-coverage-matrix.md` (implemented, implemented but partial, feature-gated, fixture-backed, package-local, design-direction, historical, unknown). The two are orthogonal axes:

• Status answers "is the code written, and how completely?"
• Proof level answers "how much verification evidence stands behind the claim?"

A surface can be implemented (status) yet only L2 (proof) because no integration or live evidence has been recorded. Use both: status for what exists, proof level for what may be claimed. Rough alignment, not a lookup table:

Capability matrix (organizer-rehearsal path)

Evidence is grounded in merged commits on main and committed artifacts. `STATE.md` and `PHASE_PROGRESS.md` are the canonical state documents and have been truth-synced through the later June 2026 cycle (the earlier #1985→#1999 receipt-chain/rehearsal cycle is now recorded on main). This matrix is an indexed proof-level view, not the root state authority: where it and STATE.md / PHASE_PROGRESS.md disagree, the canonical state documents win (per the source-of-truth hierarchy in `source-of-truth-map.md`).

Per-capability detail

The table above is the scannable view. The prose below carries the honest claim-boundary fields (real now / fixture-only / public wording / known gaps) that do not fit a cell.

1. Live receipt-chain audit path / 13-of-13 proof — L5.

• Real now: a governed proposal → vote → close → allocation flow runs against a real icnd + gateway and icnctl audit verify --token --json reports a complete 13/13 receipt chain.
• Fixture-only / mocked: none for the path itself — data is fictional, the gateway is real, ephemeral, loopback, and dev-gated.
• Public/demo wording: "live daemon/gateway proof of the 13/13 governed receipt chain on a local ephemeral node — proof of path, not proof of deployment readiness."
• Known gaps: single-node loopback only (no multi-node / L6); CI run is gated by the disk flake in #1955.

2. Durable effect dispatch evidence — L3. Real now: ExecutionRecord.results is persisted and an idempotent startup backfill reconstructs missing dispatch evidence. Fixture-only: none. Public/demo wording: "dispatch evidence is durably persisted and recovered on startup." Known gaps: durability is proven by tests, not by a recorded live multi-restart drill.

3. Dispatch-evidence recovery / backfill — L3. Real now: the backfill scan uses cursor/seek pagination (not offset), removing the crash-window and O(n²) concerns. Fixture-only: none. Public/demo wording: "recovery scan is bounded and crash-safe." Known gaps: recovery is unit/integration-proven, not exercised under a recorded fault-injection run.

4. Decision-hash ledger lookup / index — L3. Real now: ledger entries are indexed by decision_hash, fixing the crash-window and O(n²) lookup concerns. Fixture-only: none. Public/demo wording: "decision-hash lookups are indexed." Known gaps: none material at this level.

5. One-command local receipt-chain rehearsal — L4. Real now: one operator command spins a fresh ephemeral node/gateway, asserts 13/13, emits a repo-safe evidence packet conforming to urn:icn:contract:rehearsal-evidence-export:v1, validates it, and prints what is real / dev-gated / fixture-only / NOT production. Fixture-only: fictional inputs; all outputs are gitignored. Public/demo wording: "one-command local proof loop — not production, not a pilot, not live federation." Known gaps: requires a local build of icnd/icnctl; single node.

6. Pending-publish summary row contract — L2. Real now: a stable schema (urn:icn:contract:pending-publish-summary:v1, JSON Schema draft 2020-12) with a fictional example that validates via docs/scripts/validate-preview-review.py --schema; documented composition with urn:icn:contract:preview-review:v1 (#1745). Fixture-only / mocked: it is a read-model contract — it describes the rows an organizer was shown; it performs no mutation, implements no HTTP endpoint, and authorizes no formal pilot. Public/demo wording: "schema/contract for the pending-publish review row — read-model only, no endpoint, no mutation, not a formal pilot authorization." Known gaps: no producing endpoint binds to it yet.

7. Fixture-backed organizer rehearsal shell — L2. Real now: a demo-mode shell renders committed fictional fixtures (rehearsal-shell.manifest.json), validated by docs/scripts/validate-rehearsal-shell-fixtures.py. In addition to Standing and Action Cards, #2237 renders the preview-review wrapper and canonical-matched pending-publish rows as a plain-language, read-only Review Preview; every review choice is disabled, the browser fixture is schema-valid and mechanically matched to the canonical example, and Playwright/axe covers the rendered surface. Fixture-only / mocked: entirely — there is no live daemon, persisted review decision, mutation, issued receipt, or evidence export behind the shell in demo mode. Public/demo wording: "fixture-backed organizer review preview and participation shell (demo mode) — bounded fictional rehearsal artifacts; no decisions recorded, not live, not a formal pilot." Known gaps: not wired to a live preview/review endpoint; no human/assistive-technology pass; not a partner rehearsal (L7); the full participation surface and organizer walkthrough remain under #1746.

8. /me/action-cards / standing-derived participation queue — L5 (live), L6 partial. Real now: GET /v1/gov/me/action-cards emits proof-bearing receipt loops for three of five source paths (proposal/vote, action_item/complete, meeting/attend), with both a local HTTP proof loop and a homelab K3s smoke proof loop recorded (see `current-truth-map.md`). Fixture-only / mocked: the two remaining source paths (signal_rule, obligation_lifecycle) are RFC-gated under #1646 and not emitted. Public/demo wording: "three of five currently emitted source paths, live — show three of five, not five of five." Known gaps: #1631, #1634, then #1646.

9. Private-data disclosure boundary / scoped vault model — L1 (design). Real now: a design-level spec names the ScopedVault boundary and the forward-direction DisclosurePolicy / PrivacyClass / PrivateObjectRef / AccessReceipt / ExportReceipt / RedactionMap vocabulary; an icn-privacy crate exists. Fixture-only / mocked: disclosure enforcement is not implemented at runtime. Rehearsal privacy today is achieved by exclusion (repo-safe-by-construction packets, fictional fixtures), not by an enforced disclosure boundary. Public/demo wording: "design-direction scoped-vault / disclosure model — NOT private-data handling; rehearsal privacy is by exclusion, not enforcement." Known gaps: wire-stable schema, encryption/key model, and runtime enforcement are all deferred (#1792, #1798, #1767).

10. NYCN organizer rehearsal milestone (overall) — components L2/L4/L5; L7 OPEN. Real now: the kernel can prove (L5 receipt chain, L4 one-command rehearsal) and the rehearsal shell + contracts can rehearse (L2). Fixture-only / mocked: the integrated organizer-facing operable rehearsal — the participation surface joining the live proof loop to the rehearsal shell — does not exist yet. Public/demo wording: "fixture-backed organizer rehearsal plus a local proof loop; the operable participation surface is the open milestone — not a formal pilot, not live federation, not production." Known gaps: the participation surface (#1746); disclosure enforcement (#1792); the accessibility/privacy checklist below; the NYCN dogfood gossip-port preflight bug (#1956); CI disk flake (#1955).

11. DEV/DEMO appliance image — single-actor loop in one VM — L5 (stranger-runnable local proof). Real now: ICN_APPLIANCE_DEMO_PROFILE=1 produces a reproducible bootable VM image (a template, not a physical device) that a stranger can build from public main and boot in QEMU/KVM. A node instance booted from it serves the member-shell and runs the full single-actor spine — standing → action card → discharge → receipt → evidence/audit — plus an in-VM 13/13 governed receipt-chain audit (sudo icn-demo-verify --chain; the in-VM helpers run as root). Fixture-only / mocked: the institution is the fictional NYCN fixture package; the shell's ?mode=demo panes are fixture-backed. Terminology (use precisely): the appliance image is a reproducible VM image/template; a running node instance is a VM booted from it; the hypervisor host (Proxmox/KVM/cloud/local machine) runs one or many node instances; org/domain assignment and any future QR claim ceremony apply to a running node instance, never to the generic image and never to a physical box. Public/demo wording: "one local DEV/DEMO node instance proving the single-actor loop — not production, not a pilot, not federation, not multi-person, unsigned image, fictional data." Known gaps / next lanes (not built): multi-person interaction (two-member action flow), QR node-claim ceremony, commons resource allocation.

12. Summit Ops Registration Desk lane — action-card fixture — L2 (fixture/demo). Real now: a committed fictional Registration Desk action_item/complete ActionCard (demo-card-action-item-complete-registration-001) in web/pilot-ui/fixtures/icn-organizer-demo/action-cards.json, with a matching demo Logistics Committee role granting registration_desk in standing.json (so the card is derivable from holder standing). Validated per-card against `action-card.schema.json`, by docs/scripts/validate-rehearsal-shell-fixtures.py, and by the pilot-ui e2e web/pilot-ui/tests/e2e/demo-fixture-preload.spec.js + the "Rehearsal Fixture Bundle" CI gate (#2209). Docs: `summit-ops-registration-action-card-proof-loop.md`, `summit-ops-registration-fixture-shape.md`. Fixture-only / mocked: entirely — a committed fictional fixture the rehearsal shell loads/validates; there is no live daemon and no action-card→receipt runtime loop for this lane. Public/demo wording: "L2 fixture-backed Registration Desk card — committed fictional fixture, not runtime proof, not live NYCN action cards/receipts, not a node-hosted Summit Ops cockpit, not organizer-ready (L7), not a formal pilot, not production; no Google sync, no private data." Known gaps: #2209 added one data fixture, not the full registration action register. The #2099 Pilot UI security gate is closed with its default-branch alerts verified fixed, so the next bounded slice may render the full fictional registration action register under #1746; that work is not included in #2237's generic Review Preview.

Public / demo wording discipline

This section names the language that keeps claims inside the proof boundary. It is the proof-level lens on the project's existing red lines — for the full list (no crypto/token framing, regulatory vocabulary, no NYCN commitment claim, no live-federation claim), defer to `show-readiness-map.md`.

Prefer (these stay inside the proof boundary):

• "fixture-backed organizer rehearsal"
• "local proof loop" / "live daemon/gateway proof"
• "not production" / "not a formal pilot authorization" / "not private-data handling"
• "bounded rehearsal artifact"
• "proof of path, not proof of deployment readiness"

Avoid (these claim past the evidence):

• "production-ready", "fully federated", "live pilot", "secure by default"
• "complete platform", "partner deployed"
• "ready for organizers" — unless the accessibility/privacy checklist below and the #1746 acceptance conditions are both satisfied.

Accessibility and privacy readiness (gate for "organizer-facing")

A capability does not reach L7 (partner / organizer rehearsal) on engineering proof alone. Anything presented as organizer-facing must also satisfy:

• Plain-language labels — no internal jargon, URNs, or hashes as the primary label.
• Screen-reader / non-visual compatibility — every state reachable and meaningful without sight.
• Color-independent meaning — status never carried by color alone.
• No raw private paths or Drive URLs in public fixtures — fictional data only.
• Clear fixture-vs-live labeling — the viewer always knows whether they are looking at a fixture or a live result.
• Visible non-claims — "not production / not a formal pilot / not live federation" stays on the surface, not buried in a footnote.
• Visible receipt / evidence boundaries — what is proven vs described vs expected is legible.

This checklist is why capability #7 (the fixture-backed shell) is L2, not L7: the shell exists, but the organizer-facing accessibility/privacy bar and the live participation surface are open under #1746. Disclosure enforcement that would make private organizer material safe to handle is design-only under #1792; until it lands, organizer rehearsal stays on fictional fixtures. See `docs/design/ACCESSIBILITY_BASELINE.md` for the baseline this checklist draws on.

Non-claims

This map does not claim:

• production readiness for any capability;
• a formal NYCN pilot, partnership, or signed agreement;
• live federation between cooperatives;
• private-data handling readiness (the disclosure boundary is design-only);
• that the fixture-backed rehearsal shell runs against a live daemon;
• that any committed demo fixture (e.g. the Registration Desk card, row 12) is a runtime proof — committed fictional fixtures are L2 demo evidence only.

When to update this map

• A capability's strongest honest evidence changes (a new test, a live run, a recorded devnet proof) → bump its proof level.
• A new capability enters the organizer-rehearsal path → add a row plus a detail block.
• A STATE.md / PHASE_PROGRESS.md sync changes a capability's recorded state → reconcile the affected rows here (the canonical state documents win).
• The accessibility/privacy checklist or #1746 acceptance conditions change → revisit which capabilities may be called organizer-facing (L7).

Where to read deeper