# III. Problem Definition

#### 3.1 Problem Statement: Why Standards and Compliance Fail at Runtime

3.1.1 **The paper-compliance trap.** Most regimes are optimized for documents, periodic audits, and retrospective narratives. Runtime reality is continuous change across systems, configurations, dependencies, data flows, and operator actions. When standards remain static text, the control plane becomes people-and-spreadsheets, and “compliance” becomes an after-the-fact snapshot that cannot reliably predict or prevent failure under stress.

3.1.2 **The re-audit tax.** The ecosystem repeatedly re-proves the same properties because assurance outputs are not machine-verifiable, not composable, and not portable across vendors or jurisdictions. This produces duplicated diligence, inconsistent conclusions, delayed onboarding, and inflated costs—while leaving systemic exposures unmeasured and unowned.

3.1.3 **Late or ambiguous obligation attachment.** Obligations commonly attach through interpretation after incidents, rather than through explicit triggers and clocks. Without scope binding (what entity, what system boundary, what time window) and without deadlines (verify, remediate, retest, dispute), responsibility diffuses, escalation becomes ad hoc, and remediation cycles fail to converge.

3.1.4 **Trust asserted by identity and reputation.** Identity does not prove state. Vendor attestations and organizational reputation cannot substitute for measured environments, reproducible checks, and independently verifiable proof objects. Without attestation and deterministic verification, trust becomes a social claim instead of a testable property.

3.1.5 **Evidence non-portability.** Reports do not compose and proofs do not travel. Evidence is often bound to proprietary formats, hidden procedures, and non-repeatable assessments. This blocks cross-party comparability, prevents automated reliance decisions, and forces sensitive evidence sharing where it is neither lawful nor safe.

3.1.6 **Silent edits and unmanaged corrections.** When standards interpretations drift, controls change, or evidence is revised without explicit supersession, reliance collapses. Silent edits create unstable accountability: it becomes impossible to say which rule applied when, whether a prior receipt remains valid, or what changed and why.

3.1.7 **Cross-border sovereignty constraints.** Lawful-basis fragmentation, national security constraints, and critical infrastructure confidentiality make centralization infeasible. Systems that require bulk evidence export will fail adoption. A viable solution must enable verification using portable receipts while keeping sensitive evidence within sovereign or restricted zones.

3.1.8 **AI/agentic drift and toolchain risk.** AI systems, agentic workflows, and tool-enabled automation change faster than traditional controls can follow. Prompt/tool drift, policy injection, supply-chain compromise, and shadow deployment create unlogged behaviors that cannot be tested or relied upon. Without explicit obligation attachment, tool allowlists, provenance, and drift triggers, runtime safety becomes unprovable.

3.1.9 **Multi-party governance failure modes.** Standards initiatives fail in production when governance cannot prevent capture, conflicts of interest, anticompetitive coordination, or misrepresentation of conformance. Without neutral conformance surfaces and recorded decision outcomes, ecosystems fragment and trust becomes political instead of technical.

***

#### 3.2 Target Operating Environment (All Hazards / All of Society)

3.2.1 **Multi-party systems.** NXOSI targets environments spanning operators, vendors, integrators, auditors, regulators/supervisors, sovereign authorities, and communities. It assumes mixed incentives, partial trust, and divergent disclosure permissions.

3.2.2 **Multi-domain hazards and compound scenarios.** NXOSI must operate across cyber incidents, infrastructure outages, climate/disaster shocks, systemic supply disruptions, and AI incidents, including cascading and correlated events where triggers and obligations must coordinate across domains.

3.2.3 **Mixed connectivity and constrained operations.** NXOSI must function in offline-first, degraded, intermittently connected, and air-gapped contexts. Verification and status resolution must have defined degraded behaviors, cache policies, and emergency procedures.

3.2.4 **High-consequence environments.** Target deployments include critical infrastructure, financial stability-relevant systems, and public services where failure impacts safety, continuity, and national resilience. Assurance must be examiner-operable and dispute-resilient.

3.2.5 **Heterogeneous enterprise stacks.** NXOSI must integrate with multi-cloud, hybrid, legacy, and OT/IT converged architectures, including diverse telemetry sources, identity stacks, and operational tooling.

3.2.6 **Multi-language, multi-jurisdiction operations.** NXOSI must support localization without semantic drift: controlled terminology, versioned translations, and overlay governance that prevents meaning changes across languages.

***

#### 3.3 Design Objectives (System-Level Requirements)

3.3.1 **Executable standards.** Convert policy + standard + trigger + control into executable artefacts that can be compiled, simulated, deployed, and verified continuously.

3.3.2 **Machine-attachable obligations.** Attach obligations through triggers with scope, clocks, jurisdiction markers, reliance tier, handling class, and status semantics.

3.3.3 **Testable trust.** Make trust measurable via deterministic verification and attestation-first binding for defined high-impact claims, supported by transparency publication and revocation/supersession.

3.3.4 **Portable evidence.** Make proofs portable through receipts and status resolution, while supporting sovereign evidence retention and minimal disclosure.

3.3.5 **Real-time interoperability.** Enable stackable, verifiable profiles that interoperate, communicate, and run in real time across organizations and jurisdictions.

3.3.6 **Unified operations.** Provide a single control plane enabling end-to-end standards operations: expert cockpit, low-code/no-code authoring, simulation, governed overrides, and action-as-evidence logging.

3.3.7 **Ontology-driven system.** Establish a canonical entity/relation/event map that grounds scoping, obligations, controls, and evidence lineage, enabling a graph-to-controls feedback loop.

3.3.8 **Governed change and correctionability.** Enforce no silent edits across standards, profiles, ontology semantics, and operational actions, with explicit status objects and stable reliance semantics.

3.3.9 **Open and enterprise deployable.** Ensure neutrality through open interfaces and conformance suites, secure release discipline, long-term support packaging, and integration patterns across enterprise tooling and data fabrics.

***

#### 3.4 Functional Requirements (FR)

**3.4.1 FR-1 Executable Standards (Standards-as-Code)**

3.4.1.1 Normative artefacts MUST compile into runnable controls and tests with a machine-verifiable mapping from requirement → control → test → receipt.\
3.4.1.2 The system MUST produce deterministic execution plans (XPL) for conformance-critical semantics and MUST support equivalence testing across versions.\
3.4.1.3 The system MUST support a safe deployment lifecycle: staging, canary, rollback, emergency freeze, and controlled re-enable with recorded approvals.\
3.4.1.4 Supersession and revocation MUST be first-class objects; silent edits MUST NOT occur for any normative, semantic, or operationally relied-upon content.\
3.4.1.5 The system MUST support “policy + trigger + clock + scope” as executable constructs, not narrative guidance, including replayability for dispute resolution.\
3.4.1.6 Standards-as-code artefacts MUST be securely built and distributed (signed bundles, provenance, SBOM, dependency pinning).

**3.4.2 FR-2 Stackable Profiles and Real-Time Interoperability**

3.4.2.1 Profiles MUST be packaged for composition (base + sector + hazard + jurisdiction overlays) with explicit dependency declarations and compatibility constraints.\
3.4.2.2 Composition MUST detect conflicts and MUST resolve them deterministically via precedence, carve-outs, parameter narrowing, or duty escalation; unresolved conflicts MUST fail compilation with actionable outputs.\
3.4.2.3 Inter-profile communication MUST be supported via declared event semantics and message contracts, including ordering/idempotency rules and handling markers.\
3.4.2.4 Cross-jurisdiction interoperability MUST be supported through overlay algebra such that proofs remain verifiable and meaning does not drift across locales.\
3.4.2.5 Profiles MUST be “stackable as proof,” meaning profile composition yields a single verifiable interpretation for receipt issuance and reliance.

**3.4.3 FR-3 Trigger and Obligation Attachment**

3.4.3.1 Triggers MUST bind to ontology events and evidence candidates, including provenance expectations, uncertainty declarations, and admissible input classes.\
3.4.3.2 The system MUST generate an Obligation Attachment Record (OAR) containing: subject scope, clocks, jurisdiction markers, profile binding, handling class, reliance tier, and dispute window.\
3.4.3.3 Emergency mode MUST be explicit: entry criteria, break-glass constraints, time bounds, compensating controls, and post-incident review obligations.\
3.4.3.4 Due process MUST be clocked: challenge windows, escalation paths, interim status semantics, and remedy outcomes recorded as correction objects.\
3.4.3.5 The system MUST support obligation narrowing (scope reduction) as a first-class correction mechanism without erasing historical records.

**3.4.4 FR-4 Check Runtimes and Enforcement Points**

3.4.4.1 The system MUST support enforcement across build, deploy, runtime, procurement, incident response, and retest contexts per profile requirements.\
3.4.4.2 Checks MUST be policy-bound with defined inputs/outputs and MUST emit telemetry sufficient for lineage and reproducibility.\
3.4.4.3 Exceptions/waivers MUST be governed objects with expiry, authority, justification, compensating controls, and audit trails.\
3.4.4.4 Continuous verification MUST include drift detection (configuration, dependency, model, policy, data drift) and MUST be able to re-trigger obligations and retest clocks.\
3.4.4.5 Check runtimes MUST support deterministic replay where required for audit/supervisory reliance tiers.

**3.4.5 FR-5 Proof Receipts, Evidence Packs, and Status**

3.4.5.1 Proof receipts MUST be signed, time bound, independently verifiable, and scope-specific, declaring the applicable profile hash/version, reliance tier, and handling class.\
3.4.5.2 Receipts MUST support transparency publication with inclusion proofs and a declared equivocation posture aligned to reliance tiers.\
3.4.5.3 Status objects MUST support revocation, supersession, scope narrowing, and validity windows with defined verification procedures.\
3.4.5.4 Evidence packs MUST remain retainable in sovereign zones with enforceable handling controls, access logging, and lawful-basis constraints.\
3.4.5.5 Reliance tiers MUST define required disclosure minima and prohibited inferences.\
3.4.5.6 Receipt verification MUST be operable in offline/degraded modes using cached snapshots and archival bundles where required.

**3.4.6 FR-6 Ontology Fabric (Canonical Operating Map)**

3.4.6.1 The system MUST provide an entity/relation/event model sufficient for scoping obligations and representing hazards, dependencies, and control surfaces.\
3.4.6.2 Every evidence input MUST carry provenance and uncertainty declarations and MUST be subject to bounded influence and anti-poisoning controls.\
3.4.6.3 Participatory ground truthing MUST be supported with safeguards: anti-sybil measures, do-no-harm constraints, protected participation pathways, and auditable moderation and weighting.\
3.4.6.4 The system MUST implement a graph-to-controls mapping loop: events → triggers → OARs → checks → receipts → graph updates → corrected semantics.\
3.4.6.5 Ontology semantic change MUST be governed (versioning, supersession, semantic integrity tests) and MUST NOT introduce silent meaning changes across jurisdictions or languages.\
3.4.6.6 The system SHOULD support integration with enterprise data fabrics and knowledge platforms through adapters, while preserving the canonical ontology governance and semantic controls.

**3.4.7 FR-7 Single Control Plane (End-to-End Operations)**

3.4.7.1 The control plane MUST provide an expert cockpit for obligations, clocks, dockets, receipts, drift, exceptions, and corrections.\
3.4.7.2 Governed low-code/no-code authoring MUST exist for policies, triggers, playbooks, profiles, and runbooks with approval workflows and handling enforcement.\
3.4.7.3 Simulation and what-if MUST be supported pre-deploy, producing evidence outputs (e.g., predicted blast radius, dependency impacts, and expected obligation attach points).\
3.4.7.4 Operator actions MUST be captured as evidence (CPAR), including approvals, deployments, overrides, incident actions, and closures.\
3.4.7.5 Role-based views MUST enforce separation of duties, conflict-of-interest constraints, and handling compliance.\
3.4.7.6 The control plane MUST support interoperability operations at scale: multi-party onboarding, conformance reporting, plugfest execution, and registry-driven discovery.

**3.4.8 FR-8 Correctionability and Learning**

3.4.8.1 No silent edits MUST apply across standards, profiles, ontology semantics, conformance suites, and control-plane operations.\
3.4.8.2 Corrections MUST be implemented through explicit correction objects with status updates, dispute outcomes, and remedy paths, preserving stable historical references.\
3.4.8.3 Lessons learned MUST feed back into profiles, tests, compiler rules, and ontology governance through recorded defect management workflows.\
3.4.8.4 The system MUST support controlled disclosure of corrections and defects according to handling classes, including public-safe summaries where appropriate.

***

#### 3.5 Assurance Requirements (AR)

3.5.1 **AR-1 Attestation-first trust.** High-impact claims MUST be bound to measured state via attestation policies, freshness windows, and appraisal rules.\
3.5.2 **AR-2 Deterministic verification.** Conformance-critical verification MUST be reproducible under declared inputs, versions, and policies, with explicit uncertainty allowances where permitted.\
3.5.3 **AR-3 Evidence lineage by default.** Artefacts MUST be linkable end-to-end: obligation → check → receipt → docket → correction, including trace context and version bindings.\
3.5.4 **AR-4 Conformance testability.** Conformance harnesses MUST include gold vectors, negative tests, adversarial tests, and drift tests adequate to stabilize interoperability.\
3.5.5 **AR-5 Oversight readiness.** Outputs MUST be examiner-operable with verification procedures that do not require bespoke trust in the issuer and do not require unlawful evidence export.

***

#### 3.6 Security and Safety Requirements (SR)

3.6.1 **SR-1 Threat model coverage.** The system MUST address tamper/replay, equivocation, insider risk, data/ontology/model poisoning, capture/undue influence, badge misuse, and override abuse.\
3.6.2 **SR-2 Secure release and supply-chain integrity.** Tooling and reference components MUST publish signed releases with SBOM and provenance, enforce dependency controls, and maintain patch clocks.\
3.6.3 **SR-3 Incident response controls.** The system MUST support receipt invalidation, emergency mode entry/exit, disclosure clocks, and post-incident corrections with recorded outcomes.\
3.6.4 **SR-4 Override safety.** Kill switch and break-glass must be governed: approvals, time bounds, compensating controls, mandatory logging, and post-incident review.\
3.6.5 **SR-5 Data minimization.** The system MUST minimize identity metadata, prevent unnecessary publication of sensitive attributes, and enforce handling-aware logging and disclosure.\
3.6.6 **SR-6 Competition-safe participation.** Standards operations MUST implement competition-safe controls and recorded decision outcomes to avoid anticompetitive coordination risks.

***

#### 3.7 Sovereignty, Privacy, and Handling Requirements (PR)

3.7.1 **PR-1 Sovereign data zones.** The system MUST support compute-to-data, retention controls, access logging, and in-zone processing patterns for evidence packs.\
3.7.2 **PR-2 Handling classes.** Handling classes MUST be enforced across artefacts, workflows, storage, and distribution, including redaction patterns and prohibition rules for restricted content.\
3.7.3 **PR-3 Lawful basis and purpose limitation.** Disclosure MUST be explicit, time bounded, purpose limited, and auditable, with approvals recorded as evidence.\
3.7.4 **PR-4 Do-no-harm safeguards.** Participatory pipelines MUST include protected participation, anti-retaliation controls, and disclosure minimization to prevent harm.\
3.7.5 **PR-5 Cross-border transfer constraints.** Receipts MUST be designed for portability; evidence MUST remain in-zone unless lawful basis and handling clearance permit controlled access.\
3.7.6 **PR-6 Identity minimization.** The system SHOULD support role-markers and minimized identity exposure for sensitive operations where permitted, without weakening auditability.

***

#### 3.8 Operational Resilience Requirements (OR)

3.8.1 **OR-1 Availability and degradation modes.** The system MUST define and support offline/degraded verification behaviors, cache freshness rules, and recovery procedures.\
3.8.2 **OR-2 Clock-based accountability.** Obligations MUST be clocked: verification, remediation, retest, and dispute; missed deadlines MUST generate recorded events and escalation triggers.\
3.8.3 **OR-3 Observability minima.** Telemetry MUST include linkage fields enabling receipt-to-runtime traceability, and security/incident semantics sufficient for multi-party operations.\
3.8.4 **OR-4 Scalability and performance.** The system MUST define performance expectations for trigger evaluation, receipt issuance, status resolution, and docket operations; performance tests MUST be part of conformance where designated.\
3.8.5 **OR-5 Multi-party federation.** Federation MUST avoid single points of failure and MUST preserve interoperability through registries, verification bundles, and conformance-driven compatibility.

***

#### 3.9 Cryptographic and Longevity Requirements (CR)

3.9.1 **CR-1 Crypto agility.** Artefacts MUST support versioned cryptographic suites, algorithm agility, and suite identifiers carried in every verifiable object.\
3.9.2 **CR-2 Transition readiness.** The system MUST support dual-signing and migration windows, with explicit policies for deprecation and re-issuance where required.\
3.9.3 **CR-3 Long-lived verification.** Receipts MUST support archival verification bundles enabling validation years later, including strategies for status resolution under retention limits.\
3.9.4 **CR-4 Key lifecycle management.** Rotation, revocation, emergency key policies, compromise response, and key custody controls MUST integrate into status/correction workflows.

***

#### 3.10 Enterprise Integration and Deployment Requirements (ER)

3.10.1 **ER-1 Enterprise integration.** The system MUST integrate with GRC, ITSM, SOC/NOC, CI/CD, procurement, and risk reporting through stable interfaces and exportable artefacts.\
3.10.2 **ER-2 Multi-cloud/hybrid/OT support.** The system MUST provide connectors and enforcement patterns across cloud, hybrid, and OT/IT environments, including air-gapped and sovereign deployments.\
3.10.3 **ER-3 Neutral portability.** Exit and portability MUST be enforceable: receipts, dockets, profiles, verification bundles, and conformance reports must be exportable; conformance-as-portability must prevent lock-in.\
3.10.4 **ER-4 OSS + enterprise packaging.** The system MUST support long-term support releases, vulnerability response, and secure release discipline suitable for enterprise procurement and operations.\
3.10.5 **ER-5 Data fabric and knowledge integration.** The system SHOULD support adapters to enterprise data fabrics and knowledge platforms while preserving canonical ontology governance and evidence handling rules.

***

#### 3.11 Acceptance Criteria and Definition of Done (DoD)

3.11.1 **Minimum viable compliance.** End-to-end production of: PSA/SPP/TRG/OAR/XPL/CRR/PR/STO/DKT and verification of receipts + status, for at least one base profile plus one sector/hazard overlay, under declared reliance tiers.

3.11.2 **Minimum viable operability.** Demonstrated enforcement across at least three enforcement points (e.g., build, runtime, incident/retest) and a functioning control plane enabling authoring, simulation, deployment governance, monitoring, docketing, and correction workflows.

3.11.3 **Minimum viable sovereignty.** Demonstrated sovereign-zone retention of evidence packs with controlled disclosure, handling enforcement, access logging, and receipt portability to external verifiers.

3.11.4 **Minimum viable conformance.** A conformance harness with gold vectors and negative tests producing signed reports; registry discovery of conformance claims; status-resolvable badge assertions; and repeatable verification by independent parties.

3.11.5 **Minimum viable resilience.** Offline/degraded verification behavior demonstrated through drills; incident clocks and emergency mode entry/exit recorded; post-incident review producing correction objects and supersession where needed.

***

#### 3.12 Part 3 Summary and Traceability Forward

3.12.1 This Part defines a complete requirements baseline for the Nexus Standards system and the NXOSI operational kernel. Requirements are categorized as functional (FR), assurance (AR), security/safety (SR), sovereignty/privacy/handling (PR), operational resilience (OR), cryptographic longevity (CR), and enterprise integration/deployment (ER). A versioned traceability matrix maps each requirement to the architecture layers, core objects, and normative annex specifications.

3.12.2 Subsequent Parts realize these requirements through: (a) the core object model and clocks; (b) the layered architecture and control plane; (c) conformance surfaces and verification procedures; (d) governance, handling, and due process; and (e) reference implementation and deployment patterns. Authoritative schemas, verification procedures, and conformance harness definitions are specified in the annexes and are the basis for independent implementation, procurement, and verification.


---

# 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/iii.-problem-definition.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.