Eve SOTA gap → task → evidence → exit matrix — 2026-09

Initiative: eve-sota-gap-closure-2026-09-01
Machine record: eve-sota-gap-task-evidence-exit/2026-09-01.json
Schema: eve-sota-gap-task-evidence-exit.schema.json
Required verifier: ../../tools/eve-everywhere/verify-gap-task-evidence-exit.mjs

This record assigns all 211 ledger tasks exactly once as an owner and covers all 18 registered gaps. 94 rows currently have direct evidence and 117 remain planned/open. Planned evidence is an admission contract, not a completion claim.

Admission command#

node tools/eve-everywhere/verify-gap-task-evidence-exit.mjs

The verifier re-parses the authoritative ledger, recomputes both its whole-file SHA-256 and the pinned exact-task-requirements SHA-256, and refuses missing or duplicate owners, unknown task/gap references, gap ownership or admission dependencies that differ from policy, orphan gaps, open prerequisites beneath a completed owner, self-dependencies, and dependency cycles. Task IDs can occur structurally only as ownerTaskId or dependencyTaskIds.

It also applies an explicit, verifier-pinned proof-scope classification to every task. A newly added task has no admission policy until that classification is reviewed and added. Required and planned scopes must match exactly, and every scope is pinned to an evidence class. Source review, static checks, and unit behavior therefore cannot masquerade as a real model, coding agent, database, vector store, browser, mobile, native desktop, DCC, engine, external channel, multimodal fixture, protocol, load/soak, human, or assistive-technology observation.

Gap coverage#

Proof-boundary policy#

Owner matrix#

The exact requirement and full exit sentence are retained in the machine record. The compact view below exposes every owner, admission edge, proof boundary, and evidence state for review.

Exit semantics#

Each row exits only when every clause of its exact ledger requirement is satisfied, its dependencies are complete, admitted evidence covers every named operating boundary, an applicable negative control is observed red and then green, and exact limitations remain explicit. A row marked open has no artifact locators and cannot satisfy closure. A completed row must link readable direct evidence.

Phase 18 must reclassify the evidence behind every row as proved, contradicted, weak/indirect, missing, or externally blocked. Only proved work closes. Unresolved blockers, including named external or accepted gaps and successor work, keep the affected task, dependent phase, initiative, and charter completion open. This matrix deliberately does not pre-classify planned work as proved.

The charter workflow and runtime contract is EVE_SOTA_CHARTER_COMPLETENESS_2026-09.md. Task 0.8 owns full source coverage, tasks 5.10/5.11 own required runtime delivery, task 11.8 owns the cross-release benchmark, and task 12.8 owns the complete evidence gate. Phase 18 depends on those outcomes; registered-gap coverage alone cannot establish charter completion.

Explicit prerequisite rationale#

Each dependency below is a required artifact or admission gate. Ledger order is not a dependency. Work may be prepared independently, but completion still requires every named prerequisite. New task IDs fail closed until reviewed edges and proof scopes are added.

• 0.2 → 0.1: Uses the corrected gap definitions rather than the superseded audit claims.
• 0.3 → 0.2: Uses the reproducible baseline and its actual capability boundary.
• 0.4 → 0.2: Uses the reproducible baseline and its actual capability boundary.
• 0.5 → 0.3: Consumes the preregistered outcome thresholds and decision rules.
• 0.5 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 0.6 → 0.5: Uses the admitted evidence format and negative-control requirements.
• 0.7 → 0.2: Uses the reproducible baseline and its actual capability boundary.
• 0.7 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 0.8 → 0.3: Consumes the preregistered outcome thresholds and decision rules.
• 0.8 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 0.8 → 0.5: Uses the admitted evidence format and negative-control requirements.
• 0.8 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 0.8 → 0.7: Requires fresh observed host and runtime availability.
• 1.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 1.2 → 1.1: Consumes the surveyed authoritative Metis API and stable surface inventory.
• 1.3 → 1.1: Consumes the surveyed authoritative Metis API and stable surface inventory.
• 1.3 → 1.2: Uses the approved transport, identity and failure semantics.
• 1.4 → 1.3: Exercises the admitted read views and their actual bindings.
• 1.5 → 1.1: Consumes the surveyed authoritative Metis API and stable surface inventory.
• 1.5 → 1.2: Uses the approved transport, identity and failure semantics.
• 1.5 → 1.4: Requires the subject, tenant and scope guards around those views.
• 1.6 → 1.3: Exercises the admitted read views and their actual bindings.
• 1.6 → 1.4: Requires the subject, tenant and scope guards around those views.
• 1.6 → 1.5: Uses the authoritative mutation or source-backed zero-write boundary.
• 1.7 → 1.3: Exercises the admitted read views and their actual bindings.
• 1.7 → 1.4: Requires the subject, tenant and scope guards around those views.
• 1.7 → 1.5: Uses the authoritative mutation or source-backed zero-write boundary.
• 1.7 → 1.6: Depends on the restamped tool contract and measured Metis battery.
• 1.8 → 1.1: Consumes the surveyed authoritative Metis API and stable surface inventory.
• 1.8 → 1.7: Requires the observed Metis refusal, replay and outage controls.
• 1.9 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 1.9 → 1.8: Extends the existing workbench seam totality mechanism.
• 2.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 2.2 → 2.1: Implements the adopted attributed delivery lifecycle.
• 2.3 → 2.2: Consumes canonical readiness, lease, fencing and terminal-state semantics.
• 2.4 → 2.2: Consumes canonical readiness, lease, fencing and terminal-state semantics.
• 2.4 → 2.3: Exercises the real resumable drain and its process supervision.
• 2.5 → 2.2: Consumes canonical readiness, lease, fencing and terminal-state semantics.
• 2.5 → 2.3: Exercises the real resumable drain and its process supervision.
• 2.5 → 2.4: Requires evidence-linked retry and truthful triage behavior.
• 2.6 → 2.2: Consumes canonical readiness, lease, fencing and terminal-state semantics.
• 2.6 → 2.3: Exercises the real resumable drain and its process supervision.
• 2.7 → 2.1: Implements the adopted attributed delivery lifecycle.
• 2.7 → 2.2: Consumes canonical readiness, lease, fencing and terminal-state semantics.
• 2.7 → 2.3: Exercises the real resumable drain and its process supervision.
• 2.7 → 2.4: Requires evidence-linked retry and truthful triage behavior.
• 2.7 → 2.5: Requires observable fleet state and operator kill controls.
• 2.7 → 2.6: Requires isolated execution, preserved user work and independent identities.
• 2.8 → 2.7: Consumes the fault-tested queue and hand-lease/drain parity contract.
• 2.8 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 2.8 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 2.8 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 3.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 3.2 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 3.2 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 3.3 → 3.2: Consumes the measured approved embedding route and provider boundary.
• 3.4 → 3.3: Uses the versioned ACL-bearing dense index and deletion metadata.
• 3.5 → 3.1: Requires independently human-labelled relevance cases for quality claims.
• 3.5 → 3.4: Exercises actual hybrid fusion, fallback and ranking behavior.
• 3.6 → 3.3: Uses the versioned ACL-bearing dense index and deletion metadata.
• 3.6 → 3.4: Exercises actual hybrid fusion, fallback and ranking behavior.
• 3.7 → 3.5: Requires paired independent retrieval quality and cost measurements.
• 3.7 → 3.6: Requires adversarial corpus, tenancy and poisoning evidence.
• 3.8 → 3.7: Consumes the measured retrieval promotion or lexical-only decision.
• 3.8 → 13.6: Requires actual backup/restore, migration and deletion-preserving recovery proof.
• 3.8 → 14.4: Requires deletion/export propagation through actual data stores and backups.
• 3.8 → 15.5: Requires automated route canary, drift detection, quarantine and rollback.
• 4.1 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 4.2 → 4.1: Consumes the threat model and concrete attack boundaries.
• 4.3 → 4.1: Consumes the threat model and concrete attack boundaries.
• 4.3 → 4.2: Requires trust labels and provenance to survive prompt assembly.
• 4.4 → 4.1: Consumes the threat model and concrete attack boundaries.
• 4.5 → 4.1: Consumes the threat model and concrete attack boundaries.
• 4.5 → 4.4: Uses deterministic effective-authority enforcement.
• 4.6 → 4.1: Consumes the threat model and concrete attack boundaries.
• 4.6 → 4.4: Uses deterministic effective-authority enforcement.
• 4.7 → 4.4: Uses deterministic effective-authority enforcement.
• 4.7 → 4.5: Requires execution isolation and scoped credentials.
• 4.8 → 4.1: Consumes the threat model and concrete attack boundaries.
• 4.8 → 4.2: Requires trust labels and provenance to survive prompt assembly.
• 4.8 → 4.3: Requires paired attack and benign-utility cases.
• 4.8 → 4.4: Uses deterministic effective-authority enforcement.
• 4.8 → 4.5: Requires execution isolation and scoped credentials.
• 4.8 → 4.6: Consumes external-tool trust and credential boundary controls.
• 4.8 → 4.7: Requires confirmation, cancellation and reversal at high-impact boundaries.
• 5.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 5.2 → 5.1: Consumes the audited real Bellona delegation path.
• 5.2 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 5.3 → 0.7: Requires fresh observed host and runtime availability.
• 5.4 → 5.1: Consumes the audited real Bellona delegation path.
• 5.4 → 5.3: Requires a real Blender handshake and save/readback smoke.
• 5.5 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 5.5 → 5.2: Requires capability-correct registry model bindings.
• 5.5 → 5.4: Uses the deterministic risk-classified Blender action catalog.
• 5.5 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 5.5 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 5.5 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 5.6 → 5.5: Requires governed leased Bellona admission.
• 5.7 → 5.6: Extends the independently verified real Blender first-light artifact.
• 5.8 → 5.5: Requires governed leased Bellona admission.
• 5.8 → 5.7: Requires the Blender breadth and reopen behavior under test.
• 5.9 → 0.7: Requires fresh observed host and runtime availability.
• 5.10 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 5.10 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 5.10 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.10 → 5.13: Uses the real governed Unreal adapter and editor state.
• 5.10 → 5.14: Requires packaged/playable Unreal workflows, recovery and independent quality evidence.
• 5.10 → 5.33: Requires complete tool-schema delivery proven on the admitted Unreal profile, which settles the optional native backend chain (5.30 to 5.32) by adoption or measured rejection.
• 5.10 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 5.10 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 5.10 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 5.11 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 5.11 → 5.8: Requires observed Blender failure and false-success controls.
• 5.11 → 5.10: Requires complete Unreal delivery evidence for required engine workflows.
• 5.11 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.11 → 5.15: Requires internal Maya/UGC sandbox delivery and hostile-content containment.
• 5.11 → 5.16: Requires separate real solver and numerical-engine acceptance receipts.
• 5.11 → 5.17: Requires real voice/media and companion-simulation package evidence.
• 5.11 → 5.18: Requires actual declared platform/device packaging and user-journey proof.
• 5.11 → 5.19: Requires all additionally selected creative-application child tasks to close.
• 5.12 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 5.12 → 5.9: Uses the fresh host/runtime/licence matrix.
• 5.13 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 5.13 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.13 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 5.13 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 5.13 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 5.13 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 5.14 → 5.13: Uses the real governed Unreal adapter and editor state.
• 5.14 → 5.34: Retains the target-resolution failure and persisted-state receipts inside this battery for each admitted backend.
• 5.14 → 5.35: Records the project authoring-convention results inside this battery rather than in another release gate.
• 5.15 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 5.15 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.15 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 5.15 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 5.15 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 5.16 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 5.16 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.16 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 5.16 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 5.16 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 5.17 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 5.17 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.17 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 5.17 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 5.17 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 5.17 → 17.4: Uses the owning domain real generation toolchain and editable artifacts.
• 5.17 → 17.5: Requires separate modality quality, human and failure evidence.
• 5.18 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 5.18 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.18 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 5.18 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 5.18 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 5.19 → 5.12: Consumes source-owned runtime packages with exact adapter, owner and acceptance boundaries.
• 5.19 → 5.29: Requires the selected After Effects application delivery and breadth evidence.
• 5.20 → 5.3: Corrects the observed compressed-save regression in the real executable smoke.
• 5.21 → 5.9: Refreshes current host and runtime availability rather than borrowing another host receipt.
• 5.21 → 5.12: Extends the source-owned runtime packages with usable creative application hosts.
• 5.22 → 4.5: Requires execution isolation before application mutation.
• 5.22 → 4.6: Uses authenticated external-tool and transport trust.
• 5.22 → 4.7: Requires deterministic preview, confirmation, and reversal controls.
• 5.22 → 5.21: Uses the provisioned and version-pinned After Effects host.
• 5.23 → 5.22: Builds motion authoring on a verified live AE backend.
• 5.24 → 5.23: Uses actual editable AE composition and keyframe operations.
• 5.24 → 14.7: Requires source-media rights and artifact governance.
• 5.25 → 5.5: Reuses attributed leased Bellona admission and its cross-phase gates.
• 5.25 → 5.24: Requires real AE save, reopen, and render operations.
• 5.25 → 12.10: Uses registered creative-family evidence and rejection rules.
• 5.25 → 14.7: Requires actual media and project governance for live execution.
• 5.26 → 5.5: Requires governed leased Bellona execution.
• 5.26 → 5.13: Uses the admitted real Unreal editor adapter and authenticated transport.
• 5.26 → 14.7: Requires cross-domain source and artifact rights governance.
• 5.26 → 17.4: Uses live generation through the owning domain.
• 5.27 → 5.14: Uses verified Unreal workflow and recovery behavior.
• 5.27 → 5.20: Uses corrected compressed and uncompressed Blender readback/export verification.
• 5.27 → 5.26: Requires actual cross-app provider bindings and transfer.
• 5.28 → 5.24: Uses the real native project and render lifecycle.
• 5.28 → 5.26: Exercises failure across actual cross-application boundaries.
• 5.28 → 13.3: Reuses canonical retry, deadline, idempotency, and cancellation semantics.
• 5.29 → 5.25: Exercises real attributed Eve-to-AE execution.
• 5.29 → 5.28: Requires durable application failure and recovery behavior.
• 5.29 → 12.9: Uses preregistered creative measurement and failure criteria.
• 5.30 → 5.13: Compares a required workflow against the current governed Bellona backend.
• 5.30 → 5.21: Extends the provisioned, version-pinned host records; provisioning stays with 5.21.
• 5.31 → 5.5: Production admission stays behind the attributed leased Bellona registration.
• 5.31 → 5.13: Reuses the governed adapter authority contract and its live-admission gates.
• 5.31 → 5.30: Exposes the native transport only for profiles the qualification admitted.
• 5.32 → 5.31: Authorizes operations dispatched over the serialized native transport.
• 5.33 → 5.32: Native integration and rollout use the authorized discovery profile; generic fixture work may start before it.
• 5.33 → 15.3: Extends the long-context instruction and schema loss handling rather than duplicating it.
• 5.34 → 5.13: Extends the governed adapter actor, asset and planning contracts with target identity.
• 5.35 → 5.13: Carries the project policy identity through the governed adapter plans and result evidence.
• 6.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 6.2 → 6.1: Uses the native-versus-browser ownership decision.
• 6.3 → 6.1: Uses the native-versus-browser ownership decision.
• 6.3 → 6.2: Requires the shared planning/vision registry and governed screenshot-input contract.
• 6.4 → 0.7: Requires fresh observed host and runtime availability.
• 6.4 → 6.1: Uses the native-versus-browser ownership decision.
• 6.5 → 6.3: Requires the actual native execution chain to pass fabrication/security review.
• 6.5 → 6.4: Uses a real OS-level desktop fixture and permission preflight.
• 6.6 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 6.6 → 6.2: Requires native planning/vision registry bindings.
• 6.6 → 6.3: Requires the actual native execution chain to pass fabrication/security review.
• 6.6 → 6.4: Uses a real OS-level desktop fixture and permission preflight.
• 6.6 → 6.5: Requires per-run authority, focus, budget and interrupt enforcement.
• 6.6 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 6.6 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 6.6 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 6.7 → 6.6: Requires governed native leased-work admission.
• 6.8 → 6.7: Requires measured native task breadth and recovery behavior.
• 7.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 7.2 → 7.1: Uses the corrected existing Hermes/fusion boundary.
• 7.2 → 12.2: Consumes independent cohort, grader and statistically feasible sample contracts.
• 7.3 → 7.1: Uses the corrected existing Hermes/fusion boundary.
• 7.4 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 7.4 → 7.2: Consumes independently graded watcher, channel and assistant-runtime cases.
• 7.4 → 7.3: Implements the specified watcher event, freshness and lifecycle semantics.
• 7.4 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 7.4 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 7.4 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 7.5 → 7.4: Uses admitted confirmed watcher tools and scheduler state.
• 7.6 → 7.1: Uses the corrected existing Hermes/fusion boundary.
• 7.7 → 3.7: Consumes the measured retrieval promotion or lexical-only decision.
• 7.7 → 7.6: Uses one governed skill ownership, retrieval and poisoning policy.
• 7.7 → 9.4: Uses provenance, supersession, expiry and reauthorization policy.
• 7.8 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 7.8 → 7.2: Consumes independently graded watcher, channel and assistant-runtime cases.
• 7.8 → 7.5: Requires live watcher breadth, dedupe and recovery evidence.
• 7.8 → 7.6: Uses one governed skill ownership, retrieval and poisoning policy.
• 7.8 → 7.7: Uses the shared semantic recall path and deletion/tenant boundaries.
• 7.8 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 7.8 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 7.8 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 7.9 → 7.6: Reuses the ratified skill ownership and lifecycle.
• 7.9 → 14.7: Requires retained examples and source assets to carry rights governance.
• 7.9 → 17.7: Uses explicit creative workflow and capability requirements.
• 7.10 → 7.9: Uses versioned and authority-clamped creative recipes.
• 7.10 → 12.9: Uses held-out briefs and preregistered human-grounded quality rules.
• 8.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 8.2 → 8.1: Uses the actual shipped surface and invocation inventory.
• 8.3 → 8.1: Uses the actual shipped surface and invocation inventory.
• 8.3 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.4 → 8.1: Uses the actual shipped surface and invocation inventory.
• 8.4 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.5 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.6 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.7 → 8.1: Uses the actual shipped surface and invocation inventory.
• 8.7 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.8 → 8.3: Exercises contextual invocation totality and sanitized context.
• 8.8 → 8.4: Requires the measured mobile streaming and lifecycle contract.
• 8.8 → 8.5: Exercises long-turn steering, cancel and recovery behavior.
• 8.8 → 8.6: Requires the evaluated typed UI or deterministic fallback decision.
• 8.8 → 8.7: Requires the measured voice depth and accessible fallback boundary.
• 8.9 → 8.1: Uses the actual shipped surface and invocation inventory.
• 8.9 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.9 → 8.3: Exercises contextual invocation totality and sanitized context.
• 8.9 → 8.4: Requires the measured mobile streaming and lifecycle contract.
• 8.9 → 8.5: Exercises long-turn steering, cancel and recovery behavior.
• 8.9 → 8.6: Requires the evaluated typed UI or deterministic fallback decision.
• 8.9 → 8.7: Requires the measured voice depth and accessible fallback boundary.
• 8.9 → 8.8: Requires assistive-tech and WCAG acceptance for the affected states.
• 8.9 → 8.20: Requires the proven chat-surface parity journeys and register.
• 8.10 → 8.2: Uses the required interface and interaction design brief.
• 8.10 → 8.5: Reuses user steering and long-turn controls.
• 8.10 → 17.9: Presents actual versioned storyboard alternatives and selection.
• 8.10 → 17.12: Binds annotations to a working native revision loop.
• 8.11 → 8.10: Exercises the real creative review controls and service state.
• 8.11 → 17.13: Requires actual portable, downloadable native project packages.
• 8.12 → 8.1: Uses the actual shipped surface and invocation inventory.
• 8.12 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.13 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.13 → 8.3: Reuses the shared privacy boundary and untrusted context-handoff block.
• 8.13 → 8.12: Consumes the ratified per-surface parity register.
• 8.13 → 14.8: Requires attachment classification, scanning, retention and deletion policy.
• 8.13 → 17.1: Uses the real modality/toolchain capability and limitation matrix.
• 8.14 → 8.2: Consumes the approved restrained interaction and design brief.
• 8.14 → 8.12: Consumes the ratified per-surface parity register.
• 8.15 → 8.5: Exercises long-turn steering, cancel and recovery behavior.
• 8.15 → 8.6: Extends the adopted typed generative-UI allowlist and validators.
• 8.15 → 8.14: Uses the rich renderer for artifact previews and media.
• 8.16 → 8.5: Exercises long-turn steering, cancel and recovery behavior.
• 8.16 → 8.12: Consumes the ratified per-surface parity register.
• 8.17 → 8.12: Consumes the ratified per-surface parity register.
• 8.17 → 9.2: Uses the operator-visible memory inspect/correct/forget controls.
• 8.17 → 14.8: Requires deletion propagation and permalink access policy.
• 8.18 → 8.12: Consumes the ratified per-surface parity register.
• 8.18 → 15.7: Uses the admitted generation legs and priced route choices.
• 8.19 → 8.5: Exercises long-turn steering, cancel and recovery behavior.
• 8.19 → 8.15: Delivers results into the artifact workspace.
• 8.19 → 13.3: Uses standardized deadline, retry, idempotency and cancellation semantics.
• 8.20 → 8.8: Requires assistive-tech and WCAG acceptance for the affected states.
• 8.20 → 8.13: Requires the shipped multimodal composer.
• 8.20 → 8.14: Requires rich rendering on every surface.
• 8.20 → 8.15: Requires the delivered, versioned artifact workspace on every surface.
• 8.20 → 8.16: Requires turn-level edit, regenerate, copy, feedback and share parity.
• 8.20 → 8.17: Requires conversation list, rename, archive, delete and project parity.
• 8.20 → 8.18: Requires composer mode, tool and route selection.
• 8.20 → 8.19: Requires long-running work progress and completion delivery in chat.
• 9.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 9.2 → 9.1: Uses the actual persisted-memory and session-only posture.
• 9.3 → 9.1: Uses the actual persisted-memory and session-only posture.
• 9.4 → 9.1: Uses the actual persisted-memory and session-only posture.
• 9.4 → 9.2: Requires operator data inspection, correction and deletion controls.
• 9.5 → 9.2: Requires operator data inspection, correction and deletion controls.
• 9.5 → 9.4: Uses provenance, supersession, expiry and reauthorization policy.
• 9.6 → 3.7: Consumes the measured retrieval promotion or lexical-only decision.
• 9.6 → 7.7: Uses the shared semantic recall path and deletion/tenant boundaries.
• 9.6 → 9.4: Uses provenance, supersession, expiry and reauthorization policy.
• 9.7 → 9.2: Requires operator data inspection, correction and deletion controls.
• 9.7 → 9.3: Requires independently human-labelled multi-session memory cases.
• 9.7 → 9.4: Uses provenance, supersession, expiry and reauthorization policy.
• 9.7 → 9.5: Requires observed poisoning, isolation and deletion-resurrection controls.
• 9.7 → 9.6: Requires the admitted semantic-memory path or evidenced non-adoption boundary.
• 10.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 10.2 → 10.1: Uses the authoritative existing release-blocked room expectations.
• 10.3 → 10.2: Exercises runtime release-scope expectation selection.
• 10.4 → 10.1: Uses the authoritative existing release-blocked room expectations.
• 10.4 → 10.2: Exercises runtime release-scope expectation selection.
• 10.4 → 10.3: Requires provider-free dual-scope and inverted-mapping controls.
• 11.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 11.2 → 2.1: Implements the adopted attributed delivery lifecycle.
• 11.3 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 11.4 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 11.4 → 11.2: Implements or grades the explicit plan-quality and scope contract.
• 11.4 → 11.3: Uses the repository execution, isolation and evidence contract.
• 11.5 → 11.3: Uses the repository execution, isolation and evidence contract.
• 11.5 → 11.11: Exercises revision-bound fleet execution, invalidation and recovery.
• 11.6 → 11.1: Uses unseen versioned engineering cases with hidden acceptance evidence.
• 11.6 → 11.4: Requires independent behavioral review and anti-fabrication evidence.
• 11.6 → 11.5: Requires real delivery conflict, crash, rollback and resume behavior.
• 11.6 → 11.12: Requires complete operator labor accounting, including approvals and failed work.
• 11.6 → 12.2: Consumes independent cohort, grader and statistically feasible sample contracts.
• 11.7 → 2.8: Requires the actual governed fleet drain and soak evidence.
• 11.7 → 11.6: Requires measured delivery competence against paired baselines.
• 11.7 → 11.11: Exercises revision-bound fleet execution, invalidation and recovery.
• 11.8 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 11.8 → 5.11: Requires every selected runtime package, including newly discovered children, to be delivered.
• 11.8 → 11.7: Requires an actual operator-goal-to-verified-delivery trajectory.
• 11.8 → 12.8: Requires the full evidence-joining charter gate implementation, independently of later production results.
• 11.8 → 17.6: Requires real governed cross-modal delivery and verification.
• 11.9 → 11.2: Implements or grades the explicit plan-quality and scope contract.
• 11.10 → 11.9: Consumes persisted attributed goal and requirement revisions.
• 11.11 → 2.7: Consumes the fault-tested queue and hand-lease/drain parity contract.
• 11.11 → 11.10: Consumes the persisted acyclic dependency graph and proof plan.
• 11.12 → 11.2: Implements or grades the explicit plan-quality and scope contract.
• 11.12 → 13.2: Consumes attributed end-to-end trace/correlation records.
• 12.1 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 12.2 → 0.3: Consumes the preregistered outcome thresholds and decision rules.
• 12.2 → 12.1: Uses the complete required-capability and risk taxonomy.
• 12.3 → 0.3: Consumes the preregistered outcome thresholds and decision rules.
• 12.4 → 12.2: Consumes independent cohort, grader and statistically feasible sample contracts.
• 12.5 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 12.6 → 12.2: Consumes independent cohort, grader and statistically feasible sample contracts.
• 12.6 → 12.4: Requires trajectory-level grading of state, efficiency and truthfulness.
• 12.6 → 12.5: Uses held-out-data governance, provenance and contamination controls.
• 12.7 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 12.7 → 12.1: Uses the complete required-capability and risk taxonomy.
• 12.7 → 12.2: Consumes independent cohort, grader and statistically feasible sample contracts.
• 12.7 → 12.3: Requires real blinded human labels and validated judge classes.
• 12.7 → 12.4: Requires trajectory-level grading of state, efficiency and truthfulness.
• 12.7 → 12.5: Uses held-out-data governance, provenance and contamination controls.
• 12.8 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 12.8 → 12.2: Consumes independent cohort, grader and statistically feasible sample contracts.
• 12.8 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 12.9 → 0.3: Uses the north-star outcome and decision contract.
• 12.9 → 12.1: Extends the existing task and evaluation family taxonomy.
• 12.9 → 12.2: Reuses independent case sampling and stochastic decision rules.
• 12.9 → 17.7: Measures the required creative workflow outcomes.
• 12.10 → 12.7: Extends the existing applicable-family release gate.
• 12.10 → 12.8: Extends the charter completeness evidence join.
• 12.10 → 12.9: Uses explicit creative family thresholds and evidence boundaries.
• 12.11 → 8.12: Consumes the ratified per-surface parity register.
• 12.11 → 12.1: Uses the expanded task/eval taxonomy covering UX, multimodal and cost.
• 12.11 → 12.2: Uses the case diversity and stochastic-run rules.
• 13.1 → 0.3: Consumes the preregistered outcome thresholds and decision rules.
• 13.2 → 13.1: Uses the fixed per-plane SLO, RTO, budget and alert contract.
• 13.3 → 13.1: Uses the fixed per-plane SLO, RTO, budget and alert contract.
• 13.4 → 13.2: Consumes attributed end-to-end trace/correlation records.
• 13.4 → 13.3: Exercises bounded retry, fencing, backpressure and cancellation semantics.
• 13.5 → 13.2: Consumes attributed end-to-end trace/correlation records.
• 13.5 → 13.3: Exercises bounded retry, fencing, backpressure and cancellation semantics.
• 13.6 → 13.1: Uses the fixed per-plane SLO, RTO, budget and alert contract.
• 13.7 → 13.1: Uses the fixed per-plane SLO, RTO, budget and alert contract.
• 13.7 → 13.2: Consumes attributed end-to-end trace/correlation records.
• 13.7 → 13.3: Exercises bounded retry, fencing, backpressure and cancellation semantics.
• 13.7 → 13.4: Requires resource-safe realistic load and soak evidence.
• 13.7 → 13.5: Requires observed dependency/crash/resource fault recovery.
• 13.7 → 13.6: Requires actual backup/restore, migration and deletion-preserving recovery proof.
• 14.1 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 14.2 → 14.1: Uses the complete source-to-destination data inventory.
• 14.3 → 14.1: Uses the complete source-to-destination data inventory.
• 14.4 → 3.3: Uses the versioned ACL-bearing dense index and deletion metadata.
• 14.4 → 9.2: Requires operator data inspection, correction and deletion controls.
• 14.4 → 14.1: Uses the complete source-to-destination data inventory.
• 14.5 → 14.1: Uses the complete source-to-destination data inventory.
• 14.6 → 14.1: Uses the complete source-to-destination data inventory.
• 14.6 → 14.2: Requires the reviewed provider transfer, retention and subprocess posture.
• 14.7 → 14.1: Uses the complete source-to-destination data inventory.
• 14.7 → 14.2: Requires the reviewed provider transfer, retention and subprocess posture.
• 14.7 → 14.3: Requires minimization and sensitive-data/exfiltration controls.
• 14.7 → 14.4: Requires deletion/export propagation through actual data stores and backups.
• 14.7 → 14.5: Requires retention, disclosure and audited access policy.
• 14.7 → 14.6: Requires applicable human-owned legal and oversight decisions.
• 14.8 → 14.1: Uses the complete source-to-destination data inventory.
• 14.8 → 14.3: Requires minimization and sensitive-data/exfiltration controls.
• 14.8 → 14.4: Requires deletion/export propagation through actual data stores and backups.
• 14.8 → 14.5: Requires retention, disclosure and audited access policy.
• 15.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 15.2 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 15.3 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 15.4 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 15.5 → 15.2: Requires measured fallback and endpoint-failover contract preservation.
• 15.5 → 15.3: Requires long-context authority, provenance and state-retention evidence.
• 15.5 → 15.4: Uses billed cost and latency per independently verified outcome.
• 15.6 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 15.6 → 15.2: Requires measured fallback and endpoint-failover contract preservation.
• 15.6 → 15.3: Requires long-context authority, provenance and state-retention evidence.
• 15.6 → 15.4: Uses billed cost and latency per independently verified outcome.
• 15.7 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 15.7 → 15.2: Uses the provider/route resilience policy.
• 16.1 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 16.2 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 16.3 → 16.2: Consumes the pinned MCP lifecycle and transport conformance contract.
• 16.4 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 16.5 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 16.5 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 16.5 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 16.5 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 16.5 → 16.2: Consumes the pinned MCP lifecycle and transport conformance contract.
• 16.5 → 16.3: Requires protected HTTP MCP authorization and token-boundary proof.
• 16.5 → 16.4: Uses the evidenced A2A adoption or source-backed non-adoption decision.
• 16.6 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 16.6 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 16.6 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 16.6 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 16.6 → 16.1: Uses the current event interoperability decision.
• 16.6 → 16.2: Consumes the pinned MCP lifecycle and transport conformance contract.
• 16.6 → 16.3: Requires protected HTTP MCP authorization and token-boundary proof.
• 16.6 → 16.4: Uses the evidenced A2A adoption or source-backed non-adoption decision.
• 16.6 → 16.5: Requires admitted external integration provenance, health and quarantine controls.
• 17.1 → 0.6: Uses the task ownership and direct proof-boundary contract.
• 17.2 → 17.1: Uses the real modality/toolchain capability and limitation matrix.
• 17.3 → 17.1: Uses the real modality/toolchain capability and limitation matrix.
• 17.4 → 15.1: Consumes priced, capability-correct, fail-loud model registry bindings.
• 17.4 → 17.1: Uses the real modality/toolchain capability and limitation matrix.
• 17.5 → 17.2: Exercises actual structured document extraction and source anchors.
• 17.5 → 17.3: Exercises grounded multimodal understanding and uncertainty handling.
• 17.5 → 17.4: Uses the owning domain real generation toolchain and editable artifacts.
• 17.6 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 17.6 → 5.8: Requires observed Blender failure and false-success controls.
• 17.6 → 12.7: Live admission requires the applicable-family evaluation gate, not the future charter benchmark.
• 17.6 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 17.6 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 17.6 → 17.2: Exercises actual structured document extraction and source anchors.
• 17.6 → 17.3: Exercises grounded multimodal understanding and uncertainty handling.
• 17.6 → 17.4: Uses the owning domain real generation toolchain and editable artifacts.
• 17.6 → 17.5: Requires separate modality quality, human and failure evidence.
• 17.7 → 0.8: Extends the ratified source-traceable charter coverage inventory.
• 17.7 → 17.1: Uses the actual modality and toolchain capability matrix.
• 17.8 → 14.7: Requires rights, retention, and source-media governance.
• 17.8 → 17.2: Uses structured documents, OCR, and source anchors.
• 17.8 → 17.3: Uses grounded visual, audio, and video understanding.
• 17.8 → 17.7: Uses the creative input and output contracts.
• 17.9 → 17.7: Uses explicit brief, output, and checkpoint requirements.
• 17.9 → 17.8: Consumes grounded and attributed references.
• 17.10 → 15.1: Uses approved capability-correct and priced model bindings.
• 17.10 → 17.4: Uses actual owning-domain generation tooling.
• 17.10 → 17.9: Consumes approved shot plans and asset slots.
• 17.11 → 5.25: Executes through the attributed live AE path.
• 17.11 → 17.9: Compiles approved versioned storyboard semantics.
• 17.11 → 17.10: Uses selected and validated generated asset bytes.
• 17.12 → 5.28: Uses durable creative execution and cancellation/recovery.
• 17.12 → 17.9: Binds feedback to immutable storyboard revisions.
• 17.12 → 17.11: Applies changes to actual editable AE projects.
• 17.13 → 5.24: Packages real reopenable AE project and render artifacts.
• 17.13 → 5.26: Uses actual cross-domain artifact storage and transfer.
• 17.13 → 14.7: Requires media rights, retention, and deletion governance.
• 17.14 → 17.7: Uses the architectural accuracy and output requirements.
• 17.14 → 17.8: Consumes measured and source-anchored floor-plan evidence.
• 17.15 → 5.6: Uses governed and independently verified Blender execution.
• 17.15 → 5.20: Requires correct native save/reopen and export verification.
• 17.15 → 17.14: Uses the dimensioned architectural scene contract.
• 17.16 → 12.9: Uses calibrated architectural visual and dimensional quality criteria.
• 17.16 → 17.10: Uses verified generated/imported assets and provenance.
• 17.16 → 17.15: Preserves independently verified architectural geometry.
• 17.17 → 5.27: Uses semantically verified Blender-to-Unreal interchange.
• 17.17 → 17.15: Uses editable dimensionally checked geometry.
• 17.17 → 17.16: Uses reviewed reference-based materials, lighting, and furnishings.
• 17.18 → 5.29: Requires real AE breadth and failure evidence.
• 17.18 → 7.10: Uses creative skills proven on held-out briefs.
• 17.18 → 8.11: Requires the actual review and delivery user journey.
• 17.18 → 12.10: Uses the admitted creative-family evidence and quality release gate.
• 17.18 → 17.11: Uses real native motion compilation and artifacts.
• 17.19 → 5.29: Requires real AE breadth and failure evidence.
• 17.19 → 7.10: Uses transferable creative recipes rather than memorized clips.
• 17.19 → 8.11: Requires the actual review and delivery user journey.
• 17.19 → 12.10: Uses the original-motion family quality gate.
• 17.19 → 17.11: Produces editable native compositions from approved plans.
• 17.20 → 8.11: Requires the actual review and delivery user journey.
• 17.20 → 12.10: Uses the architectural and walkthrough family gates.
• 17.20 → 17.13: Delivers verified portable native project packages.
• 17.20 → 17.17: Requires a delivered and tested interactive walkthrough.
• 17.21 → 17.18: Requires accepted held-out reference-motion delivery evidence.
• 17.21 → 17.19: Requires accepted original-brief motion delivery evidence.
• 17.21 → 17.20: Requires accepted dimensional reconstruction and walkthrough evidence.
• 17.22 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 17.22 → 14.7: Requires generated-media licence, disclosure and provenance governance.
• 17.22 → 15.7: Uses the admitted generation legs and priced route choices.
• 17.22 → 17.4: Uses the owning domain real generation toolchain and editable artifacts.
• 17.23 → 8.14: Uses the shared rich renderer for inline images, players and viewers.
• 17.23 → 8.15: Uses the artifact workspace for variants, edits and saves.
• 17.23 → 8.19: Uses progress and completion delivery for generation jobs.
• 17.23 → 17.22: Requires admitted, validated, provenance-bearing generation tools.
• 17.24 → 8.13: Requires the shipped multimodal composer and attachment envelope.
• 17.24 → 15.7: Uses the admitted vision and speech legs through the registry control.
• 17.24 → 17.2: Exercises actual structured document extraction and source anchors.
• 17.24 → 17.3: Exercises grounded multimodal understanding and uncertainty handling.
• 17.25 → 4.5: Requires execution isolation for code with scoped resources.
• 17.25 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 17.25 → 7.1: Uses the recorded Hermes fusion scope for the code-execution tool.
• 17.25 → 8.15: Delivers files and charts into the artifact workspace.
• 17.26 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 17.26 → 7.1: Uses the recorded Hermes fusion scope for web search and fetch tools.
• 17.26 → 8.15: Delivers cited research reports into the artifact workspace.
• 17.26 → 8.18: Uses the composer mode picker for search and research modes.
• 17.26 → 8.19: Uses progress and completion delivery for research runs.
• 17.27 → 12.11: Uses the admitted parity and generated-media evaluation family.
• 17.27 → 17.23: Requires delivered generated media in the conversation.
• 17.27 → 17.24: Requires grounded answers from attachments.
• 17.27 → 17.25: Requires admitted sandboxed data analysis.
• 17.27 → 17.26: Requires admitted web search and deep research.
• 18.1 → 0.8: Requires ratified source coverage so required workflows cannot be omitted.
• 18.1 → 1.9: Requires required-workbench completion to reject deferred or missing seams.
• 18.1 → 2.8: Requires the actual governed fleet drain and soak evidence.
• 18.1 → 3.8: Requires operational retrieval freshness, recovery and canary evidence.
• 18.1 → 4.8: Live admission requires the security red-team gate; preparation may proceed before it.
• 18.1 → 5.11: Requires every selected runtime package, including newly discovered children, to be delivered.
• 18.1 → 6.8: Requires native injection and benign continuation proof.
• 18.1 → 7.8: Requires explicitly chosen, live-gated channel operation.
• 18.1 → 8.9: Requires actual cross-client journeys and server/tool round-trip proof.
• 18.1 → 9.7: Requires measured memory rollout, usefulness and zero-harm evidence.
• 18.1 → 10.4: Requires actual V1.2 availability and restored-semantics live evidence.
• 18.1 → 11.8: Requires the full charter benchmark and complete observation windows.
• 18.1 → 12.6: Requires online feedback and drift evidence linked to offline cases.
• 18.1 → 12.8: Requires the full evidence-joining charter gate implementation, independently of later production results.
• 18.1 → 13.7: Live admission requires operational detect, kill, recover and verify readiness.
• 18.1 → 14.7: Creative/live admission requires actual privacy, media rights and consent governance.
• 18.1 → 15.6: Requires bounded capacity and denial-of-wallet evidence.
• 18.1 → 16.6: Requires conformance against independent counterpart implementations.
• 18.1 → 17.6: Requires real governed cross-modal delivery and verification.
• 18.1 → 17.21: Requires all added creative workflows, dependencies, and truthful capability claims to reconcile before closure.
• 18.1 → 17.27: Requires generated-media and agentic chat claims to reconcile with the parity register before closure.
• 18.2 → 18.1: Requires every gap and required charter workflow to reconcile to direct evidence.
• 18.3 → 0.4: Uses the versioned source/control crosswalk to define applicable obligations.
• 18.4 → 18.1: Requires every gap and required charter workflow to reconcile to direct evidence.
• 18.4 → 18.2: Requires the fresh source/runtime audit with new gaps owned.
• 18.4 → 18.3: Requires current source and comparative capability gaps to be resolved.
• 18.5 → 18.1: Requires every gap and required charter workflow to reconcile to direct evidence.
• 18.5 → 18.2: Requires the fresh source/runtime audit with new gaps owned.
• 18.6 → 18.4: Requires the clean-state full charter and operator benchmark evidence.
• 18.6 → 18.5: Requires the final security/reliability game day without hard-lock events.
• 18.7 → 18.1: Requires every gap and required charter workflow to reconcile to direct evidence.
• 18.7 → 18.2: Requires the fresh source/runtime audit with new gaps owned.
• 18.7 → 18.3: Requires current source and comparative capability gaps to be resolved.
• 18.7 → 18.4: Requires the clean-state full charter and operator benchmark evidence.
• 18.7 → 18.5: Requires the final security/reliability game day without hard-lock events.
• 18.7 → 18.6: Requires all applicable final verification and derived artifacts.
• 18.8 → 18.1: Requires every gap and required charter workflow to reconcile to direct evidence.
• 18.8 → 18.2: Requires the fresh source/runtime audit with new gaps owned.
• 18.8 → 18.3: Requires current source and comparative capability gaps to be resolved.
• 18.8 → 18.4: Requires the clean-state full charter and operator benchmark evidence.
• 18.8 → 18.5: Requires the final security/reliability game day without hard-lock events.
• 18.8 → 18.6: Requires all applicable final verification and derived artifacts.
• 18.8 → 18.7: Requires accurate open-blocker reporting and current evidence documentation.

Limitations#

• Open rows contain evidence plans only; a planned scope or manifest path is not an executed result.
• Completed Phase-0 rows link direct repository evidence created before or during schema admission; later phase closure still requires task-specific evidence manifests.
• A matrix verifier proves ownership, dependency, and proof-boundary integrity, not the truth of a future runtime claim.