# XII. Delivery Roadmap

#### 12.1 Purpose and Scope

12.1.1 **Purpose.** This Part defines an executable delivery plan—engineering work packages bound to governance gates—that makes NXOSI deployable, interoperable, and auditable in production. The plan is designed to reduce variance: the same artefact model, verification procedures, and correction discipline must hold across vendors, sovereign deployments, and mixed-connectivity environments.

12.1.2 **Scope.** This Part specifies: (a) program principles that constrain how NXOSI ships; (b) parallel delivery workstreams and their coordination points; (c) build packages with acceptance criteria and failure-mode expectations; (d) a phased timeline with “stop-the-line” gates; (e) an open-source governance and ecosystem strategy; and (f) a standardization path that identifies which normative surfaces must be stabilized for interoperability and which elements remain implementation-specific.

12.1.3 **Non-execution boundary.** All delivery and integration guidance preserves the assurance-only perimeter. NXOSI components produce proofs, status semantics, dockets, and correction records; they do not perform custody, underwriting, market operation, claims execution, settlement, supervisory decisions, or legally binding regulatory actions. Where regulated execution stacks are integrated, interfaces are explicitly routed and non-invasive: NXOSI provides evidence and obligations as inputs, while regulated execution remains external and controlled by authorized entities.

12.1.4 **What “done” means.** “Done” is defined as: (i) conformance surfaces are testable and stable; (ii) proofs are portable and independently verifiable; (iii) deployments operate in degraded modes while still producing valid artefacts; and (iv) corrections and disputes can be governed without destabilizing reliance. Prototypes that cannot be verified, replayed, or corrected do not qualify as delivery.

***

#### 12.2 Program Principles (How NXOSI Ships Without Failing in Production)

12.2.1 **Conformance-first.** The system ships only when conformance tests exist before ecosystem claims exist. Interoperability is defined by executable test suites and gold vectors, not by documentation or brand assertions. Feature work that cannot be expressed as a conformance surface is treated as secondary until testability is established.

12.2.2 **Receipts-first.** Portable proof objects are delivered ahead of dashboards. Operator experience is built around verifiable artefacts: receipts, status objects, dockets, and correction objects are the primary product. User interfaces are treated as views over proof, not as the source of truth.

12.2.3 **Sovereignty-first.** Compute-to-data and handling discipline are core design constraints, not afterthoughts. Every build package must include a sovereign-zone deployment posture: evidence retention in-zone, minimal disclosure by default, and controlled access workflows with logged approvals.

12.2.4 **Correctionability-first.** No silent edits are permitted—across standards artifacts, profile packages, ontology semantics, receipts, status, or control-plane actions. Every change produces an explicit status or correction object with scope, reason, and reliance implications.

12.2.5 **Replaceable parts.** The reference stack is modular and built around stable conformance surfaces: artifacts, verification procedures, status semantics, and interface contracts. Components may be replaced without breaking interoperability if they preserve required inputs/outputs and pass the conformance suites.

12.2.6 **Secure-by-default.** Every release is signed and provenance-verified. SBOM and build provenance are mandatory for runtime components and for standards-as-code artifacts that can affect obligations. Vulnerability intake, patch clocks, and emergency release discipline are treated as operational requirements, not optional hygiene.

***

#### 12.3 Delivery Workstreams (Parallel Tracks)

12.3.1 **Standards workstream.** Produces the Nexus Standards taxonomy, the canonical artifact model, baseline profiles, sector profiles, hazard overlays, and jurisdiction overlays; defines normative semantics and testability expectations; and maintains the controlled vocabulary for obligations, triggers, and evidence outputs.

12.3.2 **Protocol + artefact workstream.** Defines and stabilizes object schemas, identifiers, namespaces, linkage rules, receipt formats, status semantics, docket semantics, and correction mechanisms. This workstream owns the portability contract: “receipts travel, evidence stays,” and ensures that relying parties can validate without re-audit.

12.3.3 **Runtime workstream.** Delivers the compiler pipeline, standards-as-code runtime, check runtimes, attestation binding, enforcement-point adapters, and deterministic execution requirements. This workstream ensures that compiled plans are reproducible, replayable where required, and verifiably equivalent across implementations.

12.3.4 **Ontology fabric workstream.** Delivers the entity/relation/event model, provenance and uncertainty fields, identity resolution rules, trust scoring engine with bounded influence, and semantic governance. This workstream ensures that triggers and obligations bind to meaning consistently across deployments.

12.3.5 **Control plane workstream.** Delivers the operational cockpit and governed authoring system (low-code/no-code), simulation gates, audit exports, separation-of-duties enforcement, override governance, and CPAR evidence outputs. This workstream ensures that operator actions are evidence-producing and reviewable.

12.3.6 **Conformance workstream.** Delivers the test harness, gold vectors, negative and adversarial suites, plugfest design, interoperability matrices, and continuous conformance monitoring. This workstream turns “works for me” into “works anywhere under test.”

12.3.7 **Security and handling workstream.** Delivers key lifecycle policy, signing policies, cryptographic agility posture, post-quantum readiness, sovereign zone deployment patterns, lawful basis matrices, disclosure/retention rules, incident response playbooks, and compromise response procedures.

12.3.8 **Enterprise integration workstream.** Delivers adapters, integration patterns, and operational guidance for SOC/NOC platforms, ITSM/change systems, GRC/audit tools, CI/CD pipelines, procurement/vendor systems, data platforms, and AI platforms—without collapsing assurance into regulated execution.

***

### Build Packages (Engineering Deliverables) — “2026-Ready” (12.4)

#### 12.4 Package A — Receipt & Transparency Service (NX-7 Core)

12.4.1 **Receipt schema, signing rules, and verification libraries.** Deliver stable receipt schemas with required fields, canonical serialization, signature profiles, and verification libraries supporting offline and online workflows. Verification libraries MUST enforce scope/time bounds and permitted inference limits by reliance tier.

12.4.2 **Inclusion proofs and transparency publication workflow.** Deliver append workflow, inclusion proof generation, audit hooks, and monitoring outputs. Publication MUST be reliable and observable; delayed inclusion MUST be detectable and declared where it affects reliance.

12.4.3 **Status endpoints (revocation/supersession/scope narrowing).** Deliver stable status APIs and snapshot formats supporting revocation, supersession, scope narrowing, validity windows, and migration notes. Status resolution MUST be deterministic for relying parties in online and offline modes.

12.4.4 **Offline verification bundle formats (snapshots/caches).** Deliver snapshot and cache formats and freshness policies, including archival verification bundles for long-lived receipts. Offline bundles MUST be verifiable without network dependence and must declare staleness and reliance impacts.

12.4.5 **Acceptance criteria.** Must pass receipt schema validation; signature verification vectors; inclusion proof verification vectors; status resolution tests (including conflict scenarios); replay/misuse tests; transparency outage behavior tests; and SLO tests for issuance/verification latency. Failure modes MUST be explicit: degraded operation yields constrained reliance, not silent success.

***

#### 12.5 Package B — Attestation-First Check Runtime (NX-6 Trust Core)

12.5.1 **Attestation adapters.** Deliver adapters covering CI/CD pipelines, cloud runtimes, edge/OT gateways, TEEs, and AI inference endpoints. Adapters MUST produce standardized claims and bind them to CRR outputs.

12.5.2 **Appraisal policies.** Deliver appraisal policies with required claims by risk tier and reliance tier, freshness windows, endorsement trust roots, and revocation semantics. Policies MUST support constrained environments and declare acceptable degradations.

12.5.3 **Binding attestation to CRR and PR.** Deliver binding semantics that ensure CRR outputs include attestation context and that PR receipts can declare attestation presence/absence and tier. Binding MUST prevent “receipt reuse” outside measured context.

12.5.4 **Failure handling.** Deliver deterministic outcomes for attestation failure: deny, degrade, quarantine, escalate, and issue corresponding docket actions and clocks. Failure behavior MUST be uniform across implementations.

12.5.5 **Acceptance criteria.** Must pass attestation verification vectors; freshness window tests; compromised endorsement simulations; negative tests (forged claims, stale claims, mismatched subjects); drift tests (endpoint configuration drift); and operational drills that demonstrate incident clocks and receipt invalidation where required.

***

#### 12.6 Package C — Profile Compiler + Conformance Suite (NX-5 Core)

12.6.1 **Normative ingestion → controls → tests pipeline.** Deliver a reproducible pipeline that maps normative text into atomic controls and test procedures, producing machine-checkable outputs and explicit testability declarations for every normative requirement.

12.6.2 **Composition engine and overlay algebra implementation.** Deliver deterministic stacking, precedence, and conflict detection/resolution under overlay algebra. The engine MUST produce explicit conflict reports, override decisions, carve-outs, and parameter narrowing outputs.

12.6.3 **Deterministic build and equivalence tests.** Deliver reproducible builds, deterministic execution plan generation, and equivalence regression testing so that changes can be evaluated for behavioral stability and portability impact.

12.6.4 **Signed release bundles (SBOM/provenance/signatures).** Deliver signed profile packages and compiler outputs with provenance attestations and SBOM metadata where applicable. Releases MUST include compatibility notes and explicit supersession metadata.

12.6.5 **Acceptance criteria.** Must pass gold vectors for profile composition and overlay handling; negative tests for conflicting overlays and malformed dependencies; determinism tests (byte-identical or declared-equivalent outputs); reproducibility tests; and migration tests verifying supersession and compatibility metadata.

***

#### 12.7 Package D — Observability + Security Normalization Minimums (NX-3/6/8 Cross-Cut)

12.7.1 **Telemetry minimum fields and linkage rules.** Deliver a minimum telemetry schema ensuring checks, receipts, dockets, and corrections are linkable end-to-end. Trace context requirements MUST be enforceable at enforcement points and included in CRR outputs.

12.7.2 **Normalized incident/security event mapping requirements.** Deliver consistent event semantics enabling cross-tool portability (SOC/NOC/ITSM/GRC) without semantic drift. Mappings MUST be versioned and subject to semantic regression tests.

12.7.3 **Drift detection and alerting hooks for triggers/OAR clocks.** Deliver drift signal types, threshold calibration guidance, and how drift events attach obligations and initiate retest/remediation clocks deterministically.

12.7.4 **Retention and handling-aware logging constraints.** Deliver retention minima and maxima by handling class and lawful basis, including redaction patterns and metadata minimization. Logs MUST not become a surveillance exhaust by default.

12.7.5 **Acceptance criteria.** Must pass telemetry completeness tests; linkage integrity tests; event mapping conformance tests; drift trigger tests; and handling compliance tests demonstrating that controlled/restricted data is not leaked through observability pipelines.

***

#### 12.8 Package E — AI Obligation Attachment Profile (NX-4/5/6)

12.8.1 **Trigger model for AI.** Deliver trigger predicates and OAR issuance rules tied to model deployment, model version change, tool enablement, prompt-risk class, domain shift, and abnormal behavior detection. Triggers MUST be replay-safe and bound to ontology event semantics.

12.8.2 **Controls.** Deliver controls for tool allowlists, prompt/output logging classes, human override requirements, kill switch governance evidence, and safe tool invocation constraints. Controls MUST define permitted inference limits and handling defaults to prevent over-collection.

12.8.3 **Model/toolchain provenance expectations and attestation requirements.** Deliver provenance requirements for model artifacts, pipelines, inference endpoints, and tool registries. Define attestation tiers for high-impact use cases and required freshness windows.

12.8.4 **Drift triggers and retest clock rules.** Deliver drift detection semantics (behavior, data, policy) and deterministic retest clock behavior. Drift must attach obligations and initiate docket workflows rather than remaining advisory.

12.8.5 **Acceptance criteria.** Must pass red-team vectors, prompt injection tests, tool misuse tests, endpoint integrity tests, drift regression tests, and override governance tests demonstrating correct CPAR logging and post-incident correction workflows.

***

#### 12.9 Package F — Crypto Agility + Post-Quantum Transition (NX-7/9)

12.9.1 **Algorithm agility and suite identifiers.** Deliver versioned cryptographic suite identifiers, negotiation policies where applicable, and verification libraries that can validate multiple suites deterministically.

12.9.2 **Dual-signing policy and migration clocks.** Deliver dual-signing windows, migration procedures, and explicit clocks for algorithm transitions. Migration must preserve verifiability of historical receipts while enabling forward-secure issuance.

12.9.3 **Archival verification bundles.** Deliver archival bundles containing receipts, status snapshots, transparency snapshots, and verification instructions sufficient for long-lived validation independent of online endpoints.

12.9.4 **Key lifecycle and emergency key policy.** Deliver key generation/storage requirements, rotation schedules, revocation procedures, compromise response plans, and constrained emergency keys with limited privileges and explicit expiry.

12.9.5 **Acceptance criteria.** Must pass algorithm migration tests; dual-signing verification tests; archival verification tests over extended time windows; compromised key drills demonstrating receipt invalidation and status updates; and fallback mode tests ensuring reliance is constrained rather than silently broken.

***

#### 12.10 Package G — Standards-as-Code Runtime (SACR) (NX-10)

12.10.1 **SAC IR and execution semantics.** Deliver the intermediate representation and deterministic evaluation semantics, including explicit treatment of probabilistic allowances via declared uncertainty fields and bounded decision policies.

12.10.2 **Deterministic evaluation and equivalence regression.** Deliver regression suites that prove semantic stability under updates, including equivalence tests demonstrating that changes are non-breaking or explicitly breaking with migration notes.

12.10.3 **Safe rollout/rollback/freeze controls.** Deliver authoring constraints, linting, simulation gates, staged rollout, canary, rollback, emergency freeze, and post-freeze review workflows with mandatory CPAR evidence.

12.10.4 **Inter-profile communication runtime (event bus contracts).** Deliver message contracts, ordering/idempotency/replay rules, and topic governance. Messaging MUST be handling-aware, preventing cross-zone leakage and enforcing least privilege.

12.10.5 **Acceptance criteria.** Must pass semantic regression tests; rollback drills; override constraint tests; replay and idempotency tests for messaging; and “misconfiguration survival” tests demonstrating safe failure outcomes and correct docket creation.

***

#### 12.11 Package H — Nexus Ontology Fabric (NOF) (NX-3 Core)

12.11.1 **Entity/relation/event model and identity resolution.** Deliver the canonical entity, relation, and event primitives and the identity resolution service supporting canonical IDs, aliasing, collision handling, and provenance binding.

12.11.2 **Provenance and uncertainty requirements; transformation manifests.** Deliver mandatory provenance fields and transformation manifests for derived assertions, including signatures, input pointers, methods, and uncertainty declarations.

12.11.3 **Trust scoring engine with bounded influence and poisoning resistance.** Deliver trust weighting rules that bound influence of any source class, include anomaly detection, quarantine pipelines, and review workflows that prevent capture and systematic manipulation.

12.11.4 **Semantic change control and semantic regression tests.** Deliver semantic versioning, supersession, integrity tests, and regression suites that prevent silent meaning changes, including tests for event semantics, relation semantics, and controlled vocabulary stability.

12.11.5 **Graph-to-controls mapping engine.** Deliver the interface that binds ontology events to triggers, binds entity scope to OARs, and updates graph state from receipts and corrections in a deterministic and auditable manner.

12.11.6 **Acceptance criteria.** Must pass ontology conformance tests; identity resolution tests; poisoning simulations; quarantine behavior tests; semantic regression tests; and graph-to-controls correctness tests that show deterministic OAR issuance under defined event sets.

***

#### 12.12 Package I — NXOSI Control Plane (NXCP) (NX-11)

12.12.1 **Expert cockpit modules.** Deliver dashboards and workflows for OAR clocks, dockets, receipts/status verification, drift and exceptions, and ontology views. Cockpit views must be evidence-backed and must not permit unlogged “out-of-band” actions.

12.12.2 **Governed low-code/no-code builders.** Deliver constrained authoring for policies, triggers, profiles, overlays, and playbooks, including templates, linting, policy impact analysis, approval gates, and audit trails. Authoring must produce machine-checkable outputs and enforce no silent edits.

12.12.3 **Simulation and what-if.** Deliver pre-deploy simulation that generates evidence: expected obligations, clocks, enforcement point coverage, blast-radius estimation, and drift forecast. Simulation outputs must be linked to subsequent deployments to show intent-to-execution consistency.

12.12.4 **Overrides/kill switch governance and CPAR logging.** Deliver break-glass constraints, time limits, mandatory approvals, mandatory CPAR logs, and post-incident review workflows that generate correction objects and publishable summaries where required.

12.12.5 **Acceptance criteria.** Must pass separation-of-duties tests; audit export tests; override misuse tests; simulation-to-deploy linkage tests; handling compliance tests; and evidence completeness tests showing every significant operational action yields an auditable CPAR trace.

***

### Timeline and Gates (12.13)

#### 12.13 0–90 Day Plan (MVP that Proves the Rail)

12.13.1 **Minimum viable artefacts.** Deliver the minimum artefact chain required for a functioning proof rail: PSA, SPP, TRG, OAR, XPL, CRR, PR, AEP index, DKT, STO, and CPAR. The MVP MUST support end-to-end linkage and status resolution, not isolated demonstrations.

12.13.2 **MVP conformance suite.** Deliver gold vectors and negative tests covering schemas, signatures, inclusion proofs, status semantics, deterministic plan generation, basic drift triggers, and correction objects. MVP success is defined by passing the suite, not by feature checklists.

12.13.3 **MVP receipt issuance + verification.** Deliver receipt issuance, inclusion proofs, status endpoints, and verification libraries supporting both online and offline verification. MVP MUST demonstrate deterministic failure behavior under outage or stale caches.

12.13.4 **MVP check runtime at 2–3 enforcement points.** Deliver enforcement at a minimal but representative set: one build-time gate, one deploy-time or runtime gate, and one incident/retest gate. Outputs MUST include CRR linkage and required telemetry fields.

12.13.5 **MVP ontology baseline and graph-to-controls mapping.** Deliver the baseline ontology primitives and the ability to evaluate triggers against ontology events and scope OARs against canonical entity sets. MVP MUST demonstrate provenance and uncertainty handling.

12.13.6 **Acceptance gates and stop-the-line criteria.** Stop-the-line triggers include: non-deterministic verification outcomes; inability to resolve status reliably; silent edits; receipt verification that requires privileged access; handling violations; inability to operate in degraded mode; or failure to generate end-to-end traceability.

***

#### 12.14 90–180 Day Plan (Operational Hardening)

12.14.1 **Expand enforcement-point coverage and attestation tiers.** Add procurement/vendor gates and additional runtime enforcement points, and enforce attestation-first requirements for defined high-impact claims. Introduce appraisal policy variants for constrained environments.

12.14.2 **Control plane simulation and governed authoring.** Deliver constrained low-code/no-code authoring, simulation evidence generation, and approvals with separation-of-duties enforcement. Begin systematic capture of operability defect reports from real deployments.

12.14.3 **Status semantics hardening and dispute workflow tooling.** Implement dispute windows, hold behavior, challenge intake, adjudication workflows, and correction publication discipline. Ensure reliance stability under corrections and supersession in real operational cycles.

12.14.4 **Resilience drills.** Run offline/degraded drills, failover drills, partition drills, and incident clock compliance drills. Produce drill receipts and docket traces demonstrating that the system remains verifiable under stress.

12.14.5 **First plugfest with third-party implementations.** Execute a controlled interoperability event where multiple implementations validate the same receipts and profiles, resolve status consistently, and pass conformance vectors. Interop results become regression locks for future releases.

***

#### 12.15 180–365 Day Plan (Federation and Scale)

12.15.1 **Federated multi-org verification and sovereign deployments.** Expand to multi-organization verification with explicit federation boundaries, role key constraints, and cross-zone handling discipline. Demonstrate sovereign deployments including air-gapped conformance zones and delayed transparency sync.

12.15.2 **Expanded profile library.** Deliver sector + hazard + jurisdiction overlays at scale, including conflict detection and portability guarantees. Establish a disciplined deprecation policy for profiles and overlays that preserves verifiability over time.

12.15.3 **Mature conformance/badging program with continuous monitoring.** Implement continuous conformance monitoring, drift alerting, and periodic re-validation. Badges become output of test evidence and status semantics, not marketing claims.

12.15.4 **Post-quantum readiness baseline.** Implement crypto agility and transition readiness policies, dual-signing windows where required, and archival verification bundles for long-lived reliance.

12.15.5 **LTS release + governance maturity gates.** Deliver an LTS branch with explicit compatibility promises, security response discipline, and governance maturity (decision logging, conformance governance, disputes tooling, and publication discipline). LTS acceptance requires stable conformance matrices and repeatable plugfest results.

***

### Open-Source Governance and Ecosystem (12.16)

#### 12.16 OSS Governance Model (Neutral and Compatible With External Standards Ecosystems)

12.16.1 **Technical Steering Committee, maintainers, and release managers.** Establish a governance structure with clear separation between maintainers (code stewardship), release managers (supply-chain integrity and publication discipline), and program stewards (ecosystem and conformance coordination). Roles must be auditable and revocable for policy violations.

12.16.2 **Contribution policy.** Define contribution pathways, review SLAs, coding standards, artifact signature requirements, and a controlled process for normative changes. Normative changes require conformance vectors and compatibility notes; emergency changes require post-incident review and recorded correction objects.

12.16.3 **Security response and vulnerability disclosure.** Implement coordinated disclosure workflows, triage SLAs, embargo handling, emergency patch releases, and advisory publication discipline. Security incidents must include receipt/status implications where applicable and must drive conformance regression updates.

12.16.4 **IP/patent posture and license strategy.** Define licensing for code, schemas, and documentation with explicit compatibility rules for third-party dependencies. Artifacts must not incorporate incompatible licenses into normative components. Contribution rules must ensure provenance and rights clarity.

12.16.5 **Neutrality safeguards.** Implement anti-capture controls including influence caps, transparent decision logs, conflict disclosures, and competition-safe participation. Critical interoperability decisions require recorded rationale, conformance impact analysis, and published compatibility matrices.

***

#### 12.17 Ecosystem Programs: Interop at Scale

12.17.1 **Plugfests and regression lock.** Establish recurring interoperability events tied to the conformance suites. Results become regression locks: future releases must not break demonstrated interoperability without explicit breaking-change declarations and migration tooling.

12.17.2 **Reference adapters marketplace.** Maintain a catalog of enterprise connectors and adapters that meet conformance requirements and publish evidence outputs correctly. Adapters must be replaceable; conformance is the portability guarantee.

12.17.3 **Training and credentialing.** Establish role-based training for operators, verifiers, maintainers, and adjudicators. Credentialing is evidence-based: holders demonstrate ability to run verification workflows, handle disputes, and maintain handling discipline.

12.17.4 **Public participation program.** Deliver safe channels for participatory ground truthing with anti-sybil protections, do-no-harm controls, escalation workflows, and transparent correction pathways. Participation produces evidence candidates, not unilateral truth claims.

***

#### 12.18 Release Engineering and Quality System

12.18.1 **Release trains and compatibility promises.** Establish nightly, stable, and LTS trains with explicit compatibility matrices and deprecation schedules. Compatibility promises must be machine-readable and testable.

12.18.2 **Signed release bundles with SBOM and provenance.** Every release includes signatures, checksums, SBOM metadata, build provenance attestations, and verification instructions. Release bundles for standards artifacts are treated as security-sensitive deliverables.

12.18.3 **Backward compatibility policy and deprecation timelines.** Define policy for breaking changes, migration windows, and end-of-support. Breaking changes require explicit status actions, migration notes, and updated conformance vectors.

12.18.4 **Performance budgets and SLO-based acceptance.** Define SLIs/SLOs for receipt issuance/verification latency, status resolution latency, transparency inclusion delay, and degraded-mode behavior. Releases that violate performance budgets are blocked or must ship with constrained reliance declarations.

12.18.5 **Continuous conformance monitoring and drift alerts.** Implement continuous verification of conformance surfaces and drift detection. Drift alerts must be actionable: they attach obligations and open dockets, not merely generate dashboards.

***

### Standardization Path (12.19)

#### 12.19 Standards Strategy: What Becomes a Standard vs What Remains Implementation

12.19.1 **Candidate normative outputs.** Stabilize and standardize: artefact schemas, receipt verification procedures, status semantics, overlay algebra, verification freshness rules, minimum telemetry linkage fields, and conformance test suites. These define interoperability and must remain implementation-neutral.

12.19.2 **Informative guidance outputs.** Keep implementation guidance flexible: deployment patterns, reference adapters, sector profiles, governance templates, and operational playbooks. These inform adoption but must not be prerequisites for basic interoperability.

12.19.3 **Compatibility posture with external standards ecosystems.** Define mapping strategies from external requirements into profiles, controls, and tests without re-authoring their content. Maintain a disciplined approach: mapping artifacts are versioned, testable, and correctionable, and do not imply endorsement.

***

#### 12.20 Working Group Roadmap and Deliverables

12.20.1 **Artefacts WG.** Owns schemas, identifiers, namespaces, linkage rules, serialization, and compatibility matrices. Delivers normative schema releases and maintains regression tests for portability.

12.20.2 **Proofs WG.** Owns receipt formats, transparency publication procedures, inclusion proof verification, offline bundle formats, and status semantics. Delivers verification libraries, gold vectors, and equivocation-related adversarial tests.

12.20.3 **Runtime WG.** Owns compiler determinism, standards-as-code runtime semantics, enforcement-point requirements, and equivalence testing. Delivers deterministic build requirements, runtime conformance suites, and safety constraints.

12.20.4 **Ontology WG.** Owns semantic model, controlled vocabulary, provenance requirements, trust scoring constraints, identity resolution rules, and semantic change control. Delivers semantic regression suites and poisoning/quarantine test scenarios.

12.20.5 **Control Plane WG.** Owns auditability, separation-of-duties requirements, low-code constraints, simulation evidence requirements, and CPAR semantics. Delivers control plane conformance suites and override misuse tests.

12.20.6 **Conformance WG.** Owns harness architecture, vectors, plugfest operations, conformance reporting formats, and continuous conformance governance. Delivers interop matrices and regression locks that prevent ecosystem divergence.

***

#### 12.21 Adoption Pathway (Pilot → Conformance → Federation → Scale)

12.21.1 **Pilot selection criteria.** Select pilots that are high-consequence, multi-party, cross-tool, and measurable. Preferred pilots include third-party oversight, continuity proof under stress, supply-chain integrity, and AI tool-use governance—where portability and correctionability provide immediate value.

12.21.2 **Adoption playbook.** Adoption proceeds through: install baseline components; select baseline profiles; apply sector and hazard overlays; apply jurisdiction overlays; run conformance suites; execute a controlled go-live; and establish continuous verification and correction workflows with defined clocks.

12.21.3 **Metrics.** Track measurable outcomes: diligence compression, re-audit reduction, time-to-verify, time-to-correct, drift detection latency, status resolution latency, percentage of verification performed receipt-only, and reduction in uncontrolled exceptions.

12.21.4 **Institutionalization.** Move from periodic audits to continuous verification by embedding enforcement points and verification into operational workflows. Establish routine review cycles where conformance results and correction objects drive standards and profile improvements.

12.21.5 **Federation expansion.** Expand to cross-organization verification by standardizing receipt exchange, status resolution, overlay compatibility, and controlled disclosure workflows—without centralizing evidence or identity.

***

#### 12.22 Part 12 Summary and Transition Forward

12.22.1 **What is ready to ship now vs next increments.** This roadmap separates the proof rail and conformance surfaces (ship first) from advanced UX and ecosystem scaling (ship once proof and correctionability are stable). The early emphasis is on receipts, status semantics, deterministic verification, and degraded-mode operability.

12.22.2 **Transition to testable minima baseline.** The next Part specifies the minimum non-negotiable requirements and acceptance criteria that must be met to claim NXOSI operability in production, including handling discipline, sovereignty constraints, determinism requirements, and correctionability guarantees.

12.22.3 **Transition to annexes.** Schemas, APIs, verification procedures, conformance vectors, profile packages, deployment blueprints, and governance templates referenced here are defined in the annex set, enabling implementers to build, test, and deploy NXOSI with measurable interoperability and audit readiness.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-osi/xii.-delivery-roadmap.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.