# VI. Layered Architecture

#### 6.1 Architecture Overview 

6.1.1 **Architectural goals.** NXOSI is engineered to make standards operable as a continuous, testable, multi-party control system rather than a periodic documentation exercise. The architecture is optimized for: (a) **real-time operability** through continuous verification, drift detection, and governed override mechanisms; (b) **portability of proofs** through receipts that can be verified independently across vendors and jurisdictions; (c) **sovereignty-preserving evidence handling** through compute-to-data patterns and in-zone retention; (d) **correctionability** through explicit status, supersession, and revocation semantics that preserve stable reliance; and (e) **neutrality and ecosystem convergence** through published conformance surfaces, replaceable components, and test-driven interoperability events that reduce fragmentation.

6.1.2 **Reference model versus implementations.** NXOSI is specified as a reference architecture with strict separation between **what must be interoperable** and **what may vary by deployment**. Mandatory conformance surfaces include: canonical artefact schemas (PSA/SPP/OAR/XPL/CRR/PR/AEP/DKT/STO/CPAR), verification and status resolution procedures, profile composition rules and overlay algebra, trigger and clock semantics, minimum telemetry linkage requirements, and control-plane auditability and duty-separation constraints. Replaceable implementation choices include: observatory source stacks, telemetry platforms, workflow engines, storage backends, UI frameworks, transparency service implementations, and key-management substrates—provided they satisfy the normative interfaces and produce the required artefacts with correct semantics.

6.1.3 **Trust boundaries.** NXOSI is built around explicit, enforceable trust boundaries: (a) **sovereign zones** where sensitive evidence and identity mappings are retained under national and institutional controls; (b) **organizational boundaries** where legal responsibilities, risk ownership, and duty separation differ; (c) **federation edges** where interoperability is required without mandating centralization or shared custody; and (d) **handling-class boundaries** (Public/Controlled/Restricted) where disclosure is governed by policy, lawful basis, and do-no-harm safeguards. These boundaries are enforced through role-based authorization, key separation, policy-bound interfaces, minimal disclosure defaults, and status semantics that constrain what a relying party can infer.

6.1.4 **Non-execution boundary.** NXOSI is an assurance and operability kernel: it compiles, checks, proves, routes, and corrects—but it does not execute regulated market functions. Architectural controls prevent “execution creep” by (a) limiting outputs to determinations, dockets, proof receipts, and controlled summaries; (b) requiring external execution stacks to be separately governed and authorized; (c) enforcing integration constraints that prohibit NXOSI from initiating custody, underwriting, placement, settlement, claims execution, or market operation; and (d) making any downstream execution linkage explicit, auditable, and revocable via status objects when misused or misrepresented.

6.1.5 **Deployment modes.** NXOSI supports operationally realistic deployment modes: (a) **single-organization deployments** for internal compliance and operations; (b) **multi-organization federation deployments** where parties retain sovereignty but exchange portable receipts and status signals; (c) **sovereign/air-gapped deployments** that support offline verification bundles and in-zone compute-to-data without outbound evidence export; and (d) **offline/degraded operations** where store-and-forward, snapshot verification, and bounded reliance allow continuity during crises, partitions, or infrastructure outages. Each mode is defined by explicit policies for cache freshness, clock tolerances, degraded verification behavior, and recovery reconciliation.

***

#### 6.2 Reference Architecture Diagram Set (Informative Index)

6.2.1 **End-to-end flow diagram.** A complete flow diagram depicts Sense → Ground-Truth → Trigger → Compile → Check → Prove → Route → Monitor → Correct, showing artefact emissions, clock attachments, and the points where determinism is mandatory versus where declared uncertainty is permitted.

6.2.2 **Trust-zone diagram.** A trust-zone diagram illustrates sovereign zones, handling-class boundaries, federation edges, and evidence portability rules (“receipt travels, evidence stays”), including who can see what under each reliance tier and what must remain in-zone by default.

6.2.3 **Artefact dependency diagram.** A dependency diagram shows the canonical chain PSA → SPP → OAR → XPL → CRR → PR/AEP → DKT → STO/COR/CPAR, including the registry and status resolution pathways that make verification independent of the issuer.

6.2.4 **Control-plane operations diagram.** A control-plane diagram shows author → simulate → approve → deploy → monitor → correct, highlighting duty separation, two-person rules for sensitive operations, and action-as-evidence logging for overrides, freezes, rollbacks, waivers, and dispute holds.

6.2.5 **Ontology fabric loop diagram.** A loop diagram shows events → triggers → obligations → checks → receipts → corrections → graph updates, including provenance tagging, semantic change control, bounded influence for participatory inputs, and the feedback loop from operability defects to revised tests and profiles.

***

### 6.3 NX-1 — Connectivity & Compute Underlay

6.3.1 **Purpose and scope.** NX-1 defines the assumed substrate capabilities—connectivity, compute, storage, time sources, and isolation boundaries—that NXOSI consumes but does not prescribe. NXOSI must remain deployable across heterogeneous underlays because critical infrastructure and sovereign environments vary widely and often prohibit standardized infrastructure choices.

6.3.2 **Service descriptors.** NX-1 provides declared descriptors (SLO-like statements) for availability, latency, bandwidth, locality, and outage behaviors. NXOSI consumes these descriptors to select verification strategies, set clock tolerances, determine whether offline bundles are required, and enforce reliance-tier restrictions when underlay conditions cannot support stronger verification.

6.3.3 **Compute classes.** NXOSI supports multiple compute classes: hyperscale cloud, private cloud, edge clusters, OT gateways, sovereign enclaves, and hardware-backed isolated execution where available. NXOSI treats locality as a first-class constraint because data residency, operational safety, and cyber posture often require checks to execute near data and systems of record, not at centralized hubs.

6.3.4 **Time and ordering.** NX-1 defines trusted time sources, permissible clock drift, and ordering assumptions needed for time-bound receipts, clocks, dispute windows, and transparency publication. NXOSI artefacts rely on time binding to prevent replay and to enforce accountability, so NX-1 must provide auditable time assertions and clear drift constraints that can be tested and monitored.

6.3.5 **Degraded/partitioned operation.** NX-1 supports store-and-forward, delayed synchronization, and partition tolerance. NXOSI specifies bounded degraded behavior: when connectivity is partial, verification may be provisional at lower tiers, while higher tiers may hold issuance or fail closed; reconciliation procedures and status updates are triggered once connectivity is restored to preserve correctness and prevent hidden divergence.

***

### 6.4 NX-2 — Trustworthy Network Fabric

6.4.1 **Purpose.** NX-2 provides integrity messaging and resilient distribution for artefact pointers, status queries, workflow routing, and multi-party verification. It supports federation without requiring centralization and enables controlled cross-boundary communication under handling and lawful-basis constraints.

6.4.2 **Identity and addressing.** NX-2 supports identity and addressing for services, devices, and roles, with explicit separation between role markers and private identity mappings where required. Addressing must support federation routing constraints, controlled disclosure, and service/device identity necessary for attestation contexts and anti-spoof controls.

6.4.3 **Message integrity.** NX-2 enforces message signing, replay protection, sequencing/idempotency rules, and anti-spoof mechanisms. This ensures that critical signals—receipt pointers, status updates, obligation attachments, and docket actions—cannot be forged, reordered, or replayed out of scope without detection and logged consequence.

6.4.4 **Offline-first delivery.** NX-2 implements queueing, backpressure, delivery receipts, and delayed delivery with bounded semantics. NXOSI relies on this to preserve audit trails and deterministic state transitions even under network stress, ensuring that “missing messages” become explicit states rather than hidden failure modes.

6.4.5 **Federation boundaries.** NX-2 enforces cross-organization routing constraints: handling-class filters, lawful-basis requirements, and minimal disclosure policies. Federation supports receipt exchange, status verification, and docket coordination while preventing unauthorized evidence export and limiting metadata leakage by design.

6.4.6 **Network observability hooks.** NX-2 emits minimum observability for linkage: trace context, message IDs, timestamps, and handling markers. These hooks allow NXOSI to bind workflow actions to dockets and receipts and to prove that routing and coordination occurred within declared policies.

***

### 6.5 NX-3 — Observatory + Nexus Ontology Fabric (NOF)

6.5.1 **Purpose.** NX-3 produces governed ground truth and maintains the canonical operating map of entities, relations, and events that drive triggers, obligation scope, verification priorities, and correction workflows. It is the semantic foundation that allows standards to bind to real systems and hazards rather than to vague narratives.

6.5.2 **Observatory fusion model.**

6.5.2.1 **Source classes.** NX-3 fuses EO, OSINT, sensors/IoT, enterprise telemetry, and human/community reports as evidence candidates. Source classes determine admissibility, handling defaults, uncertainty representation, and influence bounds.

6.5.2.2 **Reconciliation and uncertainty.** NX-3 de-duplicates, correlates, and reconciles candidates into normalized event candidates with explicit uncertainty annotations and provenance chains. Uncertainty is not “noise”; it is a governed attribute that constrains triggers, reliance tiers, and required human review.

6.5.2.3 **Transformation provenance.** Derived outputs (summaries, indicators, classifications, risk scores) are transformations that must be provenance-tagged: inputs referenced, transformation steps recorded, toolchain identified, and integrity bound. Where required, derived outputs are signed and timestamped to support audit replay and dispute resolution.

6.5.2.4 **Drift and anomaly detection.** NX-3 detects drift and anomalies in signals and in graph states, emitting drift events that can trigger new obligations, reopen dockets, or require retesting. Drift detection is treated as an operational control, not merely a monitoring feature.

6.5.3 **Ontology fabric core.**

6.5.3.1 **Entity model.** Canonical entities cover assets, services, systems, vendors, controls, obligations, evidence artefacts, and governance roles. The entity model includes identity resolution, ownership boundaries, and handling markers needed for lawful processing and minimal disclosure.

6.5.3.2 **Relation model.** Relations capture dependencies, ownership, custody, exposure, influence, and trust delegation. These relations enable propagation analysis (how a hazard cascades) and scope binding (which entities are in-scope for an obligation when an event occurs).

6.5.3.3 **Event model.** Events cover hazards, incidents, changes, attestations, determinations, receipt issuance, disputes, and corrections. Events are time-bound, provenance-tagged, and linked to entity scopes, enabling deterministic trigger evaluation and docket traceability.

6.5.3.4 **Identity resolution.** Identity reconciliation supports aliases, merges/splits, and canonical ID assignment with explicit audit trails. Identity changes are governed transformations with semantic change control to prevent silent meaning shifts.

6.5.4 **Provenance, uncertainty, and trust scoring engine.**

6.5.4.1 **Trust weighting bounds.** Trust weighting is bounded, auditable, and cannot override deterministic conformance semantics. Anti-capture safeguards limit concentrated influence, enforce diversity of evidence sources, and require escalation for high-impact determinations derived from narrow input sets.

6.5.4.2 **Uncertainty declarations.** Uncertainty is represented in structured forms that travel with events and derived outputs. Confidence bands, freshness, and ambiguity declarations are mandatory where probabilistic sources exist, and they constrain which reliance tiers can be issued.

6.5.4.3 **Poisoning resistance.** NX-3 provides anomaly quarantine, source-class gating, bounded influence, and escalation rules to prevent poisoning of data, models, or ontology semantics from silently changing obligations or verifications.

6.5.5 **Participatory ground truthing pipeline.**

6.5.5.1 **Safety controls.** Anti-sybil protections, anti-coercion safeguards, protected participation measures, and identity minimization prevent retaliation and reduce manipulation. High-risk submissions default to Restricted handling and are routed through protected review processes.

6.5.5.2 **Do-no-harm handling.** Sensitive reporting is handled with strict minimization, controlled summaries, and explicit consent and lawful-basis gates. The system separates “evidence candidate intake” from “public disclosure,” ensuring that participation does not create new risk.

6.5.5.3 **Escalation pathways.** Community submissions can escalate to experts and adjudicators through clocked pathways. Outcomes may generate correction objects (e.g., reclassification, scope narrowing, revocation) and update trust scoring policies and onboarding safeguards.

6.5.6 **Graph-to-controls mapping interface.**

6.5.6.1 **Event-to-trigger binding.** Typed events map deterministically to trigger predicates, with declared uncertainty policy where applicable. This ensures triggers are reproducible and testable, not subjective.

6.5.6.2 **Entity scope-to-OAR binding.** Ontology scope sets bind obligations to explicit entity sets and boundaries (jurisdiction, geography, ownership). This prevents obligation creep and clarifies who must act by when.

6.5.6.3 **Graph updates from receipts and corrections.** Receipts and correction objects update graph state through governed transformations, preserving provenance, handling rules, and semantic versioning.

6.5.7 **Semantic change control.** Ontology changes require versioning, supersession, integrity tests, and recorded approvals. Silent meaning changes are prohibited; compatibility impacts must be declared for downstream triggers and compiled plans.

***

### 6.6 NX-4 — Trigger & Obligation Attachment

6.6.1 **Purpose.** NX-4 converts signals into enforceable, time-bound obligations through explicit trigger evaluation, scope binding, clock attachment, and status semantics. It is where standards become operational duties rather than interpretive guidance.

6.6.2 **Trigger evaluation model.** Triggers are evaluated against ontology context snapshots to ensure reproducibility. Deterministic semantics are required for conformance-critical triggers; probabilistic inputs require deterministic thresholds and explicit uncertainty representation, including policies for provisional states and escalation to human review.

6.6.3 **OAR generation rules.** OAR generation binds entity scope, hazard class, geography, jurisdiction markers, time windows, reliance tier, handling defaults, and evidence access rules. OARs must be reproducible, linkable to trigger inputs, and constrained to prevent out-of-context reuse of obligations.

6.6.4 **Clock binding and escalation ladders.** NX-4 binds verification, remediation, retest, and dispute clocks and defines escalation ladders for missed clocks. Escalations are explicit events that update dockets and may downgrade reliance tiers or force emergency review, preventing silent non-compliance.

6.6.5 **Emergency mode and break-glass constraints.** Emergency mode is policy-defined and bounded: entry criteria, approvals, compensating controls, maximum duration, mandatory post-review, and publication obligations (at least controlled disclosure) are enforced and logged as CPARs.

6.6.6 **Due process interface.** NX-4 defines challenge windows and dispute holds. During dispute, issuance of higher-tier receipts may pause, become provisional, or require additional attestation and human sign-off. Dispute state is represented via status objects to preserve reliance stability and fairness.

6.6.7 **Required outputs.** NX-4 outputs OARs, docket linkage hooks, verification procedures, and status pointers. These outputs ensure relying parties can verify obligations and clock states without relying on issuer narratives.

***

### 6.7 NX-5 — Profile Compiler

6.7.1 **Purpose.** NX-5 is the determinism and compilation layer that turns standards and profiles into runnable plans and test suites. It ensures that “what the standard means” is expressed in executable artefacts with declared scope, parameters, and expected evidence outputs.

6.7.2 **Normative ingestion.** NX-5 decomposes normative requirements into controls and tests and flags operability defects when requirements are ambiguous, non-testable, or conflict across overlays. Every MUST must map to an executable control/test or be explicitly reclassified with scope-limited guidance semantics.

6.7.3 **Composition and overlay resolution.**

6.7.3.1 **Precedence and conflict detection.** NX-5 applies deterministic precedence rules and detects conflicts across base, sector, hazard, mission, and jurisdiction overlays, producing machine-readable conflict reports and prescribed resolution mechanisms.

6.7.3.2 **Overlay algebra and compatibility.** Overlay algebra implements carve-outs, parameter narrowing, and duty escalation while enforcing compatibility constraints that prevent meaning drift and hidden divergence. The compiler rejects overlays that violate “what may not be changed” rules.

6.7.3.3 **Parameter binding.** Thresholds, clocks, scope defaults, reliance tier constraints, and handling defaults are bound explicitly, recorded for replay, and validated against allowed ranges and safety constraints defined by the profile.

6.7.4 **Build outputs.**

6.7.4.1 **SPP build.** Signed profile packages include dependencies, composition declarations, event/message contracts, and conformance targets.

6.7.4.2 **XPL build.** Deterministic execution plans bind OAR context to enforcement points, required inputs, verifiers, and degraded-mode behavior.

6.7.4.3 **Conformance tests and gold vectors.** The compiler emits conformance test suites and vectors, including negative and adversarial cases where designated, and declares expected receipt patterns and status behaviors.

6.7.5 **Determinism and equivalence.** NX-5 supports reproducible builds and equivalence testing across compiler/runtime versions. Equivalence evidence becomes part of release bundles and is required for upgrades in high-consequence environments.

6.7.6 **Secure release posture.** Compiler outputs are released as signed bundles with SBOM, provenance, checksums, dependency constraints, and vulnerability advisory references. Release integrity is required so NXOSI can credibly enforce supply-chain requirements downstream.

6.7.7 **Compiler conformance surfaces.** NX-5 exposes conformance surfaces for: compilation determinism, overlay resolution correctness, conflict handling correctness, parameter validation, expected artefact emission, and compatibility metadata correctness.

***

### 6.8 NX-6 — Check Runtimes

6.8.1 **Purpose.** NX-6 executes controls at enforcement points and emits evidence artefacts in forms that can be independently verified. It is the runtime truth layer that bridges policy intent and measurable system state.

6.8.2 **Enforcement points.**

6.8.2.1 **Build-time gates.** CI/CD checks enforce provenance, dependency hygiene, secure build policy, and artefact signing requirements; failures are recorded and linked to release dockets.

6.8.2.2 **Deploy-time gates.** Infrastructure policy checks enforce configuration hardening, segmentation, secrets handling, and change control adherence, binding deployment actions to approval and evidence artefacts.

6.8.2.3 **Runtime gates.** Runtime enforcement covers service policy, access control, data handling constraints, and agentic tool invocation constraints (allowlists, prompt/output logging, tool telemetry), including kill switch triggers for high-risk events.

6.8.2.4 **Procurement/vendor gates.** Vendor conformance checks verify required receipts, status validity, and declared coverage; procurement outcomes are docketed and linked to contract clauses and expiry/retest schedules.

6.8.2.5 **Incident and retest gates.** Post-incident verification validates remediation, re-establishes assurance posture, and enforces mandatory retest schedules and dispute windows where incident causality is contested.

6.8.3 **Attestation binding.** For defined risk classes and reliance tiers, NX-6 binds checks to measured state via attestation evidence and appraisal results with freshness windows. Attestation failure semantics are deterministic and may force reliance tier downgrade, escalation, or issuance refusal.

6.8.4 **Telemetry and lineage hooks.** NX-6 emits trace context and observability events sufficient to bind CRR → PR → DKT. Telemetry is handling-aware; restricted telemetry stays in-zone while controlled summaries travel as permitted.

6.8.5 **Exceptions and waivers.** Exceptions are governed objects with authority, expiry, and compensating controls. Their use is always logged and may alter reliance eligibility; repeated or prolonged waivers trigger escalation and potentially mandatory correction workflows.

6.8.6 **Drift detection.** Continuous verification detects drift in configuration, dependencies, identity bindings, policy versions, model/tool/prompt states, and data access patterns. Drift is treated as a first-class trigger input with explicit uncertainty and escalation rules.

6.8.7 **Runtime conformance surfaces.** Conformance includes correct CRR emission, correct linkage and trace context, deterministic outcomes on failure, correct waiver behavior, correct attestation binding, and correct interaction with status semantics and clocks.

***

### 6.9 NX-7 — Evidence & Proof

6.9.1 **Purpose.** NX-7 produces portable reliance objects and manages sovereign evidence retention. It enables independent verification without requiring the relying party to trust the issuer’s process or to demand unlawful evidence export.

6.9.2 **Proof receipt issuance model.**

6.9.2.1 **Receipt fields and signing.** Receipts bind issuer authorization, subject and scope, profile and plan bindings, time binding, reliance tier, handling class, and verification procedure references. Receipts are signed under defined key policies with rotation and revocation procedures.

6.9.2.2 **Inclusion proof and publication.** Where required, receipts are published to transparency services with inclusion proofs and declared equivocation posture. Publication is governed by handling class and metadata minimization rules to prevent leakage.

6.9.2.3 **Status pointers.** Receipts include status endpoints and rules for status resolution, caching, and offline verification. Status is the mechanism by which reliance remains stable under correction rather than collapsing into disputes.

6.9.2.4 **Permitted inference constraints.** Receipts include explicit “what this means / does not mean” constraints. This prevents misuse as endorsements, prevents scope inflation, and preserves safety and fairness in multi-party reliance.

6.9.3 **Evidence pack retention model.**

6.9.3.1 **Sovereign storage.** Evidence packs are stored in-zone with access logging, role-based controls, and retrieval policies. Storage supports escrow and controlled compute-to-data verification patterns where cross-party review is required.

6.9.3.2 **Handling enforcement.** Handling class enforcement governs selective disclosure, redaction policies, transformation provenance, and do-no-harm constraints. Evidence transformations are logged and linked to the receipts they support.

6.9.3.3 **Lawful basis matrices.** Disclosure is governed by lawful basis and purpose limitation with recorded approvals, expiry, and revocation pathways, preventing evidence from becoming a de facto surveillance or uncontrolled data-sharing system.

6.9.4 **Offline verification bundles.** Offline verification bundles support crisis operations and air-gapped environments, containing snapshots and verification procedures with explicit freshness and expiry. Offline reliance is bounded and reconciled when connectivity returns.

6.9.5 **Equivocation and compromise response.** NX-7 defines response to equivocation, key compromise, or integrity failures: emergency freeze hooks, receipt invalidation via status objects, re-issuance policies, and mandatory incident docketing with controlled publication.

***

### 6.10 NX-8 — Rails (Routing, Workflow, and Integration)

6.10.1 **Purpose.** NX-8 turns proofs into operational coordination without crossing into regulated execution. It creates dockets, routes determinations, and integrates with enterprise systems to drive remediation, retest, oversight, and governance actions under clock-based accountability.

6.10.2 **Docketing service model.** Docket services manage the lifecycle of cases, link artefacts end-to-end, enforce clock transitions, and maintain audit-ready summaries. Dockets become the operational unit for multi-party coordination, including disputes and correction workflows.

6.10.3 **Determinations and routing constraints.** Determinations describe outcomes and required actions but do not execute regulated settlement or market actions. Integrations must preserve this boundary by ensuring NXOSI outputs are advisory/routing artefacts consumed by properly authorized systems and processes.

6.10.4 **Integration surfaces.** Integrations support SOC/NOC, ITSM, GRC, procurement, and resilience management. Integrations are handling-aware, minimize disclosure, and preserve linkage integrity so that enterprise actions remain provably connected to obligations, checks, and receipts.

6.10.5 **Supervisory packet generation.** Examiner-operable packets can be generated under controlled disclosure: summaries, receipt chains, status resolution evidence, clock compliance, and docket actions. Where deeper evidence is required, in-zone verification or escrow-mediated access is used rather than broad data export.

6.10.6 **Data minimization and handling compliance.** Integrations enforce minimal disclosure by default, restrict metadata leakage, and ensure that exported artefacts remain within the declared reliance tier and handling class semantics.

6.10.7 **Rails conformance surfaces.** Conformance includes required APIs, correct artefact linkage, correct handling propagation into workflows, audit trail completeness, and correct dispute-hold behavior.

***

### 6.11 NX-9 — Correction & Learning

6.11.1 **Purpose.** NX-9 governs disputes, corrections, and learning as first-class operations. It ensures that when errors occur or evidence changes, the system corrects transparently without destabilizing historical reliance or enabling silent manipulation.

6.11.2 **Dispute workflow.** Disputes follow defined clocks and procedures: challenge → review → adjudicate → remedy → publish. Dispute holds and provisional states are explicit status conditions, ensuring fairness and preventing hidden reliance on contested artefacts.

6.11.3 **Supersession and revocation semantics.** Status objects define revocation, supersession, and scope narrowing. They include verifier obligations, migration notes, and declarations of what remains historically valid and what must be treated as invalid or limited.

6.11.4 **No silent edits enforcement.** No silent edits apply across standards artefacts, profiles, ontology semantics, receipts, and operational actions. Every change that affects meaning, scope, or reliance must be recorded, statused, and linkable.

6.11.5 **Lessons learned feedback loop.** Correction outcomes and operability defects feed back into standards text, profile parameters, tests, compiler rules, and ontology governance. This creates measurable reduction in ambiguity, faster remediation, and improved cross-party interoperability over time.

6.11.6 **Publication controls.** Corrections and defects are published with handling discipline: public-safe summaries where appropriate; controlled disclosures for operational stakeholders; restricted disclosures where safety, confidentiality, or sovereign constraints require it.

6.11.7 **Correction conformance surfaces.** Conformance includes status endpoint semantics, correction object schemas, dispute clock enforcement, and required verifier behavior under revocation/supersession/scope narrowing.

***

### 6.12 NX-10 — Standards-as-Code Runtime (SACR)

6.12.1 **Purpose.** NX-10 executes dynamic policies and standards as verifiable code with controlled evolution. It enables “living standards” that are continuously enforced while preserving determinism, auditability, and stable reliance semantics.

6.12.2 **Intermediate representation and semantics.** NX-10 defines an IR that expresses obligations, triggers, scope bindings, control logic, and disclosure rules in a form suitable for deterministic evaluation. The IR supports explicit parameter binding, dependency declarations, and policy linting constraints that prevent unsafe constructs.

6.12.3 **Deterministic evaluation and equivalence.** NX-10 guarantees deterministic outcomes for conformance-critical semantics and supports equivalence testing across versions. Equivalence evidence is required to demonstrate that upgrades do not silently change meaning, especially under high reliance tiers.

6.12.4 **Safe rollout lifecycle.**

6.12.4.1 Authoring constraints and linting prevent ambiguity and unsafe patterns.\
6.12.4.2 Simulation and impact analysis estimate blast radius, obligation attachments, and evidence outputs before deployment.\
6.12.4.3 Staging, canary, rollback, emergency freeze, and controlled re-enable ensure operational safety under change.

6.12.5 **Inter-profile communication runtime.** NX-10 supports event semantics and message contracts with handling markers, ordering/idempotency requirements, and version compatibility constraints so that profiles can interoperate and “talk” in real time without semantic drift.

6.12.6 **Policy change governance.** Changes emit status objects, supersession metadata, and migration notes, and are linked to CPAR approvals and, where relevant, dispute windows. Silent changes are prohibited by construction.

6.12.7 **Runtime conformance surfaces.** Conformance includes determinism proofs, equivalence test results, correct event semantics, correct handling enforcement at runtime, and correct interactions with receipt issuance and status resolution.

***

### 6.13 NX-11 — NXOSI Control Plane (NXCP)

6.13.1 **Purpose.** NX-11 is the singular operational cockpit for end-to-end standards operations, providing governed authoring, simulation, deployment, monitoring, dispute handling, and correction workflows with full auditability and duty separation.

6.13.2 **Expert cockpit functions.**

6.13.2.1 Obligation dashboards show OARs, clocks, scope, and current compliance posture.\
6.13.2.2 Docket views show case lifecycle, remediation progress, retest status, and dispute holds.\
6.13.2.3 Receipt and status verification views enable independent verification and status resolution checks.\
6.13.2.4 Drift, exceptions, and operational risk posture views provide continuous assurance posture with thresholds and escalation.

6.13.3 **Governed low-code/no-code builders.**

6.13.3.1 Policy and trigger builder with linting, test generation prompts, and handling defaults.\
6.13.3.2 Profile and overlay builder with composition previews, conflict detection, and compatibility checks.\
6.13.3.3 Playbook/runbook builder producing automation-safe templates linked to obligations and clocks.\
6.13.3.4 Evidence/disclosure policy builder enforcing lawful basis matrices, redaction rules, and selective disclosure.

6.13.4 **Simulation and what-if.**

6.13.4.1 Pre-deploy evaluation and blast radius estimation across entities, dependencies, and jurisdictions.\
6.13.4.2 Drift forecasting and threshold calibration to reduce false positives and basis-risk-like enforcement gaps.\
6.13.4.3 Adversarial and negative scenario rehearsals to validate resilience, dispute handling, and emergency mode behavior.

6.13.5 **Overrides and kill switch.**

6.13.5.1 Break-glass constraints and mandatory logging via CPAR, including authority and compensating controls.\
6.13.5.2 Post-incident review workflows producing correction objects, status updates, and—where permitted—controlled publication.

6.13.6 **Role-based views and duty separation.** NXCP enforces separation of duties, conflict-of-interest constraints, two-person rules for sensitive actions, and handling compliance across UI and APIs, with auditable role-marker logging that minimizes identity disclosure.

6.13.7 **Control plane conformance surfaces.** Conformance includes CPAR completeness, enforced approval gates, duty separation correctness, override constraints and review enforcement, simulation gating correctness, and handling-aware disclosure behavior.

***

#### 6.14 Cross-Layer Invariants

6.14.1 **Identity, keys, authorization, and role separation.** A consistent authorization model applies across all layers: role-based keys, auditable key lifecycle management, revocation/rotation procedures, and duty separation constraints that prevent single-actor control of high-impact operations.

6.14.2 **Handling classes and sovereign zones.** Handling markers and sovereign-zone constraints apply end-to-end across processing, storage, messaging, and disclosure. Minimal disclosure is the default; any expansion of disclosure requires explicit lawful basis, recorded approvals, and bounded time windows.

6.14.3 **Evidence lineage by default.** Artefacts and events are linkable end-to-end. Every significant transformation is provenance-tagged, reproducible under declared policies, and constrained to prevent silent semantic drift and “untraceable decision-making.”

6.14.4 **Crypto agility and transition strategy.** Verifiable objects include cryptographic suite identifiers and upgrade paths. Transition windows, dual-signing policies, and archival verification requirements are enforced through policy and reflected in status semantics.

6.14.5 **Availability and degraded modes.** Each layer defines degraded-mode behavior consistent with reliance tiers and clocks. Offline verification policies, cache freshness rules, and reconciliation procedures are explicit so reliability does not depend on hidden assumptions.

6.14.6 **Interoperability and versioning discipline.** Semantic versioning, compatibility constraints, breaking-change rules, and deprecation policies apply across schemas, profiles, verification procedures, and runtime semantics. Interoperability is treated as a testable property, not a claim.

6.14.7 **Supply-chain integrity for NXOSI itself.** NXOSI components follow secure release discipline with SBOM, provenance, signed bundles, patch clocks, and vulnerability response procedures. This ensures NXOSI meets the same integrity standard it requires from ecosystems and vendors.

***

#### 6.15 Part 6 Summary and Traceability Forward

6.15.1 This Part defines NXOSI as a layered architecture with explicit trust boundaries, enforceable non-execution perimeter, and cross-layer invariants that preserve sovereignty, portability of proofs, correctionability, and neutrality under multi-party conditions.

6.15.2 Architecture-to-requirements traceability binds functional, assurance, security, sovereignty, resilience, cryptographic longevity, and enterprise integration requirements to specific layers and conformance surfaces, enabling procurement-grade evaluation and implementation-grade test planning.

6.15.3 The next Part specifies interoperability and testability in operational terms: conformance targets, verification procedures, compatibility and deprecation rules, and test harness requirements that make the architecture enforceable, auditable, and ecosystem-scalable.


---

# 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/vi.-layered-architecture.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.