# X. Reference Implementation

#### 10.1 Purpose and Scope

10.1.1 **Purpose.** This Part specifies a production-grade reference stack for Nexus Standards and NXOSI that is modular, auditable, and deployable across sovereign and enterprise environments. The reference implementation establishes stable conformance surfaces—schemas, APIs, verification procedures, and operational invariants—so independent implementations can interoperate without requiring a single vendor stack. The reference stack is designed to accelerate ecosystem convergence: implementers can reuse core libraries and tests, replace subsystems behind conformance boundaries, and still produce portable proofs and examiner-operable outputs.

10.1.2 **Scope.** The scope includes: (a) component responsibilities and boundaries; (b) core artefact schemas and protocol surfaces; (c) deployment patterns for single-organization, federated, sovereign, and air-gapped operations; (d) operational practices required for reliability and security; and (e) enterprise integration “adapter” patterns for GRC, ITSM, SOC/NOC, CI/CD, procurement, and data/AI platforms. The scope also includes reference conformance harness behavior and the evidence outputs required to demonstrate correct operation.

10.1.3 **Non-execution boundary.** Reference implementation patterns must not collapse assurance into regulated execution. NXOSI produces obligations, checks, receipts, dockets, and determinations; it may route determinations into enterprise workflows but must not perform custody, underwriting, settlement, market operation, placement, claims execution, or any regulated market activity. Integration patterns must preserve separation of duties: the assurance plane remains auditable and independent even when tightly integrated with operational systems.

10.1.4 **Compatibility objective.** The reference stack is defined as “replaceable parts with stable conformance surfaces.” Replaceability is achieved by: (a) strict schema and API versioning; (b) deterministic verification rules; (c) portable receipt verification libraries; (d) explicit status and supersession semantics; and (e) conformance test vectors that validate both syntax and semantics. Implementations may vary internally, but interoperability depends on passing the same conformance suites and producing equivalent artefacts under equivalent inputs.

***

#### 10.2 Reference Stack Overview (Components and Responsibilities)

10.2.1 **Component map.** The reference stack comprises six primary subsystems with explicit contracts:

* **Profile Compiler Pipeline (NX-5):** produces Signed Profile Packages (SPP), Execution Plans (XPL), and conformance vectors from normative inputs and overlays.
* **Standards-as-Code Runtime (NX-10):** evaluates dynamic policy semantics and emits runtime evidence and drift signals under deterministic rules.
* **Check Runtimes (NX-6):** enforce controls at defined enforcement points and emit Check Run Records (CRR) with attestation and telemetry bindings.
* **Proof and Transparency Services (NX-7):** issue Proof Receipts (PR), publish inclusion proofs, expose verification endpoints, and serve status semantics.
* **Ontology Fabric (NX-3):** maintains the canonical entity/relation/event map with provenance, uncertainty, trust scoring, and graph-to-controls mapping.
* **Control Plane (NX-11):** provides governed authoring, simulation, approvals, monitoring, correction workflows, and action-as-evidence (CPAR).

Each subsystem must be implementable independently behind its conformance surfaces.

10.2.2 **Shared services.** The stack relies on shared capabilities that must be present regardless of vendor implementation: identity and key management, registry/discovery, observability and telemetry normalization, policy/artefact storage, and access-control policy enforcement for handling classes and sovereign zone constraints. Shared services must be designed to support federation and offline modes without requiring centralization.

10.2.3 **Artefact flow.** Artefacts flow through the stack as a controlled chain:

* **Inputs:** PSA/SPP (and overlays) enter via compiler and registry.
* **Attachment:** TRG/OAR bind obligations to scope, clocks, reliance tier, and handling.
* **Planning:** XPL is generated deterministically from profiles, overlays, and context snapshots.
* **Execution:** CRR records control execution, attestation binding, telemetry pointers, and exceptions.
* **Proof:** PR provides portable reliance objects; AEP retains full evidence sovereignly.
* **Case management:** DKT groups end-to-end obligations, actions, and corrections.
* **Status and correction:** STO and COR govern supersession, revocation, and scope narrowing.
* **Operator accountability:** CPAR records approvals, overrides, waivers, freezes, rollbacks, and closures.

10.2.4 **Trust-zone placement.** The stack separates components that must remain in-zone from components that can travel:

* **Sovereign-zone components:** evidence stores (AEP), sensitive ontology assertions, controlled docket details, and any processing that would violate local lawful-basis or residency constraints.
* **Portable components:** receipt verification libraries, profile packages and conformance vectors, public-safe registries, transparency snapshots, and verifier tooling.
* **Bridging components:** federated gateways that enforce handling and disclosure policies, enabling receipt travel and selective disclosure without bulk evidence export.

10.2.5 **Replaceability matrix.** Replaceability is governed by conformance boundaries. Implementers may swap:

* Datastores (graph DB, object store) provided schema, retention, and access logging rules hold.
* Transparency log backends provided inclusion proof formats and equivocation posture are satisfied.
* CI/CD, SOC, ITSM adapters provided linkage fields and audit trails are preserved.
* UI layers provided CPAR semantics, approval gates, and handling constraints remain enforced.\
  Non-replaceable elements include normative artefact schemas, receipt verification semantics, status resolution rules, overlay algebra requirements, and declared determinism constraints.

***

#### 10.3 Open Source Program Architecture (Program-Grade Delivery)

10.3.1 **Repository structure.** The reference program should separate: (a) **core** schemas/protocols/verifier libraries; (b) **reference implementations** for compiler, proof services, and minimal control plane; (c) **adapters** for enterprise systems; (d) **sector packs** (profiles, tests, playbooks); and (e) **developer tooling** (generators, linters, simulators). A multi-repo structure is preferred where core stability and review discipline are required, with extension repos for adapters and sector packs.

10.3.2 **Module boundaries.** Boundaries must prevent accidental coupling: core protocol libraries must not depend on proprietary adapters; UI must not define normative behavior; sector packs must not alter core semantics; and adapters must not introduce hidden extensions that fragment interoperability. Every module must declare: supported versions, conformance scope, and required handling constraints.

10.3.3 **Contribution pathways.** Contributions must follow recorded proposals, review gates, and test requirements. Enhancement proposals define changes to schemas, semantics, or conformance suites. Security reports use coordinated disclosure. Sector pack updates require overlay compatibility checks and semantic regression tests to prevent silent meaning drift.

10.3.4 **Release trains and compatibility promise.** The program should operate multiple release channels: development (fast), stable (validated), and long-term support (predictable). Compatibility promises apply to conformance surfaces; breaking changes require explicit major version increments, migration guidance, and supersession/status semantics that preserve reliance stability.

10.3.5 **Security response.** The program must maintain a security response process: intake, triage, embargo handling where necessary, emergency releases, advisories, and downstream notifications. Security fixes that affect proof semantics require status guidance and may require receipt invalidation rules if prior artefacts are compromised.

10.3.6 **Artifact publication discipline.** Every release—code and policy artefacts—must be published as signed bundles with checksums, SBOMs, provenance attestations, and verification instructions. Conformance vectors and negative/adversarial tests are part of the release artifact, not optional add-ons.

***

#### 10.4 Core Schemas, APIs, and Protocol Surfaces (Normative Interfaces)

10.4.1 **Artefact schemas and serialization.** NXOSI defines canonical schemas for PSA, SPP, OAR, XPL, CRR, PR, AEP index, DKT, STO, and CPAR. Serialization formats must be stable, machine-verifiable, and versioned. Every artefact includes identifiers, version, handling markers, reliance tier (where applicable), signature metadata, and linkage pointers.

10.4.2 **Registry and discovery APIs.** Discovery must support: profile lookup by identifier/version, dependency resolution, overlay retrieval, compatibility metadata, and status resolution for published artefacts. Registries must support public-safe metadata publication and controlled metadata where necessary, without leaking sensitive deployment details.

10.4.3 **Receipt verification APIs.** Verification APIs must support: offline receipt verification using cached snapshots, online status checks, inclusion proof verification, scope/time validation, reliance tier enforcement, and deterministic failure codes. Verification libraries must be portable and not require privileged access to controlled evidence by default.

10.4.4 **Status APIs.** Status endpoints must support revocation, supersession, scope narrowing, and validity windows, including deterministic resolution semantics when multiple status objects apply. Status must be cacheable for offline operation with defined freshness windows and downgrade rules.

10.4.5 **Docket APIs.** Dockets must support open/update/close operations, remediation and retest scheduling, controlled summaries, and linkage to receipts, status, and corrections. Docket APIs must preserve handling constraints and provide non-exfiltrating pointers to evidence packs.

10.4.6 **Ontology APIs.** Ontology services must support entity/event ingest, provenance submission, uncertainty declarations, identity resolution queries, and semantic version queries. API design must separate public-safe graph views from controlled graph views and enforce access control at the query layer.

10.4.7 **Control plane APIs.** Control plane APIs must support governed authoring, simulation, approvals, deployments, overrides, audit logs, and export of CPAR records. APIs must enforce separation of duties and produce evidence artefacts for material actions.

10.4.8 **Access-control policy APIs.** Access control policy must be expressed in machine-checkable form: handling classes, lawful basis declarations, selective disclosure rules, retention policies, and disclosure approval workflows. Implementations may vary, but policy evaluation outcomes must be recorded and auditable.

***

#### 10.5 Receipt & Transparency Service (NX-7 Core Subsystem)

10.5.1 **Responsibilities.** The receipt and transparency subsystem issues proof receipts as portable reliance objects, publishes inclusion proofs, exposes verification endpoints, and provides status pointers and resolution rules. It must support both high-volume operational receipts and high-consequence receipts requiring stronger authorization and audit.

10.5.2 **Receipt issuance pipeline.** Issuance binds: issuer authorization, subject and scope, profile hash, OAR and XPL references, time binding, reliance tier declaration, and handling defaults. Issuance must verify prerequisites: required CRRs exist, attestation requirements satisfied, and required telemetry linkage present.

10.5.3 **Transparency publication pipeline.** Publication must be append-only within defined semantics, produce verifiable inclusion proofs, and support monitoring hooks for anomaly detection. Publication must minimize metadata exposure and avoid embedding sensitive identifiers.

10.5.4 **Equivocation posture.** The service must implement an explicit split-view and equivocation risk posture: monitoring, auditability, consistency checks where applicable, and deterministic reliance downgrade rules when equivocation cannot be ruled out.

10.5.5 **Status integration.** Receipts must carry pointers to status endpoints. Status actions must be recorded and signed, with clear semantics for how reliance changes. Status changes must themselves be publishable under handling constraints to stabilize reliance across parties.

10.5.6 **Offline verification bundles.** The subsystem must support snapshot distribution for offline verification: transparency checkpoints, status snapshots, profile packages, and verifier libraries. Update rules define freshness, expiry, and downgrade behavior when snapshots are stale.

10.5.7 **Operational requirements.** The subsystem must publish SLOs for issuance latency, verification latency, availability, backlog behavior, and recovery time. It must support incident response procedures including emergency freeze hooks and key compromise drills.

***

#### 10.6 Attestation Adapters and Appraisal Service (NX-6/NX-7 Trust Subsystem)

10.6.1 **Attestation sources.** Attestation adapters must support multiple environments: CI/CD pipelines, cloud infrastructure, edge and OT gateways, TEEs, and AI inference endpoints. Adapters convert platform-native measurements into standardized claims consumable by appraisal policies.

10.6.2 **Appraisal policies.** Appraisal policies define minimum claims, freshness windows, acceptable measurement sources, and revocation semantics. Policies are profile-bound: high-consequence controls require stricter appraisal; lower-risk controls may allow weaker measurements with declared uncertainty.

10.6.3 **Binding to CRR and PR.** CRRs must bind to attestation evidence and appraisal decisions; PRs must bind to CRR references and declare the attestation tier achieved. Binding must prevent substitution: attestations cannot be swapped across different contexts without detection.

10.6.4 **Offline and constrained device attestations.** The subsystem must support delayed appraisal, cached endorsements, and constrained measurement sets. Where offline, attestations must be time-bound, and reliance must degrade if freshness cannot be confirmed.

10.6.5 **Failure handling.** Failure outcomes are deterministic: deny where mandatory, degrade where permitted, quarantine suspect environments, open dockets with remediation clocks, and trigger retest schedules. Failure handling must be evidence-producing, not merely operational logging.

10.6.6 **Security controls.** Attestation keys require strong protection, rotation, and revocation. Endorsement revocation and compromise response must be supported, including invalidation guidance for receipts that depended on compromised attestations.

***

#### 10.7 Profile Compiler Pipeline (NX-5 Core Subsystem)

10.7.1 **Normative ingestion workflow.** The compiler ingests normative standards text and policy intent and decomposes them into controls, tests, and triggers. Ingestion must produce a mapping record that ties each normative requirement to testable controls or explicitly scoped non-testable items with reliance constraints.

10.7.2 **Profile assembly.** Profiles are assembled from base profiles, sector profiles, hazard profiles, and overlays with explicit parameters and clocks. Assembly must produce a deterministic result given the same inputs and declared environment snapshot.

10.7.3 **Composition engine.** The compiler resolves precedence, detects conflicts, applies overlay algebra, and enforces compatibility constraints. Where conflicts cannot be resolved automatically, the compiler must fail closed or require explicit human adjudication, recorded as a governed decision.

10.7.4 **Output packaging.** The compiler produces:

10.7.4.1 **Signed Profile Packages (SPP).** Including dependencies, overlay declarations, parameter bindings, handling defaults, and conformance targets.

10.7.4.2 **Execution Plans (XPL).** Including deterministic execution graphs, enforcement points, required inputs, and fallback behavior under degraded operation.

10.7.4.3 **Conformance tests and vectors.** Including gold vectors, negative tests, and semantic regression tests for overlays and ontology bindings.

10.7.5 **Deterministic builds.** Builds must be reproducible and support equivalence testing. The compiler must emit build attestations, checksums, and provenance artifacts so independent parties can validate that the published package corresponds to declared sources and rules.

10.7.6 **Secure build and release.** Compiler outputs are signed release bundles with SBOM and provenance. Vulnerability and integrity issues in compiler dependencies require patch clocks and may require status guidance for impacted packages.

10.7.7 **Plugin model.** The compiler supports plugins for sector parsers, control libraries, policy templates, and ontology bindings, but plugins must not alter core semantics. Plugins must declare conformance scope and must be testable via the harness.

***

#### 10.8 Standards-as-Code Runtime (SACR) (NX-10 Core Subsystem)

10.8.1 **Runtime responsibilities.** SACR evaluates dynamic policy and standards semantics in real time, under deterministic execution rules, and emits evidence artifacts and drift signals. SACR is not a general-purpose automation platform; it is a constrained evaluation engine whose purpose is verifiable policy enforcement and evidence production.

10.8.2 **IR and execution model.** SACR operates on a defined intermediate representation with strict semantics. Determinism requirements apply to evaluation ordering, side-effect control, and replayability. Where probabilistic inputs exist (e.g., uncertain ontology assertions), SACR must require declared uncertainty fields and deterministic handling of confidence thresholds.

10.8.3 **Policy lifecycle.** Policies move through governed states: authoring, linting, simulation, staged deployment, canary, full rollout, monitoring, and supersession. Each transition produces evidence: approvals, simulations, deployment records, and status objects.

10.8.4 **Real-time inter-profile communication.** Inter-profile communication is handled through an event bus with explicit message contracts.

10.8.4.1 **Ordering, idempotency, replay.** Message semantics must define ordering expectations, idempotency requirements, and replay protection to avoid inconsistent policy outcomes.

10.8.4.2 **Topic governance.** Publish/subscribe permissions are least privilege and handling-aware; topic access is governed and auditable.

10.8.4.3 **Handling-aware messaging.** Messages must not leak across handling classes or zones; sensitive context must be represented as pointers with in-zone resolution, not embedded payload.

10.8.5 **Safety controls.** SACR enforces authoring constraints, sandboxing, rate limits, and resource controls. Unsafe patterns (unbounded loops, external side effects, hidden dependencies) are rejected or forced into controlled execution contexts with explicit evidence and approvals.

10.8.6 **Safe rollout and rollback.** Deployments require staged gates, canaries, rollback paths, and emergency freeze behavior. Break-glass policies require stricter approval and mandatory CPAR logging with expiry.

10.8.7 **Runtime evidence outputs.** SACR emits CRR entries (where it executes checks), drift and anomaly signals, and proof linkage metadata. Evidence outputs must be linkable to OAR/XPL and must include declared uncertainty and context snapshots where required.

***

#### 10.9 Check Runtime Patterns and Enforcement-Point Integrations (NX-6)

10.9.1 **Enforcement point taxonomy.** Check runtimes must support enforcement at:

10.9.1.1 **CI/CD gates.** Provenance checks, dependency policies, build integrity, and release signing requirements.

10.9.1.2 **Deploy gates.** Infrastructure policy validation, configuration guardrails, segmentation checks, and deployment approvals.

10.9.1.3 **Runtime gates.** Service-level policies, data access controls, agentic tool invocation controls, and runtime drift monitoring.

10.9.1.4 **Procurement/vendor gates.** Intake and verification of third-party evidence, contractual checks, remediation clock enforcement.

10.9.1.5 **Incident/retest gates.** Post-event verification and restoration confirmation with defined retest schedules.

10.9.2 **Policy-bound checks.** Checks must be defined as controls with explicit input/output contracts and deterministic evaluation criteria. Control libraries must support composability and must declare required telemetry and attestation prerequisites.

10.9.3 **Waivers and exceptions.** Exceptions are governed objects with expiry, authority, justification, and compensating controls. Exceptions must generate CPAR records and must appear in docket views and audit exports; “informal waivers” are treated as defects.

10.9.4 **Drift detection and continuous verification.** Runtimes must emit required drift signals: configuration drift, dependency drift, environment drift, model/tool drift for AI profiles, and ontology drift where relevant. Drift thresholds are profile-bound and must attach OAR clocks when breached.

10.9.5 **Telemetry requirements.** Telemetry must include linkage fields, trace context, timestamps, enforcement point identity, and retention minima. Telemetry must be handling-aware and must avoid leaking sensitive identity or controlled context.

10.9.6 **OT/IT integration patterns.** OT integration must respect safety constraints: segmented networks, gateway mediation, controlled update paths, and offline-friendly verification. OT enforcement must be explicit about what is measurable and what is inferred, with declared uncertainty.

***

#### 10.10 Nexus Ontology Fabric Implementation (NX-3 Core Subsystem)

10.10.1 **Architecture overview.** The ontology fabric is an entity graph plus relation graph plus event model, with provenance and uncertainty as first-class fields. It serves as the canonical operating map for obligations, controls, evidence, and corrections, enabling graph-to-controls mapping.

10.10.2 **Ingestion pipelines.**

10.10.2.1 **Automated feeds.** Telemetry, sensors, EO, OSINT feeds enter through ingestion adapters that normalize format, stamp provenance, and apply handling defaults.

10.10.2.2 **Participatory submissions.** Public/community submissions enter via safeguarded pipelines with anti-sybil and do-no-harm enforcement, producing evidence candidates rather than authoritative truth.

10.10.2.3 **Enterprise sync.** Enterprise systems (CMDB, asset inventories, vendor registries) sync through controlled connectors that respect lawful basis and minimize identity leakage.

10.10.3 **Provenance pipeline.** Every transformation produces a manifest: source references, transformation identity, parameters, uncertainty propagation, signatures, and handling constraints. Provenance must be queryable for audit without exposing restricted payloads.

10.10.4 **Trust scoring engine.** Trust scoring must enforce bounded influence, anomaly detection, quarantine behavior, and capture resistance. Trust scores must be interpretable: the system must disclose why a score is high or low without revealing protected sources unnecessarily.

10.10.5 **Identity resolution service.** Identity resolution assigns canonical IDs, supports aliasing and collision handling, and produces status semantics for merges/splits. Identity operations must be governed and logged due to their downstream impact on obligation scope.

10.10.6 **Graph-to-controls mapping engine.**

10.10.6.1 **Event → trigger evaluation.** Ontology events feed trigger predicates with declared uncertainty rules.

10.10.6.2 **Entity scope → OAR binding.** Scoped entity sets are bound into OARs with jurisdiction and handling constraints.

10.10.6.3 **Graph updates from receipts and corrections.** Receipts update confidence states and compliance posture; corrections update semantic and factual assertions with supersession discipline.

10.10.7 **Governance tooling.** Ontology governance includes semantic versioning, supersession objects, semantic regression tests, and controlled publication of schema changes. Meaning changes are treated as reliance-impacting and require explicit migration guidance.

***

#### 10.11 NXOSI Control Plane Implementation (NXCP) (NX-11)

10.11.1 **Architecture and security posture.** The control plane enforces RBAC/ABAC, separation of duties, and handling constraints. All material actions emit CPAR records with linkage to affected artefacts and dockets. Control plane security includes step-up authentication for sensitive actions and multi-party approval where required.

10.11.2 **Expert cockpit modules.**

10.11.2.1 **Obligations and clocks dashboard.** Tracks OAR lifecycle, deadlines, escalation paths, and dispute holds.

10.11.2.2 **Receipts and status verification dashboard.** Provides deterministic verification views, status resolution, and reliance tier interpretation guidance.

10.11.2.3 **Docket case management dashboard.** Manages remediation, retest schedules, closure criteria, and audit exports.

10.11.2.4 **Drift/exception dashboard.** Monitors waivers, anomalies, expiring exceptions, and emerging risk signals.

10.11.2.5 **Ontology view.** Provides entity maps, relations, event overlays, and provenance/uncertainty summaries under handling constraints.

10.11.3 **Governed low-code/no-code builders.** Builders are constrained authoring environments with linting, templates, and approval gates.

10.11.3.1 **Policy + trigger builder.** Produces PSAs and trigger bindings with testability checks.

10.11.3.2 **Profile + overlay builder.** Produces SPP overlays with compatibility checks and precedence declarations.

10.11.3.3 **Control + test builder.** Produces testable controls with explicit IO contracts and evidence expectations.

10.11.3.4 **Playbook/runbook builder.** Produces automation-safe operational templates linked to dockets and clocks.

10.11.3.5 **Disclosure/handling policy builder.** Encodes lawful basis, purpose limitation, and selective disclosure rules.

10.11.4 **Simulation and what-if.** Simulation produces evidence: impact analyses, blast radius estimates, drift forecasts, and adversarial scenario outcomes. Simulation results must be linkable to the policy and profile versions they evaluated.

10.11.5 **Overrides and kill switch.** Break-glass is bounded by constraints, approvals, time limits, and mandatory CPAR logging. Post-incident review workflows are integrated and enforce the creation of correction objects where needed.

10.11.6 **Operator actions as evidence.** CPAR generation is non-optional: approvals, deployments, overrides, waivers, freezes, rollbacks, and closures must emit CPAR artefacts for audit and for dispute resolution.

***

#### 10.12 Observability and Security Normalization (Cross-Cutting Implementation)

10.12.1 **Telemetry minimums and linkage rules.** Observability must support end-to-end linkage: check → receipt → docket → correction. Minimum fields include timestamps, enforcement point identity, artefact identifiers, trace context, and handling markers.

10.12.2 **Normalized incident/security semantics.** The stack must map incident and security events into a normalized vocabulary so cross-tool correlation is possible without custom vendor interpretation. Normalization must preserve provenance and uncertainty.

10.12.3 **Dashboards and alerts.** Required alert classes include drift, expiring clocks, status changes, transparency anomalies, attestation freshness failures, and waiver expiry. Alerts must be docket-generating where they create obligations.

10.12.4 **Handling-aware observability.** Observability must not become a metadata leakage channel. Logs and telemetry exports must enforce redaction, compartmentalization, and purpose limitation consistent with handling classes and sovereign zone rules.

***

#### 10.13 Evidence Pack Storage and Sovereign Zone Patterns (AEP)

10.13.1 **Storage patterns.** Evidence packs are stored in sovereign-compliant stores: object stores, vault-backed repositories, sovereign enclaves, and controlled archives. Storage must support immutability where required, retention enforcement, and audit-grade access logs.

10.13.2 **Access control patterns.** Access to controlled evidence uses policy gates, approval workflows, escrow patterns, and compute-to-data review. “Download by default” is prohibited for controlled and restricted classes unless explicitly authorized.

10.13.3 **Retention and destruction.** Policies define minimum retention for verification and audit and maximum retention consistent with privacy requirements. Destruction events are recorded and may require countersignature depending on handling class.

10.13.4 **Selective disclosure workflows.** Evidence pack summaries and controlled extracts are generated under policy, preserving verifiability: summaries must link to pack indexes, transformations, and status objects.

10.13.5 **Audit logs.** All evidence access and disclosure actions must be logged with identity (or role marker), purpose, time, objects accessed, and authorization references, and must be exportable for auditor workflows under handling constraints.

***

#### 10.14 Enterprise Integration Reference Patterns (“Adapters”)

10.14.1 **GRC integration.** Adapters map profiles and controls into GRC control catalogs, bind audits to receipts and docket chains, and provide evidence pointers rather than bulk evidence replication. GRC integration must preserve correctionability: supersession and revocation must update GRC views deterministically.

10.14.2 **ITSM/change management integration.** Dockets map to tickets with remediation clocks, retest schedules, approvals, and closure criteria. Change windows and freeze controls must be reflected in NXOSI status objects and CPAR records.

10.14.3 **SOC/NOC integration.** Security and operational incidents feed ontology events and triggers, generate OARs when thresholds are met, and route into playbooks. SOC/NOC systems must be able to verify receipts and status without privileged evidence access.

10.14.4 **CI/CD integration.** CI/CD adapters enforce policy gates, provenance checks, dependency constraints, and release attestation. Build results emit CRRs and feed receipt issuance for release integrity and deployment readiness.

10.14.5 **Procurement/vendor integration.** Vendor evidence intake is modeled as receipts and controlled evidence pointers; remediation clocks are attached contractually and operationally. Vendor conformance claims must be testable and revocable through status semantics.

10.14.6 **Data platform integration.** Data platforms synchronize asset inventories and lineage into the ontology fabric and consume ontology outputs for monitoring and policy enforcement. Integrations must support compute-to-data and avoid cross-border exfiltration of controlled datasets.

10.14.7 **AI platform integration.** AI adapters integrate with model registries and inference endpoints to bind tool allowlists, prompt/output logging classes, model provenance, and drift triggers into OAR clocks. AI controls must produce audit-grade evidence without turning NXOSI into an AI execution environment.

***

#### 10.15 Deployment Architectures and Topologies

10.15.1 **Single-organization deployment.** A single organization may deploy a central control plane with segmented sovereign zones. The architecture must isolate evidence stores and controlled ontology assertions while allowing portable receipt verification and public-safe registry operations.

10.15.2 **Federated multi-organization deployment.** Federation supports cross-organization receipt verification and status resolution with boundary enforcement. Federation does not require shared evidence; it requires interoperable receipts, shared profile semantics, and compatible status resolution.

10.15.3 **Sovereign deployment.** Sovereign deployments emphasize data residency, compute-to-data, local lawful basis constraints, and jurisdiction overlays. External parties verify via receipts and controlled disclosures without default evidence export.

10.15.4 **Air-gapped conformance zones.** Air-gapped operation requires secure update paths, signed bundle import/export, offline verification bundles, and delayed transparency sync. Air-gapped deployments must still produce verifiable receipts with defined offline status semantics.

10.15.5 **Offline and degraded operations.** The stack must support store-and-forward, delayed sync, and deterministic reliance downgrades. Degraded mode must be visible in artefacts: receipts must declare verification constraints and freshness status.

10.15.6 **High-availability patterns.** HA includes redundancy for proof services, quorum-backed status signers where required, disaster recovery for registries, and continuity plans for key compromise. HA must not centralize sovereign evidence; it must preserve zone boundaries.

***

#### 10.16 SRE, Performance, and Operational Discipline

10.16.1 **SLIs/SLOs.** Required SLIs/SLOs include: receipt issuance latency, verification latency, status resolution latency, compiler build determinism rate, docket processing latency, transparency publication delay, and system availability. SLOs must be tiered by reliance class: higher reliance requires tighter operational controls.

10.16.2 **Capacity planning and scaling.** Capacity planning must address receipt volume, transparency log growth, evidence storage growth, ontology graph growth, and federation verification load. Scaling must preserve determinism and auditability; parallelism must not create non-deterministic outcomes.

10.16.3 **Failure management.** The reference stack must implement backpressure, circuit breakers, and bounded queues. Failure modes must be deterministic and evidence-producing: if verification cannot be completed, outputs must degrade explicitly rather than silently succeeding.

10.16.4 **Change management and release governance.** Release governance includes freeze windows, staged rollouts, canaries, emergency patches, and explicit supersession discipline. Every change must be linkable to a release bundle, conformance results, and status objects when reliance may change.

10.16.5 **Security operations.** Security ops include key compromise drills, incident playbooks, monitoring for transparency anomalies, handling enforcement audits, and vulnerability patch clocks. Operational readiness is demonstrated through receipts and dockets generated by drills, not merely by policy statements.

***

#### 10.17 Compliance Posture and Regulator-Operable Outputs

10.17.1 **Examiner-operable workflows.** The reference implementation must support two primary verification workflows: (a) receipt-only verification for low-disclosure validation; and (b) controlled evidence review for audit or supervisory reliance. Workflows must be repeatable, time-bound, and produce audit trails of access and decisions.

10.17.2 **Third-party oversight packs.** The stack must generate oversight packs for vendor and third-party risk: receipts, status timelines, remediation clocks, and controlled evidence pointers. Oversight packs must enable comparable evaluation across vendors without requiring bespoke audits for each party.

10.17.3 **Audit exports.** The stack must export signed conformance reports, docket histories, status timelines, CPAR logs, and controlled summaries. Exports must be machine-readable and human-readable, with handling-aware variants.

10.17.4 **Disclosure controls and lawful basis matrices.** Every export and disclosure must include lawful basis declarations, purpose limitation, retention rules, and recipient constraints, and must be linked to access logs and approval records.

***

#### 10.18 Part 10 Summary and Transition Forward

10.18.1 **OSS vs adapters.** The reference stack distinguishes: (a) open components that define interoperability—schemas, verifier libraries, conformance harness, reference services; and (b) enterprise adapters that integrate NXOSI into existing toolchains without changing conformance semantics. The interoperability core remains neutral and portable; adapters remain replaceable.

10.18.2 **Transition to sector profiles and use cases.** The next Part demonstrates how the reference stack is applied in practice through sector profiles and end-to-end workflows, including examiner walkthroughs that show receipt verification, status resolution, docket traceability, and controlled evidence access under real constraints.

10.18.3 **Transition to roadmap and standardization path.** The subsequent Part sets out the delivery roadmap, adoption sequence, and governance path for maintaining stable conformance surfaces while enabling rapid evolution through correctionability and controlled supersession.


---

# 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/x.-reference-implementation.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.