# Annex N #### N.1 Canonical entity model (assets, services, suppliers, controls, obligations, hazards) N.1.1 **Purpose.** The Nexus Ontology Fabric (NOF) provides the canonical, machine-operable map of “what exists” and “what matters” for NXOSI across all hazards and sectors. It is the semantic control surface for triggers (TRG), obligation scope (OAR), execution planning (XPL), proof binding (PR), docketing (DKT), and correctionability (STO/COR). The NOF is normative for *interoperability semantics*—implementations MAY vary in storage engines and query layers, but MUST preserve canonical meaning, versioning, and evidence linkage. N.1.2 **Entity categories (normative).** The NOF MUST support, at minimum, the following canonical entity categories, each with stable identifiers and semantic versioning hooks (N.7): N.1.2.1 **Asset.** A discrete physical or logical object that can be owned, operated, depended upon, attacked, degraded, or verified (e.g., server, substation, router, model endpoint, dataset vault, facility). N.1.2.2 **Service.** A delivered capability or function (e.g., payments processing, emergency dispatch, water distribution, authentication service). Services MUST be representable independently of underlying assets to model cascading failures. N.1.2.3 **System.** A composed set of assets/services governed as a unit (e.g., a platform, an OT network segment, a sovereign evidence zone, a CI/CD system, a procurement pipeline). Systems MUST support boundary declarations (zones, organizations, trust boundaries). N.1.2.4 **Organization.** A legal or operational entity (operator, vendor, regulator, auditor, community org). Organizations MUST be representable with minimal disclosure modes (e.g., opaque IDs in public contexts) and jurisdictional attributes for overlays. N.1.2.5 **Supplier / Third Party.** A specialized organization role used to model supply-chain, concentration, and dependency risks. Supplier is not a separate legal entity class; it is a role binding with additional relations and constraints. N.1.2.6 **Control.** A normative, atomic obligation unit (mapped from standards and profiles) with testable semantics and enforcement points. Controls MUST reference their canonical identifiers from Nexus Standards artifacts and MUST be linkable to CRR/PR outcomes. N.1.2.7 **Obligation.** A time-bound duty attached to a scope under an OAR. Obligations MUST be representable as entities to allow lifecycle management, clocks, disputes, and correction. N.1.2.8 **Profile / Overlay.** A deployable semantic package boundary (SPP + overlays) that shapes what controls apply and how they are parameterized. Profiles MUST be entities to support dependency reasoning and portability. N.1.2.9 **Hazard.** A canonical hazard class (cyber, outage, disaster/climate, supply shock, AI incident) and hazard instance (a specific storm, exploit campaign, outage event). Hazards MUST be representable separately from incidents to support early warning and anticipatory obligations. N.1.2.10 **Evidence Store / Zone.** A sovereign data zone, enclave, escrow, or evidence repository (AEP retention target). Zones MUST be first-class entities to enforce “receipt travels, evidence stays” constraints. N.1.2.11 **Identity Objects.** Canonical identity references (role markers, service identities, device identities) used for authorization and issuance (e.g., receipt issuer, adjudicator). Identity objects MUST support privacy-preserving representations. N.1.3 **Core required attributes (normative).** Every entity MUST contain: N.1.3.1 `entity_id` (canonical ID, see N.4). N.1.3.2 `entity_type` (from controlled vocabulary). N.1.3.3 `name` (or redacted alias for public-safe views). N.1.3.4 `jurisdiction_tags` (for overlay evaluation, may be empty). N.1.3.5 `handling_class` marker for the entity record itself (not the evidence about it). N.1.3.6 `provenance_pointer` (N.5) for the assertions that created/modified this entity state. N.1.3.7 `semantic_version` pointer (N.7) for the schema/term-set in force. N.1.3.8 `status` and validity window fields (active/deprecated/merged/superseded) consistent with status semantics. N.1.4 **Entity profiles for high-consequence contexts (mandatory).** The following entities MUST support additional attributes where applicable: N.1.4.1 **Asset criticality.** Criticality tier, safety impact tier, and service dependency contribution. N.1.4.2 **Service continuity.** RTO/RPO targets (if applicable), resilience posture references, and continuity test references. N.1.4.3 **Supplier concentration.** Concentration metrics (bounded/minimized), critical supplier designation flags, and cross-supplier dependency relations. N.1.4.4 **AI endpoints and models.** Model version references, inference endpoint identity/attestation capability flags, tool allowlist association pointers, and drift monitoring configuration pointers (without embedding sensitive training data metadata). N.1.4.5 **Zones.** Residency and handling constraints, access logging policy pointers, escrow patterns, and disaster recovery posture. N.1.5 **Normative “minimum semantic set.”** Implementations MUST provide a minimal semantic set enabling: N.1.5.1 Trigger predicates to refer to entities unambiguously. N.1.5.2 OAR scope binding to resolve a stable entity set at a point in time. N.1.5.3 Proof receipts to bind claims to the correct subjects and contexts. N.1.5.4 Dockets to remain portable by referencing canonical IDs and term sets rather than system-specific names. *** #### N.2 Relation model (dependencies, exposure, custody, influence, supply links) N.2.1 **Purpose.** Relations encode “how things affect each other.” Relations are essential for cascading risk, third-party oversight, and jurisdictional overlays. Relations MUST be typed, directional where appropriate, time-bound where necessary, and provenance-backed. N.2.2 **Relation primitives (normative).** The NOF MUST support: N.2.2.1 **Dependency relations.** `depends_on`, `provides_to`, `requires`, with optional strength/criticality annotations. Dependencies MUST support multi-hop reasoning and “blast radius” evaluation. N.2.2.2 **Exposure relations.** `exposed_to` connecting assets/services/systems to hazards, threat actors (as abstract classes), or environmental stressors, with uncertainty bounds (N.6). N.2.2.3 **Custody and control relations.** `owned_by`, `operated_by`, `administered_by`, `custodied_by`, `processed_by` (for data systems), including time bounds and lawful basis pointers where relevant. N.2.2.4 **Influence relations.** `influenced_by`, `controls`, `governs`, `supplies_policy_to` to model capture risk, governance separation, and decision influence chains. Influence MUST be bounded in downstream trust scoring (N.5/N.6) to resist capture. N.2.2.5 **Supply links.** `supplies`, `subcontracts_to`, `distributes`, `maintains`, `hosts`, `licenses`, `depends_on_component`, supporting supply-chain proofs and SBOM/provenance associations. N.2.2.6 **Assurance relations.** `verified_by`, `attested_by`, `audited_by`, linking entities to issuers/verifiers with evidence pointers (without implying endorsement). N.2.2.7 **Scope membership relations.** `member_of_scope` linking entities to an OAR scope or profile scope, enabling portable replay of checks. N.2.3 **Required relation attributes (normative).** Every relation assertion MUST include: N.2.3.1 `relation_id` (canonical, stable). N.2.3.2 `relation_type` (controlled vocabulary). N.2.3.3 `subject_entity_id` and `object_entity_id`. N.2.3.4 Directionality marker (if relation is directional). N.2.3.5 Validity window (start/end or start + open-ended). N.2.3.6 `handling_class` marker for the assertion. N.2.3.7 `provenance_pointer` (N.5) and uncertainty/confidence fields where applicable (N.6). N.2.4 **Cascading reasoning constraints.** Implementations MUST support: N.2.4.1 Graph queries to compute dependency chains for defined depth limits. N.2.4.2 Stable snapshots to ensure OAR binding and XPL compilation are reproducible. N.2.4.3 Handling-aware traversal: public-safe reasoning MUST not traverse restricted edges unless authorized and in-zone. N.2.5 **Conflict and supersession for relations.** When relations conflict: N.2.5.1 Conflicts MUST be preserved as competing assertions, not overwritten silently. N.2.5.2 Adjudication outputs MUST produce correction objects and/or status changes that supersede or scope-narrow specific assertions with explicit traceability. *** #### N.3 Event model (incidents, hazards, attestations, determinations, corrections) N.3.1 **Purpose.** Events are the runtime substrate for triggers, obligations, monitoring clocks, and corrections. Events MUST be typed, time-bound, linkable, and provenance-backed. The event model enables the full graph-to-controls loop: events → triggers → OARs → checks → receipts → graph updates. N.3.2 **Event categories (normative).** The NOF MUST represent, at minimum: N.3.2.1 **Hazard events.** Storm formation, threat campaign indicators, supply disruption signals, geopolitical or systemic stressors, with uncertainty declarations and source weighting. N.3.2.2 **Incident events.** Cyber intrusion, outage, safety incident, integrity breach, AI misuse event, service degradation, with severity, scope, and response phase attributes. N.3.2.3 **Change events.** Configuration changes, deployment changes, policy changes, profile changes, ontology semantic changes, waiver grants/expiry. N.3.2.4 **Attestation events.** Appraisal results, endorsement updates, attestation failures, re-keying, re-baselining events, with freshness and validity windows. N.3.2.5 **Check outcome events.** CRR completion events, drift detection events, enforcement-point gate outcomes, exception/waiver issuance events. N.3.2.6 **Proof events.** PR issuance, transparency inclusion, status changes (STO updates), revocation/supersession/scope narrowing events. N.3.2.7 **Determination events.** DO/GDO creation, docket updates, remediation milestones, retest completions, closure events. N.3.2.8 **Dispute and correction events.** Challenge initiation, dispute holds, adjudication outcomes, correction publication, and supersession enforcement. N.3.3 **Required event attributes (normative).** Every event MUST include: N.3.3.1 `event_id` (canonical). N.3.3.2 `event_type` (controlled vocabulary). N.3.3.3 `event_time` and `recorded_time` (distinct; recorded\_time may lag). N.3.3.4 `subjects` (entity IDs affected). N.3.3.5 `handling_class` and disclosure tier. N.3.3.6 `provenance_pointer` and transformation manifest pointers where derived. N.3.3.7 `uncertainty` fields where applicable (N.6). N.3.3.8 `trace_context` linking to TRG/OAR/XPL/CRR/PR/DKT/STO/CPAR as applicable. N.3.4 **Event lifecycle and correctionability.** Events MUST be correctionable: N.3.4.1 Events MUST NOT be silently edited; modifications MUST be represented as superseding events and/or correction objects with explicit linkages. N.3.4.2 Event assertions under dispute MUST support “hold” semantics that constrain reliance until resolved. N.3.5 **Event-to-trigger binding rules.** Trigger predicates MUST reference event types and ontology bindings, and MUST declare: N.3.5.1 Which event attributes are required for evaluation. N.3.5.2 Whether probabilistic attributes are permitted and what uncertainty thresholds apply. N.3.5.3 How missing or delayed events affect clock binding and monitoring behavior. *** #### N.4 Identity resolution rules (canonical IDs, aliasing, collisions) N.4.1 **Purpose.** Identity resolution ensures “the same thing is the same” across vendors, deployments, and sovereign zones without forcing centralization. Canonical IDs support portability of receipts and dockets while preserving sovereignty and minimal disclosure. N.4.2 **Canonical ID requirements (normative).** The system MUST support canonical IDs that are: N.4.2.1 Globally unique within the defined namespace scheme. N.4.2.2 Stable across time unless explicitly superseded/merged. N.4.2.3 Resolvable to entity records under appropriate handling and access constraints. N.4.2.4 Compatible with offline verification (IDs can be validated structurally without network access). N.4.3 **Aliasing model.** The NOF MUST support alias sets: N.4.3.1 Multiple external identifiers (CMDB IDs, vendor IDs, registry IDs, procurement IDs) MAY map to one canonical ID. N.4.3.2 Alias mappings MUST include provenance, confidence, and validity windows. N.4.3.3 Public-safe views MUST be able to present opaque aliases where canonical disclosure is restricted. N.4.4 **Collision handling.** When two canonical IDs are later determined to represent the same entity: N.4.4.1 A merge MUST be represented as a governed correction with explicit mapping from deprecated IDs to the surviving canonical ID. N.4.4.2 All dependent artefacts (OAR/XPL/PR/DKT) MUST remain verifiable via a stable mapping table, including offline bundles. N.4.5 **Split handling.** When one canonical ID is later determined to represent multiple real entities: N.4.5.1 A split MUST be represented as a governed correction with explicit partition rules and effective times. N.4.5.2 Reliance semantics MUST be updated via status/scope narrowing where prior proofs become ambiguous. N.4.6 **Privacy-preserving resolution.** Identity resolution MUST support sovereign and handling constraints: N.4.6.1 Implementations MUST provide a means to verify equivalence or mapping without exposing restricted underlying attributes. N.4.6.2 Cross-border identity mapping SHOULD default to receipt-level references and controlled mapping disclosure. *** #### N.5 Provenance requirements and transformation manifests N.5.1 **Purpose.** Provenance is the basis for trust scoring, auditability, dispute resolution, and correctionability. The NOF MUST record “where did this assertion come from,” “what transformed it,” and “who authorized it,” with handling-aware constraints. N.5.2 **Provenance pointer (mandatory).** Every entity/relation/event assertion MUST include a provenance pointer that resolves (subject to handling rules) to: N.5.2.1 Source class (EO/OSINT/IoT/telemetry/human report/enterprise record). N.5.2.2 Source identity reference (redacted or opaque where needed). N.5.2.3 Acquisition time and method. N.5.2.4 Integrity metadata (hashes, signatures where applicable). N.5.2.5 Handling class of the source material. N.5.3 **Transformation manifests (mandatory for derived assertions).** For derived products (fusion, deduplication, model outputs), a transformation manifest MUST declare: N.5.3.1 Input set pointers (sources and prior assertions). N.5.3.2 Transformation method identifier (algorithm or process reference) and version. N.5.3.3 Parameterization and thresholds (including uncertainty thresholds). N.5.3.4 Operator actions (CPAR linkage) where human judgment altered outcomes. N.5.3.5 Output assertions produced and their identifiers. N.5.4 **Lineage chain integrity.** Implementations MUST ensure: N.5.4.1 Lineage chains are tamper-evident (e.g., signed manifests or hash-linked records). N.5.4.2 Lineage remains valid under corrections via explicit supersession pointers. N.5.5 **Minimal disclosure in provenance.** Provenance MUST be handling-aware: N.5.5.1 Public provenance may be summarized, but MUST remain sufficient to evaluate allowed reliance tier claims (e.g., “multi-source corroborated” with timestamp and method class). N.5.5.2 Controlled/Restricted provenance may contain detailed source identifiers, subject to lawful basis and access logging. *** #### N.6 Uncertainty model (confidence declarations; bounds) N.6.1 **Purpose.** NOF must represent uncertainty explicitly to avoid false determinism, prevent over-claiming, and enable deterministic behavior where required. Uncertainty is not a weakness; it is the mechanism that makes trigger evaluation and reliance stable under real-world ambiguity. N.6.2 **Mandatory uncertainty fields (where applicable).** Assertions derived from uncertain sources MUST include: N.6.2.1 Confidence score or interval (bounded, interpretable scale). N.6.2.2 Uncertainty type (measurement error, model uncertainty, source conflict, temporal staleness). N.6.2.3 Freshness/decay policy reference (how confidence degrades over time). N.6.2.4 Corroboration count or class summary (without leaking restricted source identities). N.6.3 **Determinism under uncertainty.** Where NXOSI requires deterministic outcomes (e.g., OAR issuance), triggers MUST declare: N.6.3.1 Deterministic decision rules over uncertainty (e.g., threshold crossing with tie-breaking rules). N.6.3.2 Fallback behavior when uncertainty is too high (defer, escalate to human review, issue provisional OAR with constrained reliance tier). N.6.4 **Competing assertions.** The NOF MUST support multiple competing assertions about the same fact: N.6.4.1 Competing assertions MUST be representable simultaneously with provenance and confidence. N.6.4.2 Adjudication MUST produce correction objects and status changes, not silent overwrites. N.6.5 **Uncertainty in participation and anti-poisoning.** Participatory inputs MUST be treated as evidence candidates: N.6.5.1 Default uncertainty for unverified public inputs MUST be declared high, with bounded influence in trust scoring. N.6.5.2 Escalation pathways must allow verified promotion of assertions with explicit manifests. *** #### N.7 Semantic versioning and governance hooks N.7.1 **Purpose.** Semantic stability is the precondition for portable proofs. If meanings change silently, receipts stop being reliable. Semantic versioning ensures that ontology terms, schemas, and inference rules evolve without breaking reliance. N.7.2 **Semantic version identifiers (mandatory).** The NOF MUST support version identifiers for: N.7.2.1 Ontology term sets (entity/relation/event vocabularies). N.7.2.2 Schema structures (fields, constraints). N.7.2.3 Mapping and inference rules used in graph-to-controls binding. N.7.3 **Breaking vs non-breaking change rules.** Changes MUST be classified: N.7.3.1 **Non-breaking**: additive fields, new optional terms, new mappings that do not alter interpretation of existing assertions. N.7.3.2 **Breaking**: term meaning changes, required field changes, relation/event semantic shifts, inference rule changes that alter prior determinations. N.7.4 **No silent semantic change rule.** Any semantic change that could affect reliance MUST: N.7.4.1 Produce explicit status/supersession objects for the ontology term set. N.7.4.2 Include migration and equivalence notes (what changed, what remains equivalent, what is no longer comparable). N.7.4.3 Trigger regression tests (semantic regression vectors) before adoption. N.7.5 **Governance hooks (mandatory).** Ontology changes MUST integrate with governance controls: N.7.5.1 Proposal intake with scope and operability tests. N.7.5.2 Review and approval with conflict checks and handling clearance. N.7.5.3 Publication discipline: signed releases, checksums, and a public-safe change summary. N.7.5.4 Dispute windows: ability to challenge semantic changes with interim holds where reliance would be destabilized. N.7.6 **Compatibility guarantees for relying parties.** Implementations MUST provide: N.7.6.1 A method to determine which ontology version a receipt/docket was evaluated against. N.7.6.2 A method to obtain offline snapshots of the relevant term sets for archival verification. N.7.6.3 A method to validate that a relying party’s verifier understands the term set version (or else constrain reliance). N.7.7 **Interlock with overlays.** Jurisdiction overlays MUST be able to: N.7.7.1 Reference ontology versions explicitly. N.7.7.2 Constrain term use (e.g., national definitions of critical entities) without forking canonical meanings, using overlay bindings and scope constraints rather than redefining base terms. --- # 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/annexes/annex-n.md?ask= ``` 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.