# V. Core Arc

#### 5.1 Purpose of the NXOSI Operational Model

5.1.1 **Why a state machine.** NXOSI uses a defined operational state machine to achieve determinism, auditability, portability, and correctionability in multi-party environments. A state machine makes explicit: (a) what inputs are admissible at each step; (b) what transformations are permitted; (c) what artefacts must be emitted; (d) what clocks attach; and (e) what conditions allow progression, pause, rollback, dispute hold, or emergency operation. This prevents “implicit process drift” and ensures that reliance objects can be reproduced and verified independently.

5.1.2 **Relationship to Nexus Standards.** Nexus Standards produce normative packages (PSA/SPP/TRG and associated controls/tests) and define verification procedures and reliance semantics. NXOSI is the execution kernel that operationalizes those packages: it compiles them into executable plans (XPL), runs checks, issues proofs (PR), manages evidence packs (AEP), opens and routes dockets (DKT), and governs correction through status and correction objects (STO/COR).

5.1.3 **Relationship to the ontology fabric.** The ontology fabric provides the canonical map of entities, relations, and events. It supplies the semantic contract of meaning for triggers, scoping, and evidence linkage. In NXOSI, ontology events and entity states drive trigger evaluation and obligation attachment; NXOSI outputs (receipts, determinations, and corrections) update the graph through governed, provenance-tagged transformations.

5.1.4 **Non-execution boundary reaffirmation.** NXOSI produces determinations and routes dockets for operational response and oversight workflows; it does not execute regulated actions. Where determinations result in regulated actions (e.g., settlement, claims, market operations), those actions are performed by external, properly authorized execution entities. NXOSI’s role is to provide verifiable assurance artefacts and traceable decision records, not to perform execution.

***

#### 5.2 NXOSI End-to-End State Machine

5.2.1 **State 1 — Sense.** NXOSI ingests candidate observations and signals from the observatory and enterprise integrations. Inputs include telemetry, OSINT/EO feeds, sensor readings, change events, incident reports, and community submissions. All inputs are treated as *candidates* until ground-truthed. Each candidate MUST be stamped with source identity class, handling class, time bounds, and initial provenance metadata.

5.2.2 **State 2 — Ground-Truth.** NXOSI reconciles and de-duplicates candidates, annotates uncertainty, and binds candidates to ontology entities and event types. Ground-truthing produces: (a) normalized event candidates; (b) provenance chains including transformations; (c) uncertainty declarations; and (d) bounded influence weights for participatory inputs. Ground-truthing MUST preserve raw inputs in-zone where handling requires it, and MUST emit only permitted summaries outward.

5.2.3 **State 3 — Trigger.** NXOSI evaluates trigger predicates (TRG) against ontology events and evidence candidates. Trigger evaluation MUST be deterministic for conformance-critical triggers. Where probabilistic signals are permitted, the predicate MUST include deterministic thresholds and declared uncertainty representation. A satisfied trigger initiates obligation attachment and the creation of an OAR.

5.2.4 **State 4 — Compile.** NXOSI selects profiles, resolves overlays, and compiles a deterministic execution plan (XPL). Compilation yields: (a) the composed profile set (including precedence resolution results); (b) the control list and tests to execute; (c) enforcement points; (d) required attestations and appraisals; (e) telemetry requirements for lineage; and (f) degraded-mode behavior and escalation rules. Compilation MUST fail when conflicts remain unresolved.

5.2.5 **State 5 — Check.** NXOSI executes controls at declared enforcement points (build, deploy, runtime, procurement, incident, retest). Each check emits a Check Run Record (CRR) including inputs, outputs, pass/fail semantics, attestation context (where required), telemetry pointers, and any exceptions/waivers used. Checks MUST enforce handling constraints on inputs and outputs and MUST prevent “out-of-context reuse” of check results across scopes and time windows.

5.2.6 **State 6 — Prove.** NXOSI issues proof receipts (PR) and publishes inclusion proofs where transparency publication is required. Evidence packs (AEP) are assembled and retained within sovereign zones as required by handling class and lawful basis. Proof issuance MUST bind to: profile hash/version, scope, time, and reliance tier. Proof issuance MUST also produce or reference the applicable status endpoints and verification procedures.

5.2.7 **State 7 — Route.** NXOSI generates Determination Objects (DO) and/or Graph Determination Objects (GDO) and opens or updates Dockets (DKT). Routing integrates with enterprise workflows (SOC/NOC, ITSM, GRC, procurement) and with external oversight processes where permitted. Routing MUST remain non-executory: determinations describe outcomes and required actions; they do not execute regulated settlement or market activities.

5.2.8 **State 8 — Monitor.** NXOSI performs continuous verification and drift detection. Monitoring evaluates expiry clocks, exception expiries, and retest schedules; it detects configuration drift, dependency drift, model/tool/prompt drift, and policy drift. Monitoring may re-trigger obligations, reopen dockets, or require re-compilation and re-check. Monitoring outputs MUST be linkable to earlier receipts and dockets through immutable identifiers.

5.2.9 **State 9 — Correct.** NXOSI executes correction workflows: disputes, supersession, revocation, scope narrowing, and lessons-learned feedback. Corrections are emitted as Correction Objects (COR) and Status Objects (STO), with clocked challenge windows and recorded outcomes. Corrections update registry status, ontology semantics (where applicable), and the conformance harness backlog through explicit operability defects and releases.

***

#### 5.3 Core Artefacts Overview (Normative → Operational → Evidence → Correction)

5.3.1 **Artefact families and purpose.** NXOSI artefacts fall into four families:\
(a) **normative artefacts** (PSA, SPP, TRG) defining requirements and executable semantics;\
(b) **operational artefacts** (OAR, XPL, CRR, OBS) capturing execution planning and runtime results;\
(c) **evidence artefacts** (PR, AEP, DO/GDO, DKT) enabling portable verification, case management, and oversight; and\
(d) **correction artefacts** (STO, COR, CPAR) preserving reliance stability and accountability through explicit change control.

5.3.2 **Required metadata and identifiers.** Every artefact MUST carry: (a) globally unique identifier; (b) namespace; (c) semantic version (where applicable); (d) handling class marker; (e) reliance tier marker (where applicable); (f) time bounds (issuance time and validity window); and (g) issuer authorization reference.

5.3.3 **Linkage rules.** Artefacts MUST be linkable end-to-end via immutable identifiers. Linkage includes at minimum: PSA/SPP/TRG → OAR → XPL → CRR → PR → DKT → STO/COR, with telemetry pointers and ontology snapshot references where applicable.

5.3.4 **Determinism and declared uncertainty.** Artefacts MUST declare the determinism class of their semantics: (a) deterministic; (b) deterministic-with-declared-uncertainty; or (c) probabilistic-only (informational tier only). The declared uncertainty field MUST identify the source of uncertainty, the representation, and the decision thresholds where applicable.

***

#### 5.4 Normative Artefacts (Executable Standards Inputs)

**5.4.1 Policy/Standard Artefact (PSA)**

5.4.1.1 **Structure.** A PSA binds: policy intent; normative requirements; trigger bindings; control mappings; testability expectations; reliance tier eligibility; and handling constraints. The PSA is the canonical unit for “standards-as-code” compilation.

5.4.1.2 **Normative semantics and scope.** The PSA defines MUST/SHOULD/MAY semantics and the scope of application. Every MUST MUST map to one or more controls with tests or to an explicitly scoped guidance item. The PSA MUST declare out-of-scope areas and prohibited inferences to avoid misuse.

5.4.1.3 **Security and provenance.** PSA publication MUST be a signed release bundle, including: content hashes, change log, compatibility notes, dependency constraints, and provenance for tooling used to compile or validate the PSA.

5.4.1.4 **Compatibility and supersession.** PSA changes MUST follow semantic versioning and MUST be accompanied by explicit supersession metadata and status semantics. Silent edits are prohibited.

**5.4.2 Signed Profile Package (SPP)**

5.4.2.1 **Required fields.** An SPP MUST include profile ID, version, dependencies, overlays applied, parameter values, enforcement point declarations, reliance tier eligibility, and handling defaults.

5.4.2.2 **Composition declarations.** The SPP MUST declare stacking order, precedence, conflict detection strategy, and conflict resolution policy (override, carve-out, parameter narrowing, duty escalation).

5.4.2.3 **Inter-profile communication.** The SPP MUST declare emitted and consumed events and message contracts, including handling constraints, ordering, idempotency requirements, and dependency versions.

5.4.2.4 **Conformance targets.** The SPP MUST declare required conformance tests and expected proof outputs (receipt types, status semantics, and evidence pack index requirements) for each reliance tier.

***

#### 5.5 Obligation Attachment and Planning Artefacts

5.5.1 **Trigger Definition (TRG).** A TRG specifies predicate logic, scope defaults, clocks, reliance tier, handling defaults, and admissible evidence candidates. TRG predicates MUST bind to ontology event types and MUST be deterministic for conformance-critical triggers. TRGs MUST declare degraded-mode evaluation rules.

**5.5.2 Obligation Attachment Record (OAR)**

5.5.2.1 **Scope binding.** An OAR MUST bind obligation scope: entity set, geography, jurisdiction markers, time window, hazard class, and affected boundaries. Scope must be explicit to prevent out-of-context reuse.

5.5.2.2 **Clock bindings.** An OAR MUST include: verification deadline, remediation clock, retest clock, and dispute window. Clock computation MUST be deterministic and MUST declare business calendar rules where applicable.

5.5.2.3 **Emergency mode flags and constraints.** An OAR MUST declare whether emergency mode is eligible, what approvals are required, what compensating controls apply, and the maximum duration and post-incident review requirements.

5.5.2.4 **Disclosure defaults.** The OAR MUST declare reliance tier, handling class, evidence pack access rules, and disclosure minima. Where disclosure is restricted, the OAR must specify in-zone compute-to-data verification options.

5.5.2.5 **OAR validity.** OAR validity is governed by status objects. OAR supersession and invalidation conditions MUST be explicit, including triggers for scope narrowing, revocation, or re-attachment.

**5.5.3 Execution Plan (XPL)**

5.5.3.1 **Inputs.** An XPL is produced from SPP + overlays + OAR + ontology context snapshot. The snapshot reference MUST be recorded to support deterministic replay and dispute resolution.

5.5.3.2 **Determinism guarantees.** The XPL MUST define the execution graph deterministically for conformance-critical semantics. Equivalence checks MUST be available to demonstrate that changes in compiler/runtime do not alter intended outcomes without explicit version change and migration notes.

5.5.3.3 **Enforcement points.** The XPL MUST map controls to enforcement points (build, deploy, runtime, procurement, incident, retest) and MUST declare required runtime privileges and constraints to prevent overreach.

5.5.3.4 **Dependency resolution.** The XPL MUST declare required data sources, attestations, telemetry fields, verification libraries, and status endpoints. Dependency versions MUST be pinned or bounded and must be auditable.

5.5.3.5 **Failure handling.** The XPL MUST specify fallback behavior, degraded modes, escalation triggers, and “fail closed/fail open” policy by reliance tier and hazard class, including required human sign-off thresholds where applicable.

***

#### 5.6 Runtime and Observability Artefacts

**5.6.1 Check Run Record (CRR)**

5.6.1.1 **Core fields.** A CRR MUST include: check identifier, control identifier, XPL reference, input set, output set, pass/fail semantics, timestamps, and scope binding.

5.6.1.2 **Attestation binding.** Where required, the CRR MUST include attestation context: measured environment claims, appraisal policy reference, appraisal result, and freshness window. Attestation failures MUST yield deterministic outcomes and escalation requirements.

5.6.1.3 **Telemetry pointers and trace context.** The CRR MUST include telemetry pointers and trace context sufficient to link runtime events to the receipt and docket. Telemetry must respect handling constraints and may be summarized where required.

5.6.1.4 **Exceptions and waivers.** Any waiver/exception applied MUST be referenced, including authority, expiry, justification, and compensating controls. Use of waivers MUST be recorded as CPAR entries and may affect reliance tier eligibility.

5.6.1.5 **Determinism and replay controls.** CRRs MUST declare replay eligibility and prevent misuse outside their scope/time context. Replay for audit/supervisory reliance must be supported under defined conditions.

**5.6.2 Observability Events (OBS)**

5.6.2.1 **Required fields and linkage.** Observability events MUST carry linkage fields binding them to CRR/PR/DKT and to ontology entities/events. Minimum fields include timestamp, event type, scope, source class, handling class, and trace context.

5.6.2.2 **Normalized semantics.** Observability events SHOULD map to normalized incident/security semantics to enable cross-tool interoperability. Where mappings exist, they must be declared by profile and verified by conformance harness where designated.

5.6.2.3 **Drift and anomaly signals.** Drift and anomaly signals MUST feed monitoring clocks and may re-trigger obligations. Drift signals must include provenance, uncertainty, and threshold references.

***

#### 5.7 Proof and Evidence Artefacts

**5.7.1 Proof Receipt (PR)**

5.7.1.1 **Required fields.** A PR MUST include: issuer authorization reference; subject identity (entity reference); scope; profile hash and version; PSA reference; OAR and XPL references; time binding; reliance tier; handling class; and verification procedure reference.

5.7.1.2 **Inclusion proof and publication pointer.** Where transparency is required, the PR MUST include a publication pointer and inclusion proof data sufficient for independent verification.

5.7.1.3 **Status pointer.** The PR MUST include a status endpoint pointer for revocation/supersession/scope narrowing and MUST declare the required status resolution procedure (online/offline, cache policy).

5.7.1.4 **Permitted inference limits.** The PR MUST declare what may be inferred and what must not be inferred. This includes explicit prohibitions against implying endorsement or broader compliance beyond scope.

5.7.1.5 **Selective disclosure and redaction.** The PR MUST support selective disclosure rules appropriate to handling class, enabling verifiers to validate integrity and scope without exposing restricted evidence.

5.7.1.6 **Offline verification bundles.** Where required by environment or reliance tier, the PR MUST be verifiable using an offline bundle containing required artefacts, snapshots, and procedures with declared freshness and expiry rules.

**5.7.2 Evidence Pack (AEP)**

5.7.2.1 **Evidence contents.** An AEP MAY include raw artefacts, logs, attestations, transformations, provenance chains, test results, and analyst annotations. The AEP MUST include an index describing contents, provenance, handling constraints, and retrieval/compute-to-data options.

5.7.2.2 **Sovereign storage.** Evidence packs MUST be stored in sovereign zones as required, with zone policy references, escrow patterns where needed, and access logging. Evidence pack access is governed by lawful basis and handling class.

5.7.2.3 **Handling enforcement.** Evidence packs MUST enforce controlled access, do-no-harm constraints, and retention/destruction rules. Transformations and redactions must be provenance-tagged.

5.7.2.4 **Portability rules.** The system enforces “receipt travels, evidence stays” by default. Evidence is exported only where lawful basis and handling clearance permit, and only in minimal form required for the reliance tier.

5.7.2.5 **Retrieval protocols.** Evidence pack retrieval MUST support protocols that avoid default data exfiltration, including remote query, in-zone verification, and escrow-mediated access where applicable.

***

#### 5.8 Routing, Determinations, and Case Management Artefacts

**5.8.1 Determination Object (DO)**

5.8.1.1 **Determination types.** Determinations include conformance outcomes, risk classifications, incident classifications, readiness actions, and compliance posture summaries, each bound to defined scope and time.

5.8.1.2 **Non-execution constraints.** Determinations MUST remain routing-only and advisory within the NXOSI perimeter; they cannot instruct or execute regulated settlement, market actions, or claims execution. Where determinations are consumed by execution entities, the integration must preserve separation and prevent implied execution authority by NXOSI.

5.8.1.3 **Required linkage.** A DO MUST link to OAR/XPL/CRR/PR and to the ontology snapshot reference used, enabling deterministic replay and audit.

**5.8.2 Graph Determination Object (GDO)**

5.8.2.1 **Ontology-backed reasoning trace.** A GDO MUST include a reasoning trace referencing entities, relations, events, and evidence pointers used to derive the determination, along with applied profiles and overlay decisions.

5.8.2.2 **Confidence and uncertainty.** A GDO MUST declare confidence and uncertainty in a structured form and must identify which parts of the reasoning are deterministic vs probabilistic.

5.8.2.3 **Human sign-off by tier.** For higher reliance tiers, the GDO MUST include human-in-the-loop sign-off references, including role-based approvals and any dissent or conditions recorded.

**5.8.3 Docket (DKT)**

5.8.3.1 **Structure.** A DKT is the end-to-end case file linking obligations → checks → proofs → actions → corrections, including clock status and workflow state.

5.8.3.2 **Lifecycle.** Dockets progress through states: open, update, pending remediation, retest pending, closed, and disputed/held. Transitions are clocked and recorded, with required actions and evidence outputs at each transition.

5.8.3.3 **Integration hooks.** Dockets integrate with SOC/NOC, ITSM, GRC, procurement, and program management systems via stable interfaces. Integration must preserve handling and minimize disclosure.

5.8.3.4 **Portability and retention.** Dockets are exportable as structured artefacts with retention policies aligned to lawful basis and reliance tier. Export does not require exporting restricted evidence packs.

5.8.3.5 **Public vs controlled summaries.** Where permitted, dockets may produce public-safe summaries; controlled summaries include richer technical details. Summaries are governed transformations with provenance and handling markers.

***

#### 5.9 Status and Correction Artefacts (No Silent Edits)

**5.9.1 Status Objects (STO)**

5.9.1.1 **Revocation.** Revocation invalidates reliance for defined scopes/time windows and must state cause class, effective time, affected artefacts, and required verifier behavior.

5.9.1.2 **Supersession.** Supersession replaces an artefact with a new version and includes migration notes, equivalence constraints, and explicit declaration of what remains valid historically.

5.9.1.3 **Scope narrowing.** Scope narrowing limits reliance scope without full revocation. It must define which entity sets, time windows, or conditions are excluded and why.

5.9.1.4 **Validity windows and expiry.** Status objects define validity windows and expiry semantics, including whether a receipt requires periodic renewal under retest clocks.

5.9.1.5 **Status resolution rules.** Relying parties must resolve status per declared procedures, including offline/online behavior and cache freshness rules. Status resolution must be auditable and reproducible.

**5.9.2 Correction Objects (COR)**

5.9.2.1 **Correction triggers.** Corrections may be triggered by error discovery, dispute outcomes, new evidence, policy changes, or security incidents affecting integrity.

5.9.2.2 **Workflow.** Correction workflows follow: propose → review → publish → enforce → audit. Each step produces evidence objects and approvals with handling constraints.

5.9.2.3 **Due process.** Correction workflows include challenge rights, dispute windows, and remedy options. Interim holds may apply, with clocked resolution requirements.

5.9.2.4 **Impact analysis.** Corrections include impact analysis: what changes for relying parties, what remains valid, what migration is required, and what additional verification is mandated.

***

#### 5.10 Control Plane Actions as Evidence (Operator Accountability)

**5.10.1 Control-Plane Action Record (CPAR)**

5.10.1.1 **Action types.** CPARs record: approve, deploy, override, waive, freeze, rollback, reopen, close, and publish actions, plus delegation and recusal events.

5.10.1.2 **Authority and separation of duties.** CPARs MUST include authority references and demonstrate separation-of-duties compliance (e.g., two-person rule for defined actions, conflict-of-interest checks).

5.10.1.3 **Handling constraints.** CPARs MUST carry handling markers and must not disclose restricted identity or sensitive operational details beyond what is permitted for the relevant reliance tier.

5.10.1.4 **Linkage requirements.** CPARs MUST link to affected dockets, receipts, status objects, and relevant standards/profile versions to support audit replay.

5.10.1.5 **Post-incident review.** Overrides and kill switch usage MUST trigger post-incident review obligations, including recorded analysis, corrective actions, and supersession where required.

***

#### 5.11 Clocks, Timers, and Accountability Framework

5.11.1 **Verification clocks.** Verification clocks bind event-to-verification deadlines, including initial verification and periodic re-verification where required.

5.11.2 **Remediation clocks.** Remediation clocks bind time-to-fix requirements and escalation paths. Missed clocks MUST create recorded events, escalation triggers, and updated docket states.

5.11.3 **Retest clocks.** Retest clocks enforce mandatory re-verification schedules, including after remediation, after drift events, and at periodic intervals for defined risk classes.

5.11.4 **Dispute clocks.** Dispute clocks define challenge windows, interim hold/freeze rules, and resolution deadlines. Dispute outcomes are recorded as correction objects and reflected in status semantics.

5.11.5 **Emergency mode clocks.** Emergency mode clocks define maximum break-glass duration, required compensating controls, and mandatory post-mortem timelines.

5.11.6 **Clock publication rules.** Clocks have publication classes: public-safe clocks may be disclosed broadly; controlled clocks may be disclosed to participants; restricted clocks may be limited to need-to-know. Clock publication rules are part of handling discipline.

***

#### 5.12 Failure Modes, Degraded Operation, and Recovery Behavior

5.12.1 **Partial data and uncertainty.** Where data is partial, the system must represent uncertainty explicitly and must restrict reliance tier eligibility accordingly. The system must not silently “fill gaps” without declared assumptions.

5.12.2 **Offline verification.** Offline verification must function using cached profiles, cached transparency snapshots, and archival verification bundles with explicit freshness and expiry rules. Offline reliance is bounded by declared policies.

5.12.3 **Transparency/log unavailability.** If transparency services are unavailable, verification behavior depends on reliance tier: higher tiers may require hold/fail-closed behavior; lower tiers may allow provisional verification with explicit provisional status and mandatory later reconciliation.

5.12.4 **Attestation failures.** Attestation failures produce deterministic outcomes: downgrade of reliance tier, refusal to issue higher-tier receipts, escalation to human review, or emergency constraints depending on profile policy.

5.12.5 **Compromise response.** Compromise triggers receipt invalidation, emergency freeze, and status updates. Recovery behavior includes key rotation, re-issuance policies, incident docketing, and post-incident correction workflows.

***

#### 5.13 Part 5 Summary and Traceability Forward

5.13.1 This Part defines NXOSI’s operational determinism through a complete state machine and a unified artefact model: PSA/SPP/TRG/OAR/XPL/CRR/OBS/PR/AEP/DO/GDO/DKT/STO/COR/CPAR, linked end-to-end through immutable identifiers and governed by clocks and handling rules.

5.13.2 Artefact schemas, verification procedures, status semantics, and conformance harness requirements are specified in annexes and constitute the authoritative implementation basis.

5.13.3 The next Part maps this operational model to the layered architecture, assigning each artefact and state transition to specific layers and cross-layer invariants, enabling implementers to build interoperable deployments.


---

# 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/v.-core-arc.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.