# IV. Conceptual Model

#### 4.1 System Overview and Core Claims

4.1.1 **NXOSI as an operational kernel.** NXOSI is the operational kernel that converts standards from static text into live operational truth. It compiles standards artefacts and profile packages into deterministic execution plans, executes controls at defined enforcement points, issues portable proof receipts, routes docketed case files across operational and oversight workflows, and governs correction through explicit status objects. The system is designed to support continuous verification while preserving a strict non-execution perimeter for regulated activities.

4.1.2 **Three interoperability seams.** NXOSI operationalizes three seams that determine whether interoperability is real in production:\
(a) **portable proofs**—receipts that can be verified independently across organizations, while evidence may remain sovereign;\
(b) **machine-attachable obligations**—triggers, clocks, scope binding, and status semantics that attach obligations deterministically to entities and events; and\
(c) **testable trust**—verification bound to measured state (where required), with transparency publication and revocation/supersession semantics that stabilize reliance.

4.1.3 **All-hazards, all-of-society posture.** NXOSI is designed for multi-domain hazards (cyber, outage, climate/disaster, supply chain, AI incidents), multi-party governance environments, and mixed connectivity conditions including offline-first and air-gapped modes. It assumes that high-consequence systems must maintain operability and verifiability under stress, not only in ideal network conditions.

4.1.4 **Trust boundaries and non-execution boundary.** NXOSI defines explicit trust boundaries between: (a) standards authorship and compilation; (b) runtime verification and enforcement points; (c) evidence retention zones and disclosure controls; (d) transparency and status publication; and (e) regulated execution systems (which are out of scope). NXOSI produces verifiable assurance artefacts; it does not execute regulated financial or market activities.

***

#### 4.2 Governance and Firewall Doctrine (Non-Execution Perimeter)

4.2.1 **Assurance-only perimeter.** Within its permitted perimeter, NXOSI may: define and publish standards artefacts, profiles, controls, tests, and verification procedures; execute checks for conformance; issue proof receipts and status objects; maintain registries for discovery and version tracking; support docketing and correction workflows; enable controlled disclosure under handling rules; and produce examiner-operable verification bundles.

4.2.2 **Prohibited execution functions.** NXOSI and Nexus Standards MUST NOT provide custody, underwriting, market operation, brokering/placement, claims execution, payment execution, asset management, or any function requiring regulated licensing for execution. NXOSI outputs may be consumed by properly licensed execution entities operating outside the NXOSI perimeter, but NXOSI itself remains assurance and operability infrastructure.

4.2.3 **Independence and separation of duties.** The conceptual model assumes that assurance integrity requires independence: the party authoring standards artefacts should be separable from the party operating enforcement points; the party issuing a receipt should be separable from the party benefiting from that receipt; and adjudication of disputes should be separable from operational execution. Separation of duties is enforced through role-based access controls, approval workflows, and logged operator actions.

4.2.4 **Due process expectations.** The system implements due process through clocked challenge windows, dispute clocks, appeal paths, and recorded outcomes. Corrections occur through explicit objects (supersession, revocation, scope narrowing), preserving historical references while enabling reliance updates. The system is designed so that disputes can be resolved with reproducible evidence and deterministic semantics rather than informal interpretations.

4.2.5 **Anti-capture and competition-safe posture.** The conceptual model assumes multi-party participation and therefore requires safeguards against capture and anticompetitive coordination. Participation constraints, conflict-of-interest policies, influence limits, recusal procedures, and safe-meeting controls are treated as integrity requirements because they preserve the neutrality of standards operations and the reliability of conformance outputs.

***

#### 4.3 Normative Language and Interpretation Rules

4.3.1 **Normative keywords.** The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as requirements of conformance where they appear in normative sections and normative annexes. Non-normative sections are explanatory unless explicitly marked otherwise.

4.3.2 **Deterministic requirements and declared uncertainty.** Conformance-critical semantics MUST be deterministic: profile composition, overlay precedence, trigger evaluation, clock computation, receipt validation logic, and status interpretation. Where probabilistic methods are permitted (e.g., anomaly scoring, classification confidence), the allowance MUST be explicit and bounded by: declared uncertainty representation, deterministic thresholds for decisions, and deterministic audit replay rules for higher reliance tiers.

4.3.3 **Ambiguity elimination discipline.** Every MUST must be testable, or it must be explicitly scoped as non-testable guidance with stated limitations. Where a requirement cannot be made testable, the system treats it as an operability defect to be resolved through additional definitions, new controls, or new test vectors.

4.3.4 **Backward compatibility and breaking changes.** Normative artefacts, schemas, and verification procedures must follow breaking-change discipline. Breaking changes require major version increments, explicit migration notes, and compatibility constraints. Non-breaking changes require explicit change logs and status semantics. Silent meaning changes are prohibited.

***

#### 4.4 Core Doctrines (Design Principles That Govern Everything)

4.4.1 **Evidence-first operations.** NXOSI prioritizes verifiable proof objects over narrative reports. The primary unit of reliance is a proof receipt plus its status semantics and verification procedure. Narrative reports may exist, but they are subordinate and may not supersede proof semantics.

4.4.2 **Clocks and accountability.** Obligations are time-bound: attach, verify, remediate, retest, dispute, and close. Clocking transforms standards from aspirational language into operational accountability, and it enables automated escalation and audit completeness.

4.4.3 **Correctionability.** The system enforces no-silent-change discipline through explicit correction objects. Supersession, revocation, and scope narrowing are first-class, queryable, and auditable. Corrections preserve historical references while updating reliance in a controlled, time-bounded manner.

4.4.4 **Sovereignty by default.** Evidence stays in-zone; receipts travel. The system is designed so that verification can occur without bulk export of sensitive evidence, and so that controlled disclosure is performed only under lawful basis and handling clearance.

4.4.5 **Minimal disclosure.** For each reliance tier, NXOSI reveals the least information required to justify the permitted inference. Privacy, safety, and critical infrastructure constraints are treated as baseline requirements, not deployment-specific add-ons.

4.4.6 **Attestation-first trust.** For defined high-impact claims, proof issuance is bound to measured state through attestation policies and appraisal rules. This shifts trust from reputation to verifiable execution context.

4.4.7 **Open and enterprise-ready.** NXOSI is open by design: stable interfaces, published schemas, and conformance suites enable multi-vendor interoperability and portability. Enterprise readiness is achieved through secure release discipline, long-term support packaging, and integration patterns into operational tooling.

***

#### 4.5 Reliance Model (Who Can Rely, and on What)

4.5.1 **Reliance tiers.** NXOSI defines reliance tiers:\
(a) **informational**—limited assertions for situational awareness;\
(b) **operational**—bounded reliance for internal operational decisions;\
(c) **audit**—reliance for formal assurance processes; and\
(d) **supervisory**—bounded reliance suitable for high-stakes oversight contexts where applicable.\
Each tier defines required fields, determinism expectations, attestation requirements, and disclosure minima.

4.5.2 **Required disclosure minima per tier.** Higher tiers require stronger reproducibility and stronger evidence linkage. Informational receipts may omit sensitive details; supervisory-tier receipts require richer provenance, explicit version bindings, and stricter status resolution procedures, while still respecting minimal disclosure constraints through sovereign evidence retention.

4.5.3 **Reliance prohibitions.** A receipt or badge does not imply endorsement, absence of defects, or compliance beyond its scope. It does not authorize regulated execution or substitute for legal determinations. Receipts may not be used to infer properties not tested or not declared by the applicable profile and reliance tier.

4.5.4 **Reliance stability under correction.** Reliance is stable because corrections are explicit. A relying party determines validity by verifying receipt integrity and status at the relevant time window and scope. Supersession and scope narrowing do not erase historical receipts; they contextualize them with explicit validity semantics.

4.5.5 **Reliance conflicts and resolution.** Conflicts are resolved through status objects, clocks, and scope narrowing. Where a receipt is disputed, interim status may be applied while investigation proceeds. Dispute outcomes produce correction objects and explicit updates that allow relying parties to converge on a consistent interpretation.

***

#### 4.6 Handling Classes and Sovereign Data Zones (Disclosure Architecture)

4.6.1 **Handling classes.** NXOSI uses handling classes:\
(a) **Public**—safe for open distribution;\
(b) **Controlled**—limited distribution with forwarding restrictions; and\
(c) **Restricted**—need-to-know distribution with strict controls.\
Handling class governs storage, access, distribution behavior, and what can be published to registries and transparency services.

4.6.2 **Sovereign data zones.** Evidence packs and sensitive telemetry are retained within sovereign or controlled zones. Compute-to-data patterns allow verification to occur in-zone while emitting portable receipts and minimal disclosures outward. Access logging and two-person control rules apply where required by handling class.

4.6.3 **Lawful basis and purpose limitation.** Processing and disclosure are constrained by lawful basis and purpose limitation. Disclosures must be time-bounded, recorded, and auditable. The system is designed to support jurisdiction overlays that implement different lawful-basis matrices without forking core semantics.

4.6.4 **Redaction and selective disclosure.** NXOSI supports selective disclosure by producing: (a) minimal receipts for verification; (b) controlled summaries for operational reliance; and (c) in-zone evidence pack access for audit and oversight where lawful basis permits. Redaction is treated as a governed transformation with provenance and integrity binding.

4.6.5 **Retention and destruction.** The model supports minimum retention required for verification, dispute resolution, and long-lived validation, while enforcing privacy constraints through retention schedules and destruction attestations where applicable. Archival verification bundles may be used to support long-lived reliance without indefinite data retention.

4.6.6 **Protected participation and do-no-harm safeguards.** Participatory inputs are handled with safety constraints: protected reporting pathways, anti-retaliation controls, anti-coercion measures, and bounded influence rules to prevent harm, misattribution, or targeting.

***

#### 4.7 Integrity Primitives (Testable Trust Components)

4.7.1 **Attestation model.** NXOSI adopts an attestation posture where verification outputs may bind to measured state. Evidence is produced by an attester, claims are derived, and appraisal policies determine whether the evidence satisfies the relying party’s requirements. Attestation requirements vary by reliance tier and profile risk class.

4.7.2 **Transparency publication model.** NXOSI supports transparency publication for proof receipts: inclusion proofs, append-only behavior expectations, and equivocation risk posture appropriate to reliance tiers. Transparency exists to enable independent verification without trusting a single issuer.

4.7.3 **Signing and verification model.** All verifiable objects are signed under defined authorization policies. Issuer identity and authorization are represented in a manner that supports role separation and audit. Key lifecycle—rotation, revocation, compromise response—feeds directly into status semantics and verification procedures.

4.7.4 **Status model.** Status objects implement revocation, supersession, scope narrowing, and validity windows. Status is queryable and auditable. Verification procedures specify how status must be resolved, including offline or cached modes where permitted.

4.7.5 **Anti-replay and time binding.** Proof receipts are bound to time and scope to prevent reuse out of context. Verification procedures incorporate freshness rules and anti-replay constraints appropriate to the reliance tier and hazard context.

4.7.6 **Crypto agility.** Objects carry cryptographic suite identifiers and support algorithm agility. Transition hooks support future suite migration and dual-signing windows for long-lived verification requirements.

***

#### 4.8 Interoperability Primitives (How Standards Interoperate at Runtime)

4.8.1 **Profile composition.** Interoperability is achieved by deterministic profile composition with declared precedence, overlays, and conflict resolution. Composition yields a single executable interpretation for receipt issuance and verification.

4.8.2 **Inter-profile communication.** Profiles may communicate through declared events and message contracts. Events are typed and governed by ontology semantics. Message contracts specify required fields, handling markers, ordering, and idempotency where required.

4.8.3 **Semantic interoperability.** Ontology bindings are the contract of meaning: entity identity, relation types, and event semantics are governed. Without semantic governance, identical strings can hide divergent meaning; NXOSI treats this as a primary failure mode to be prevented.

4.8.4 **Conformance surfaces.** Interoperability depends on stable conformance surfaces: canonical schemas, verification procedures, status semantics, and conformance harness vectors. Implementations may differ internally, but conformance surfaces must remain compatible.

4.8.5 **Portability guarantees.** A relying party must be able to validate receipts and status with published procedures. Offline validation is supported through snapshots and archival bundles according to reliance tier, while online validation may use live status resolution and transparency inclusion proofs.

4.8.6 **Exit and anti-lock-in design.** Conformance is portability. Receipts, profiles, dockets, and verification bundles are exportable. Replaceable components and published interfaces prevent vendor lock-in and support sovereign and enterprise procurement requirements.

***

#### 4.9 Ontology-as-Control-Surface (Canonical Operating Map)

4.9.1 **Canonical entity model.** The ontology model includes assets, services, systems, vendors, dependencies, controls, obligations, and evidence artefacts. Entities have stable identities and versioned attributes, enabling deterministic scoping of obligations and controls.

4.9.2 **Relation model.** Relations capture ownership, custody, dependency, influence, exposure, and trust delegation. Relations are first-class because hazards propagate through dependencies and because obligations often attach through supply chain and operational interconnection.

4.9.3 **Event model.** Events include hazards, incidents, changes, attestations, determinations, receipts issuance, dispute actions, and corrections. Events are time-bound and provenance-tagged, supporting trigger evaluation, clock computation, and audit replay.

4.9.4 **Provenance, uncertainty, and trust scoring.** Every object and transformation carries provenance and uncertainty declarations. Trust scoring is bounded and auditable; it does not become an opaque “score” that substitutes for evidence. Trust weighting is used to prioritize and triage, not to override deterministic conformance where required.

4.9.5 **Graph-to-controls mapping.** NXOSI implements a closed loop: events update the graph; graph changes evaluate triggers; triggers attach obligations (OARs) with clocks; obligations compile into checks; checks produce receipts; receipts update dockets and status; corrections update graph semantics and profiles; and the cycle repeats with improved operability.

4.9.6 **Semantic change control.** Ontology changes are governed like standards changes: versioning, supersession, semantic integrity tests, and recorded approvals. Silent meaning changes are prohibited because they destabilize interoperability and invalidate prior receipts.

***

#### 4.10 Human-in-the-Loop Model (Experts + Safeguarded Participation)

4.10.1 **Expert roles.** NXOSI defines expert roles including authors, reviewers, verifiers, operators, custodians, and adjudicators. Roles are separated to preserve integrity. Approvals and overrides are recorded as evidence objects.

4.10.2 **Participation model.** Public and community reporting is treated as governed evidence candidates. The system supports structured intake, provenance capture, handling classification, and bounded influence. Participation expands coverage while preventing unverified claims from becoming determinative without checks.

4.10.3 **Safety rules for participatory inputs.** Anti-sybil controls, anti-coercion measures, protected reporting channels, and do-no-harm policies are mandatory. The system prevents participation from becoming a vector for retaliation, manipulation, or targeting.

4.10.4 **Dispute and remedy pathways.** Challenge windows, escalation rules, and remedy outcomes are clocked and recorded. Dispute outcomes produce correction objects and status updates so that reliance can converge across parties.

4.10.5 **Accountability of operator actions.** Operator actions in the control plane are captured as Control-Plane Action Records (CPAR) and linked into dockets. This ensures that overrides, waivers, and emergency actions are auditable and correctable.

***

#### 4.11 System Boundaries and Interfaces (What Touches What)

4.11.1 **Internal interfaces.** NXOSI includes internal interfaces between compiler, runtime, proof services, ontology fabric, registries, and the control plane. These interfaces are governed by canonical schemas and versioned contracts to ensure determinism and reproducibility.

4.11.2 **External interfaces.** NXOSI integrates with enterprise tools, telemetry sources, CI/CD pipelines, registries, and transparency services. External interfaces prioritize verifiable artefacts and status resolution over bespoke narrative exchanges.

4.11.3 **Federation boundaries.** Federation supports multi-organization deployments with sovereign zones and air-gapped modes. The conceptual model assumes that federation occurs through shared conformance surfaces, receipt verification, and registry discovery—not through centralized data pooling.

4.11.4 **Minimum interface contracts.** Interoperable deployments require minimum contracts: stable identifiers; artefact schemas; verification procedures; status semantics; event semantics and ontology bindings; and exportable verification bundles. Implementations may differ behind these contracts, but compatibility at these surfaces is required for NXOSI claims.

***

#### 4.12 Part 4 Summary and Traceability Forward

4.12.1 This Part establishes the conceptual model: core claims, doctrines, trust boundaries, reliance and handling architecture, integrity primitives, interoperability primitives, and the ontology-driven control surface. These doctrines are implemented across the layered architecture (NX-1 through NX-11) and are enforced through conformance surfaces and test harnesses.

4.12.2 Reliance, handling, and integrity primitives map directly to conformance requirements: receipt verification, status resolution, determinism, attestation binding, semantic governance, and auditability of control-plane actions. These mappings are defined in the traceability matrix and supported by normative annex specifications.

4.12.3 Canonical artefact schemas, verification procedures, status semantics, and conformance harness requirements are defined in annexes and are the authoritative source for implementation and procurement.


---

# 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/iv.-conceptual-model.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.