# Annex Q #### Q.1 Event→trigger predicate mapping rules Q.1.1 **Purpose.** This Annex specifies the normative mapping between (i) ontology events and assertions in the Nexus Ontology Fabric (NOF), and (ii) trigger evaluation (TRG) and obligation attachment (OAR). It defines what “event satisfaction” means, how uncertainty is handled, and how triggers remain deterministic and testable while operating in all-hazards, mixed-connectivity environments. Q.1.2 **Inputs.** A trigger evaluation MUST operate over a bounded, versioned context set: Q.1.2.1 **Ontology snapshot identifier.** Each evaluation MUST reference a specific ontology schema version and a specific graph snapshot (or snapshot hash) to prevent ambiguous re-evaluation. Q.1.2.2 **Event objects.** Events MUST be represented as canonical NOF Event objects with: event ID, event type, time bounds, location scope (if relevant), involved entities, provenance pointers, uncertainty/confidence, and handling markers. Q.1.2.3 **Evidence candidates.** Where triggers require evidence candidates (e.g., a telemetry anomaly series), the candidates MUST be referenced by pointer with provenance/uncertainty fields and handling markers. Q.1.2.4 **Overlay context.** Applicable overlays (sector/hazard/jurisdiction/operator) MUST be enumerated (by immutable IDs) as part of the evaluation context because overlays can change predicate thresholds, clocks, and required confirmation steps. Q.1.3 **Trigger predicate form (TRG).** A trigger predicate MUST be expressed as a declarative predicate over NOF objects and MUST include: Q.1.3.1 **Predicate signature.** `(event_set, entity_scope, overlay_set, time_window, uncertainty_policy) -> {true|false|defer}`. Q.1.3.2 **Determinism requirement.** Given identical inputs and the same uncertainty policy, the predicate MUST yield identical outputs. Q.1.3.3 **Handling-awareness.** A trigger MUST declare the minimum handling class required to evaluate it. If required inputs are unavailable due to handling restrictions, the predicate MUST return `defer` and MUST NOT “guess” across disclosure boundaries. Q.1.4 **Uncertainty policies (mandatory).** Every TRG MUST declare an uncertainty policy specifying: Q.1.4.1 **Minimum confidence thresholds** for event assertions and entity linkages used in predicate evaluation. Q.1.4.2 **Aggregation rules** for multi-source evidence (e.g., “two independent sources above threshold,” or “one attested source”). Q.1.4.3 **Defer rules** when uncertainty exceeds bounds or when inputs are incomplete. Q.1.4.4 **Escalation rules**: which human-in-the-loop or adjudication steps are required when predicates are close to threshold or contested. Q.1.5 **Temporal semantics (mandatory).** Trigger evaluation MUST define: Q.1.5.1 **Event time window.** How event start/end and observation time are treated. Q.1.5.2 **Freshness windows.** Maximum age of evidence candidates for the trigger to be valid. Q.1.5.3 **Ordering assumptions.** If event ordering matters, the predicate MUST specify ordering rules and acceptable clock skew bounds. Q.1.6 **Cross-event logic.** Triggers MAY reference patterns across events (e.g., cyber intrusion + outage + supplier disruption). When doing so, the predicate MUST: Q.1.6.1 Specify whether logical conjunction requires simultaneity or sequential ordering. Q.1.6.2 Provide bounded lookback windows and correlation rules. Q.1.6.3 Provide anti-poisoning constraints (e.g., exclude quarantined sources; cap influence). Q.1.7 **Output binding requirements.** When a TRG evaluates to `true`, NXOSI MUST: Q.1.7.1 Bind the evaluation to an immutable evaluation record (linkable to the eventual OAR). Q.1.7.2 Record predicate inputs by pointer (not necessarily by copying), including snapshot IDs and overlay IDs. Q.1.7.3 Emit a trace context identifier that will propagate into OAR, XPL, CRR, PR, and DKT. *** #### Q.2 Entity scope→OAR binding rules and correctness tests Q.2.1 **Purpose.** OAR binding converts ontology “meaning” into a machine-attachable obligation with scope and clocks. This section defines how the entity set and contextual constraints are computed and how correctness is demonstrated. Q.2.2 **Scope binding components (mandatory).** OAR scope MUST include, at minimum: Q.2.2.1 **Subject set.** One or more entity identifiers (canonical IDs) describing the obligated subjects (systems, services, operators, vendors, programs, etc.). Q.2.2.2 **Context envelope.** Jurisdiction, geography (if relevant), hazard class, sector class, time window, and handling defaults. Q.2.2.3 **Overlay binding.** The exact profile stack and overlays that determine obligations. Q.2.2.4 **Dependency closure (when applicable).** If the profile requires obligations to extend to dependencies (e.g., critical suppliers), the closure rule MUST be declared (depth, relation types included, exclusion rules). Q.2.2.5 **Uncertainty bounds.** Confidence thresholds for entity resolution and relation traversal used to construct the subject set. Q.2.3 **Entity resolution determinism.** Given the same ontology snapshot and resolution policy, the computed subject set MUST be deterministic and reproducible. Q.2.4 **Correctness tests (mandatory).** Implementations MUST provide correctness tests covering: Q.2.4.1 **Identity resolution correctness.** Same input evidence yields same canonical ID mapping; known collisions and merges are handled per policy. Q.2.4.2 **Traversal correctness.** Dependency closure produces expected entity sets under known graphs; depth limits and relation filters behave as declared. Q.2.4.3 **Handling correctness.** Entity inclusion MUST NOT depend on unavailable restricted inputs unless the TRG/OAR explicitly requires controlled evaluation; otherwise it must `defer`. Q.2.4.4 **Overlay correctness.** Overlay precedence and carve-outs must be reflected in the scope (e.g., obligations apply only to subsets under a jurisdiction carve-out). Q.2.4.5 **Stability under compatible changes.** Under compatible ontology releases, the subject set for a given snapshot and policy must remain stable; any change must be flagged as a breaking semantic event requiring explicit governance (see Annex P). Q.2.5 **OAR issuance rules.** When binding completes, the OAR MUST: Q.2.5.1 Reference the trigger evaluation record ID. Q.2.5.2 Include the ontology snapshot ID used for scope computation. Q.2.5.3 Include the subject set IDs and any dependency closure declaration. Q.2.5.4 Include clock bindings, reliance tier, and handling defaults. Q.2.5.5 Include a status pointer for future supersession/revocation/scope narrowing. *** #### Q.3 Check selection and planning rules (XPL generation constraints) Q.3.1 **Purpose.** This section specifies how OAR + profile stack + ontology context produces a deterministic execution plan (XPL) and how the plan selects checks, enforcement points, and dependencies without execution creep. Q.3.2 **Deterministic plan generation.** XPL generation MUST be deterministic given: * SPP stack and versions; * overlays and parameter bindings; * OAR scope + clocks + reliance tier; * ontology snapshot context and declared uncertainty policy. Q.3.3 **Check selection model.** The compiler/runtime MUST select checks as follows: Q.3.3.1 **Control set derivation.** Controls MUST be derived from the profile stack after overlay resolution, including any conditional controls activated by hazard class, entity type, or risk class. Q.3.3.2 **Applicability predicates.** Each control MUST have an applicability predicate referencing ontology entity attributes/relations/events (e.g., “applies to entities of type CriticalSupplier with relation ‘supports’ to CriticalService”). Q.3.3.3 **Enforcement points.** Each control MUST declare applicable enforcement points (build/deploy/runtime/procurement/incident/retest). The XPL MUST include at least one valid enforcement point per mandatory control, or it MUST mark the control as non-enforceable and fail closed for the declared reliance tier unless a governed exception is present. Q.3.3.4 **Dependency declarations.** Checks MUST declare their required inputs (telemetry, attestations, policy artefacts) by type and handling class. The plan MUST fail closed or `defer` if required dependencies are unavailable, per the reliance tier rules. Q.3.3.5 **Attestation requirements.** If the profile requires attestation for certain controls or reliance tiers, the plan MUST embed attestation bindings and appraisal policy references as plan constraints. Q.3.4 **No execution creep constraint.** XPL MUST produce: * checks to evaluate compliance/operability and to generate evidence artefacts; and * routing outputs (docket updates, determinations) to external systems.\ XPL MUST NOT contain actions that perform regulated execution (e.g., moving funds, underwriting, market actions, claims settlement). Q.3.5 **Plan completeness and safety.** XPL MUST include: Q.3.5.1 **Plan graph.** A DAG of checks with declared ordering constraints. Q.3.5.2 **Clock alignment.** Each check mapped to verification/remediation/retest clocks, including escalation triggers. Q.3.5.3 **Failure semantics.** For each control: fail/deny/defer behavior, degraded mode behavior, and dispute hold behavior (if contested). Q.3.5.4 **Trace context.** A propagated trace ID linking to OAR and onward to CRR/PR/DKT. Q.3.6 **Correctness tests (mandatory).** XPL generation MUST be validated by: Q.3.6.1 Deterministic build tests (same inputs produce identical XPL hash). Q.3.6.2 Overlay resolution tests (composition/precedence produces expected control sets). Q.3.6.3 Applicability tests (controls apply to the correct entity subsets under known graphs). Q.3.6.4 Attestation gating tests (required tiers enforce as declared). Q.3.6.5 Negative tests (missing dependencies; restricted inputs; conflict overlays) produce correct fail/defer behavior. *** #### Q.4 Graph updates from receipts and corrections Q.4.1 **Purpose.** NXOSI outputs are not only reports; they are graph-updating evidence. This section specifies how PR/CRR/DO/DKT/STO/CPAR update the ontology while preserving provenance, handling constraints, and correctionability. Q.4.2 **Update principles (mandatory).** Q.4.2.1 **Provenance-by-default.** Every graph update MUST include provenance pointers back to the generating artefacts and to the ontology snapshot used in evaluation. Q.4.2.2 **Non-repudiation.** Updates derived from PR/CRR/CPAR MUST reference signed artefacts and issuer authorization. Q.4.2.3 **Handling-preserving updates.** Updates MUST not “downgrade” handling class. If a receipt is public-safe but the underlying evidence is controlled, the update MAY include only public-safe assertions and MUST point to controlled evidence via an AEP index pointer. Q.4.2.4 **No silent overwrites.** Updates MUST be additive with explicit supersession semantics; previous assertions must remain addressable and must be superseded or narrowed via status/correction objects. Q.4.3 **Receipt-derived updates.** When a PR is issued, the system MAY update: Q.4.3.1 Entity compliance state attributes (bounded to the PR scope and reliance tier). Q.4.3.2 Obligation satisfaction edges (OAR → satisfied/unsatisfied) with time binding. Q.4.3.3 Control evaluation edges (control → pass/fail) by pointer to CRR. Q.4.3.4 Risk posture indicators (only if allowed by profile and reliance tier; must declare uncertainty). Q.4.4 **Correction-derived updates.** When STO/COR is published: Q.4.4.1 Graph assertions dependent on revoked artefacts MUST be marked as invalidated for reliance tiers impacted. Q.4.4.2 Superseded terms/relations/events MUST be mapped to new IDs where applicable, with migration pointers. Q.4.4.3 Scope-narrowing MUST update allowable inferences and dependent reasoning paths. Q.4.5 **Correctness tests (mandatory).** Implementations MUST test: Q.4.5.1 Provenance integrity: every update has required pointers. Q.4.5.2 Handling integrity: no leakage or downgrading. Q.4.5.3 Supersession integrity: old assertions remain addressable, and resolution yields correct current state under status rules. Q.4.5.4 Replay resistance: updates cannot be injected out-of-context using replayed receipts due to scope/time binding constraints. *** #### Q.5 Drift feedback loops (graph signals → triggers → obligations) Q.5.1 **Purpose.** Drift is when reality changes faster than standards, controls, or assumptions. NXOSI must detect drift via graph signals and respond by attaching obligations, tightening clocks, or requiring retests—without destabilizing the system via over-triggering. Q.5.2 **Drift signal sources.** Drift signals MAY arise from: Q.5.2.1 Observability anomalies (OBS) linked to entities or controls. Q.5.2.2 Attestation freshness failures or appraisal downgrades. Q.5.2.3 Status changes (revocations, supersessions, scope narrowing). Q.5.2.4 Ontology semantic changes that invalidate prior mappings. Q.5.2.5 Participatory reports confirmed above trust thresholds. Q.5.3 **Drift-to-trigger mapping.** Drift triggers MUST be defined as TRG predicates over drift signals and MUST include: Q.5.3.1 Hysteresis rules (to prevent flapping). Q.5.3.2 Minimum confirmation rules (multi-source or attested confirmation for high-impact obligations). Q.5.3.3 Rate limits and escalation tiers (notify → observe → obligate → emergency mode). Q.5.4 **Obligation responses to drift.** When drift triggers, the system MAY: Q.5.4.1 Issue a new OAR requiring retest or remediation within a defined clock. Q.5.4.2 Narrow reliance scope for existing proofs pending retest (scope narrowing STO). Q.5.4.3 Open a docket for investigation and evidence gathering (non-execution routing). Q.5.4.4 Require elevated attestation tiers for subsequent checks. Q.5.5 **Correctness and safety constraints.** Drift loops MUST be: Q.5.5.1 Deterministic given the same drift inputs and policies. Q.5.5.2 Handling-aware (no reliance on restricted inputs unless authorized). Q.5.5.3 Resistant to manipulation (bounded influence; quarantined sources excluded). Q.5.6 **Drift tests (mandatory).** The conformance suite MUST include: Q.5.6.1 Drift detection vectors (known anomaly patterns). Q.5.6.2 Flapping prevention tests (hysteresis behavior). Q.5.6.3 Adversarial drift injection tests (poisoning, replay, coerced reports). Q.5.6.4 Retest clock compliance tests (drift → OAR → XPL → CRR → PR chain). *** #### Q.6 Mapping conformance suite and regression lock Q.6.1 **Purpose.** This section defines the minimum conformance tests that prove a given implementation preserves graph-to-controls semantics and does not diverge across vendors or sovereign deployments. Q.6.2 **Mandatory suites (baseline).** Q.6.2.1 **Event→TRG suite.** Validates trigger predicate correctness across hazard patterns, uncertainty policies, and handling constraints. Q.6.2.2 **Scope→OAR suite.** Validates deterministic entity selection, traversal closure, overlay effects, and handling-aware defer behavior. Q.6.2.3 **OAR→XPL suite.** Validates deterministic plan generation, correct control applicability, enforcement-point mapping, and attestation gating. Q.6.2.4 **Outputs→Graph update suite.** Validates provenance, handling integrity, and supersession-safe updates from PR/STO/CPAR. Q.6.2.5 **Drift loop suite.** Validates drift detection, hysteresis, rate limits, and obligation attachment outcomes. Q.6.3 **Regression lock requirement.** A “regression lock” MUST be maintained: Q.6.3.1 Gold vectors and expected outputs MUST be published and versioned. Q.6.3.2 Any change in expected outputs MUST be treated as a breaking semantic event unless explicitly classified and approved as compatible with documented reliance implications. Q.6.3.3 Plugfests MUST use the regression lock vectors as the shared interop contract across implementations. Q.6.4 **Conformance evidence outputs.** Each conformance run MUST output: * machine-readable results with hashes of inputs and outputs; * signed conformance report; * delta summary against the prior lock baseline; * declared compatibility and migration guidance if deltas exist. Q.6.5 **Failure criteria.** An implementation MUST be considered non-conformant if it: * produces non-deterministic mappings given identical inputs; * violates handling constraints or causes metadata leakage; * fails to maintain provenance linkage; * allows silent overwrites rather than supersession/status semantics; * diverges from regression lock without an approved, published semantic change process. --- # 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-q.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.