# Annex P #### P.1 No silent meaning changes: governance rules and enforcement P.1.1 **Purpose.** This Annex specifies the mandatory governance and technical enforcement required to ensure the Nexus Ontology Fabric (NOF) can evolve without destabilizing interoperability, proof portability, or reliance. “Meaning” in NXOSI is operational: entity/relation/event semantics drive triggers (TRG), obligation attachment (OAR), execution plans (XPL), checks (CRR), proofs (PR), determinations (DO/GDO), and corrections (STO/COR). Therefore, meaning changes are safety-critical changes. P.1.2 **Normative rule: no silent meaning changes.** Any change that can alter the interpretation of an ontology term, relationship, event class, constraint, or mapping MUST be published as an explicit versioned release with supersession semantics and a status object. Silent edits are prohibited across: * term definitions and constraints; * class hierarchies and subtyping rules; * relation semantics (directionality, cardinality, transitivity); * event semantics (predicate meaning, time/ordering assumptions); * mapping rules from ontology objects to TRG/OAR/XPL selection; * provenance/uncertainty field meanings and defaults; * identifier resolution rules (aliasing/collision handling). P.1.3 **Semantic authority and scope.** The ontology authority is the stewarding function designated in the governance perimeter (assurance-only). Authority is limited to semantic stewardship and conformance surfaces; it MUST NOT extend into regulated execution decisions. P.1.4 **Change classification (mandatory).** All ontology changes MUST be classified as one of: P.1.4.1 **Semantic patch (non-breaking).** Clarifies text, fixes typos, adds non-normative notes, or adds optional fields with safe defaults that do not change reasoning outcomes for any conformant consumer. P.1.4.2 **Semantic minor (compatible extension).** Adds new terms or relations, introduces new event types, or expands enumerations without changing existing meanings; consumers may ignore new items without breaking. P.1.4.3 **Semantic major (breaking).** Changes a definition, constraint, mapping, or interpretation that could change trigger satisfaction, obligation attachment, checks selection, or verification outcomes. P.1.4.4 **Emergency semantic fix.** A time-critical change required to prevent ongoing harm, misuse, or systemic misinterpretation (see P.6). P.1.5 **Governance gate (mandatory).** Semantic minor/major changes MUST pass: * technical review (coherence, mapping effects, regressions); * security/safety review (misuse potential, poisoning risk impact); * handling/privacy review (metadata leakage risks); * interoperability review (cross-profile compatibility, overlays impact); * recorded decision and publication readiness checks. P.1.6 **Enforcement mechanisms (mandatory).** Implementations MUST enforce no silent meaning changes through: P.1.6.1 **Signed releases.** Every ontology release MUST be signed, versioned, and published as a release bundle with checksums and provenance pointers. P.1.6.2 **Status objects.** The release MUST be accompanied by a status object declaring: supersession lineage, validity window (if any), and reliance impact guidance. P.1.6.3 **Deterministic resolution.** Consumers MUST be able to deterministically resolve which ontology version was used for any OAR/XPL/DO/GDO/PR by following immutable identifiers in artefacts. P.1.6.4 **Compatibility assertions.** Each release MUST include explicit compatibility assertions (compatible / conditionally compatible / breaking) and machine-readable migration hints. P.1.6.5 **Mismatch lock.** If the system detects a mismatch between the ontology version referenced in an artefact chain and the version loaded for verification, verification MUST either (i) fail closed for the declared reliance tier, or (ii) require an explicit policy allowing fallback with reduced reliance. P.1.7 **Overlay interaction.** Jurisdiction/sector overlays MAY extend the ontology with additional terms, but overlays MUST NOT redefine the meaning of base terms. Redefinition attempts MUST be detected as conflicts by overlay algebra and rejected or forced into a major change with explicit governance. *** #### P.2 Semantic regression tests and required test vectors P.2.1 **Purpose.** Semantic regression tests ensure that ontology evolution does not silently alter the operational meaning relied upon by triggers, checks, receipts, and verification. P.2.2 **Required regression test categories (mandatory).** P.2.2.1 **Canonical invariants suite.** A fixed set of invariants MUST always hold (e.g., identity resolution determinism; required provenance fields; handling marker semantics; basic relation constraints). P.2.2.2 **Trigger semantics suite.** Gold vectors for TRG predicates MUST be replayable under ontology versions. If outcomes change, the change MUST be declared as major and accompanied by migration notes and reliance guidance. P.2.2.3 **Obligation attachment suite.** OAR scope bindings derived from ontology queries MUST be stable under compatible releases; changes MUST be detected and classified. P.2.2.4 **Graph-to-controls mapping suite.** The mapping from events/entities to controls/tests selection MUST be validated via deterministic test vectors. P.2.2.5 **Interoperability suite.** Cross-profile communication bindings (event schemas and meanings) MUST remain compatible across declared compatible releases. P.2.2.6 **Security semantics suite.** Tests MUST detect changes that weaken poisoning resistance, provenance requirements, or uncertainty model semantics. P.2.2.7 **Handling leakage suite.** Tests MUST confirm that ontology changes do not introduce additional metadata exposure in public-safe outputs. P.2.3 **Required test vectors.** The conformance harness MUST include at minimum: P.2.3.1 A baseline set of entities/relations/events covering: assets, services, suppliers, controls, obligations, hazards, attestations, determinations, corrections. P.2.3.2 Cross-hazard vectors (cyber, outage, disaster/climate, AI incident, supply disruption) where events map to different obligations. P.2.3.3 Cross-jurisdiction overlay vectors validating precedence and conflict detection without semantic redefinition. P.2.3.4 Identity resolution vectors with alias collisions, merges/splits, and canonical ID stability expectations. P.2.3.5 Uncertainty/provenance vectors that verify required fields, transformation manifests, and decay/freshness semantics. P.2.4 **Regression acceptance criteria.** A release MAY be published as compatible only if: P.2.4.1 All canonical invariants pass. P.2.4.2 All “compatibility-marked” vectors preserve outcomes, or any changes are explicitly scoped as non-impacting for defined reliance tiers. P.2.4.3 Any changed outcomes are accompanied by: (i) explicit classification as major, (ii) migration notes, (iii) status semantics, and (iv) updated gold vectors. P.2.5 **Evidence outputs.** Each regression run MUST produce a signed conformance report including: * ontology version IDs and hashes; * test suite versions; * pass/fail and deltas; * declared impact scope and reliance guidance. *** #### P.3 Supersession and migration notes for ontology changes P.3.1 **Supersession as first-class.** Ontology releases MUST participate in NXOSI status semantics. Each release MUST declare: P.3.1.1 **Supersedes**: the prior version(s) it replaces. P.3.1.2 **Superseded-by**: pointers for relying parties. P.3.1.3 **Scope of change**: terms/relations/events affected. P.3.1.4 **Migration policy**: what consumers must do to remain conformant. P.3.1.5 **Equivalence notes**: whether old and new meanings are equivalent for certain reliance tiers or bounded contexts. P.3.2 **Migration notes minimums (mandatory).** Migration notes MUST include: P.3.2.1 A machine-readable mapping table for renamed, split, merged, or deprecated terms (old ID → new ID(s)). P.3.2.2 Constraint changes (cardinality, required fields, allowed values). P.3.2.3 Reasoning changes (how triggers/OAR selection might differ). P.3.2.4 Required re-verification guidance (when old receipts/determinations must be re-evaluated). P.3.2.5 Overlay impact notes (whether overlays require updates and by when). P.3.3 **Deprecation rules.** Deprecation MUST be explicit, time-bound, and testable: P.3.3.1 Deprecated terms MUST remain resolvable for a defined window to support archival verification. P.3.3.2 The window MUST be declared in the status object and migration notes. P.3.3.3 Post-window, terms MAY be retired only if archival bundles remain verifiable (e.g., through snapshots or mapping manifests). P.3.4 **Reliance stability.** If an ontology major change affects the meaning of prior proofs, the system MUST provide one of: P.3.4.1 **Scope narrowing** of affected claims; or P.3.4.2 **Supersession** with explicit equivalence constraints; or P.3.4.3 **Revocation** where reliance can no longer be defended. Silent reinterpretation is prohibited. *** #### P.4 Dispute and remedy procedures for semantic disputes P.4.1 **Who can dispute.** Semantic disputes MAY be raised by implementers, operators, auditors, supervisors (where applicable), and affected stakeholders under defined governance rules. Participatory inputs may trigger dispute consideration but do not compel outcomes. P.4.2 **Dispute objects and dockets.** A semantic dispute MUST create a docket (DKT) and a dispute record that includes: * disputed term(s)/relations/events IDs; * affected artefact classes (TRG/OAR/XPL/PR/DO); * claimed harm or incompatibility; * requested remedy and urgency class; * handling constraints for evidence. P.4.3 **Clocks and interim measures.** Disputes MUST be clocked: P.4.3.1 Intake acknowledgment clock. P.4.3.2 Review and decision clock (tiered by severity). P.4.3.3 Interim measures: where reliance could cause harm, the system MUST support a “dispute hold” status that freezes new reliance at specific tiers until resolved. P.4.4 **Independence and COI.** Adjudication MUST enforce separation-of-duties and COI recusals. Parties who authored the contested semantics SHOULD NOT be the sole adjudicators. P.4.5 **Permitted remedies.** Semantic dispute remedies include: P.4.5.1 Clarification (patch) with explicit publication. P.4.5.2 Compatible extension (minor) to add missing semantics while preserving old meaning. P.4.5.3 Breaking change (major) with migration notes. P.4.5.4 Scope narrowing or revocation of impacted proofs/determinations. P.4.5.5 Quarantine of affected mapping rules pending fix. P.4.6 **Finality and stabilization.** Disputes MUST end with: * a recorded decision; * a published status/correction object; * updated regression tests and vectors; * guidance on reliance restoration and any required re-verification. *** #### P.5 Publication discipline (public-safe summaries; controlled details) P.5.1 **Minimum publication requirements.** Each ontology release MUST publish, at minimum: * version ID and hash; * classification (patch/minor/major/emergency); * supersession lineage and status pointer; * high-level change summary; * compatibility assertion and migration window. P.5.2 **Public-safe vs controlled content.** The system MUST maintain two disclosure tracks: P.5.2.1 **Public-safe release note.** MUST NOT reveal sensitive critical infrastructure details, protected participation data, or restricted operational mappings. P.5.2.2 **Controlled technical note.** MAY include detailed mapping impacts, risk analysis, and sensitive interoperability considerations, access-limited by handling rules and lawful basis. P.5.3 **No metadata leakage.** Publication MUST avoid creating inference channels (e.g., revealing incident location specificity or vendor vulnerabilities through semantic updates). Where such risk exists, the release MUST use controlled publication with a public-safe summary. P.5.4 **Records discipline.** All releases, disputes, and remedies MUST be recorded in the designated registry/records system with immutable identifiers and linkages to conformance reports and regression test results. *** #### P.6 Emergency semantic fixes and post-incident review requirements P.6.1 **Emergency definition.** An emergency semantic fix is permitted only when a semantic defect is causing or is likely to cause: * unsafe triggers or misattached obligations; * systemic verification failure or ecosystem divergence; * exploitable ambiguity leading to abuse or poisoning; * unacceptable harm due to misinterpretation in high-consequence contexts. P.6.2 **Emergency process constraints.** Emergency fixes MUST: P.6.2.1 Be time-bound and scoped to the minimum necessary change. P.6.2.2 Require explicit approval gates with multi-party oversight. P.6.2.3 Produce immediate status objects (including “emergency” marker), migration notes, and reliance guidance. P.6.2.4 Trigger an automatic regression run with emergency vectors and publish results (public-safe summary at minimum). P.6.3 **Emergency holds and freezes.** If an emergency fix implies that prior meaning is unsafe, the system MUST support: * immediate scope narrowing for affected reliance tiers; and/or * targeted revocation for impacted proofs; and/or * temporary “freeze” of specific triggers/mappings until verification. P.6.4 **Post-incident review (mandatory).** Every emergency semantic fix MUST be followed by a post-incident review that includes: * root cause analysis (why semantic governance failed); * impact analysis (what artefacts and relying parties were affected); * corrective actions (tests added, policies tightened, tooling improved); * publication of a public-safe postmortem summary and controlled detailed report as appropriate. P.6.5 **Learning loop.** The outcome of the post-incident review MUST feed back into: * semantic regression test suites (new gold/negative/adversarial vectors); * overlay conflict detection improvements; * governance process improvements and acceptance criteria tightening. --- # 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-p.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.