# Annex A #### A.1 Glossary governance (authority, change control, publication discipline) A.1.1 **Glossary as a normative control surface.** The glossary is a controlled, versioned authority for meaning. Defined terms bind the semantics of artefacts, controls, tests, receipts, status objects, overlays, and verification procedures. Any ambiguity in meaning is treated as an operability defect. A.1.2 **Authority and stewardship.**\ A.1.2.1 The **Glossary Authority** is the designated steward role (or steward committee) responsible for approving additions, modifications, deprecations, and supersessions of terms.\ A.1.2.2 The Glossary Authority MUST be independent from execution-stack operators and commercial implementers for purposes of neutral meaning control and conflict avoidance.\ A.1.2.3 The Glossary Authority MAY delegate drafting to working groups but MUST retain approval authority and publication discipline. A.1.3 **Change control and versioning.**\ A.1.3.1 Every glossary release MUST have: a unique version identifier, release date/time, signing metadata, and a change log.\ A.1.3.2 Changes MUST be classified as **non-breaking** (clarifications that do not change meaning) or **breaking** (meaning changes that affect conformance, verification, or reliance).\ A.1.3.3 Breaking changes MUST require a supersession object (STO) that includes: the impacted terms, migration notes, compatibility expectations, and reliance stability guidance.\ A.1.3.4 A term MUST NOT be silently edited. Any modification MUST be recorded as a new version with explicit change notes and, where applicable, a supersession chain. A.1.4 **Publication discipline and distribution.**\ A.1.4.1 The glossary MUST be published as a signed release bundle and MUST be discoverable via the registry/discovery interface.\ A.1.4.2 The glossary MUST include stable identifiers for each term (TERM IDs) to support machine-reference, translation, and semantic regression testing.\ A.1.4.3 A glossary release MUST specify its handling class and permitted distribution. Public-safe glossary bundles MUST avoid including sensitive operational details while still defining semantics required for verification and conformance. A.1.5 **Normative precedence.**\ A.1.5.1 In conflicts, glossary-defined terms control the interpretation of this paper’s normative sections and annexes unless superseded explicitly by a higher-precedence normative definition published with formal supersession semantics.\ A.1.5.2 When terms are adopted from external standards, the glossary MUST specify whether the external definition is incorporated by reference or adapted with NXOSI-specific constraints. A.1.6 **Operability defect linkage.** Any ambiguity, collision, or inconsistent usage discovered in implementation, conformance testing, or disputes MUST be logged as an operability defect and routed to glossary governance for correction or supersession. *** #### A.2 Normative keywords and interpretation rules (MUST/SHOULD/MAY) A.2.1 **Normative keywords.** This specification uses normative keywords to distinguish obligations, recommendations, permissions, and prohibitions. The following keywords are normative and MUST be interpreted as defined in this section: **MUST**, **MUST NOT**, **SHOULD**, **SHOULD NOT**, **MAY**, **REQUIRED**, **RECOMMENDED**, **OPTIONAL**. A.2.2 **Interpretation hierarchy.**\ A.2.2.1 **MUST / REQUIRED**: absolute requirement for conformance. A conformant implementation or deployment has no discretion to omit the requirement.\ A.2.2.2 **MUST NOT**: absolute prohibition. Any occurrence constitutes non-conformance.\ A.2.2.3 **SHOULD / RECOMMENDED**: strong recommendation. A conformant system may deviate only with documented justification, compensating controls, and explicit declaration of deviation in conformance reporting where the requirement affects reliance.\ A.2.2.4 **SHOULD NOT**: strong discouragement. Deviation requires explicit justification and risk acceptance, and may reduce the permitted reliance tier.\ A.2.2.5 **MAY / OPTIONAL**: permitted behavior that does not affect conformance unless separately required by a profile, overlay, or reliance tier. A.2.3 **Profile and overlay specialization.** Profiles and overlays MAY strengthen requirements (e.g., elevating SHOULD to MUST for a given risk class or jurisdiction) but MUST NOT weaken baseline mandatory requirements for NXOSI-compliant claims unless explicitly defined as a different conformance class with separate labeling and disclosure. A.2.4 **Testability rule.**\ A.2.4.1 Any requirement expressed using **MUST** or **MUST NOT** MUST be testable by a conformance harness or a relying-party verification procedure, unless explicitly and narrowly scoped as non-testable and mapped to a human review requirement with required evidence outputs.\ A.2.4.2 Non-testable requirements MUST be minimized, clearly labeled, and bounded by defined evidence artefacts (e.g., CPAR sign-off objects or docket entries) so they remain auditable. A.2.5 **Determinism and uncertainty rule.** Where requirements allow probabilistic inputs (e.g., signal fusion, trust scoring), the requirement MUST specify declared uncertainty fields and verification behavior under uncertainty, including what is deterministic (artefact linkage, signatures, scopes, clocks, and status semantics) and what is probabilistic (confidence bands, trust weights). A.2.6 **Handling-aware interpretation.** Requirements MUST be interpreted and validated in a handling-aware manner. Verification steps that would require restricted evidence access MUST be clearly separated from receipt-only verification procedures and bound to controlled disclosure workflows. *** #### A.3 Controlled terms (artefacts, clocks, reliance tiers, handling classes) A.3.1 **Controlled term registry.** This annex defines the controlled terms used throughout NXOSI. Each controlled term SHOULD be assigned a stable TERM ID and categorized as: Artefact, Clock/Timer, Reliance Tier, Handling Class, Identity/Key, Ontology Object, or Process Construct. A.3.2 **Artefact terms (core).** The following are controlled artefact terms; each term MUST map to a normative schema and linkage rules:\ A.3.2.1 **PSA (Policy/Standard Artefact):** signed, versioned normative bundle defining intent, requirements, control mappings, trigger bindings, and conformance expectations.\ A.3.2.2 **SPP (Signed Profile Package):** signed package composing controls/tests/parameters/overlays with declared dependencies and interoperability declarations.\ A.3.2.3 **TRG (Trigger Definition):** machine-evaluable predicate bound to ontology events and evidence candidates; includes clocks, scope binding rules, reliance tier defaults, and handling defaults.\ A.3.2.4 **OAR (Obligation Attachment Record):** binding object attaching obligations to an entity set and context with explicit clocks, jurisdiction, reliance tier, and disclosure defaults.\ A.3.2.5 **XPL (Execution Plan):** deterministic compiled plan defining enforcement points, checks, dependencies, failure handling, and evidence outputs.\ A.3.2.6 **CRR (Check Run Record):** signed (or integrity-protected) record of control evaluation with inputs/outputs, pass/fail semantics, attestation binding (where required), and telemetry pointers.\ A.3.2.7 **PR (Proof Receipt):** signed portable reliance object binding issuer, subject, scope, profile hash, time binding, inclusion proof pointer, and status pointer.\ A.3.2.8 **AEP (Evidence Pack):** sovereignly retained evidence bundle; the portable component is the AEP index/pointer plus access policy and retention declaration.\ A.3.2.9 **DO (Determination Object):** non-execution output expressing a decision or classification, linked to OAR/XPL/CRR/PR and ontology context.\ A.3.2.10 **GDO (Graph Determination Object):** ontology-backed determination with reasoning trace, uncertainty declarations, and sign-off requirements by reliance tier.\ A.3.2.11 **DKT (Docket):** case file object connecting obligations, checks, proofs, actions, and corrections through a defined lifecycle.\ A.3.2.12 **STO (Status Object):** revocation/supersession/scope narrowing/validity semantics published for any artefact affecting reliance.\ A.3.2.13 **COR (Correction Object):** governed correction instrument linking defect or dispute outcomes to concrete changes and status updates.\ A.3.2.14 **CPAR (Control-Plane Action Record):** operator action-as-evidence record for approvals, deployments, overrides, waivers, freezes, rollbacks, and closures. A.3.3 **Clock and timer terms.** The following clock terms are controlled and MUST be representable in OAR and in docket workflows:\ A.3.3.1 **Verification Clock:** maximum allowed time from trigger/event context to required verification completion and receipt issuance (or declared justified exception).\ A.3.3.2 **Remediation Clock:** maximum allowed time from non-conformance detection to required remediation completion (or compensating control issuance).\ A.3.3.3 **Retest Clock:** mandatory schedule for re-verification after remediation, exception expiry, or defined drift signals.\ A.3.3.4 **Dispute Clock:** challenge window during which reliance may be constrained, held, or conditioned.\ A.3.3.5 **Emergency Mode Clock:** maximum duration and conditions of break-glass behavior; includes mandatory post-incident review timeline. A.3.4 **Reliance tier terms.** Reliance tiers define what a relying party may conclude from a receipt and what additional evidence is required. Tiers MUST be declared on PR and referenced in OAR:\ A.3.4.1 **Informational Reliance:** receipt confirms an activity occurred under defined scope; no high-impact conclusions permitted.\ A.3.4.2 **Operational Reliance:** receipt supports operational decisions within defined limits; may require online status checks.\ A.3.4.3 **Audit Reliance:** receipt supports audit conclusions when paired with evidence pack access under controlled disclosure and reproducible checks.\ A.3.4.4 **Supervisory Reliance:** receipt supports supervisory/examiner reliance with defined controlled disclosure workflows, enhanced handling discipline, and stronger conformance posture. A.3.5 **Handling class terms.** Handling classes are controlled disclosure and behavior regimes applied to all artefacts and evidence stores:\ A.3.5.1 **Public:** safe for open distribution; must avoid sensitive identity metadata and must preserve minimal disclosure.\ A.3.5.2 **Controlled:** restricted distribution; access logged; redaction required for downstream sharing; lawful basis controls apply.\ A.3.5.3 **Restricted:** highest sensitivity; small-cell access; strict no-forward rules; mandatory access logging; additional do-no-harm safeguards. A.3.6 **Term usage discipline.** Implementations, profiles, and overlays MUST use controlled terms as defined. Synonyms MUST NOT be introduced in normative contexts without explicit aliasing in the glossary and machine-readable mapping. *** #### A.4 Abbreviation register and reserved namespaces A.4.1 **Abbreviation register.**\ A.4.1.1 A machine-readable abbreviation register MUST be maintained as part of the glossary release bundle, including abbreviation, expansion, TERM ID (where applicable), and first-introduced version.\ A.4.1.2 Abbreviations MUST be unambiguous within the NXOSI domain. If collision exists with a widely used external abbreviation, the glossary MUST define disambiguation rules or choose an alternative. A.4.2 **Reserved namespaces (identifiers).** The following namespace classes MUST be reserved to ensure global uniqueness and prevent spoofing:\ A.4.2.1 **Artefact identifiers** for PSA/SPP/TRG/OAR/XPL/CRR/PR/AEP/DO/GDO/DKT/STO/COR/CPAR.\ A.4.2.2 **Issuer identifiers** for authorized receipt issuers and status publishers.\ A.4.2.3 **Profile and overlay namespaces** for baseline, sector, hazard, and jurisdiction packs.\ A.4.2.4 **Ontology namespaces** for entity classes, relation types, event types, and provenance objects.\ A.4.2.5 **Conformance test namespaces** for harness suites, vectors, and results. A.4.3 **Namespace governance.**\ A.4.3.1 The registry/discovery service MUST enforce namespace ownership, delegation rules, and revocation procedures.\ A.4.3.2 Namespace assignment MUST be auditable and include issuance authority, validity windows, and status pointers.\ A.4.3.3 Namespace squatting and impersonation MUST be treated as a security incident and addressed via takedown, status updates, and public correction where reliance risk exists. A.4.4 **Compatibility and interop labeling.** Namespace rules MUST support interoperability labeling, including explicit version floors/ceilings and deprecation timelines, so relying parties can evaluate compatibility without privileged access. *** #### A.5 Terminology conflict resolution rules (supersession discipline) A.5.1 **Conflict definition.** A terminology conflict exists when:\ A.5.1.1 A term is used with different meanings across normative sections, profiles, overlays, or implementations;\ A.5.1.2 Two terms refer to the same meaning without explicit aliasing;\ A.5.1.3 A term’s meaning changes without an explicit supersession chain; or\ A.5.1.4 External definitions incorporated by reference diverge from NXOSI usage without clear scoping. A.5.2 **Resolution hierarchy.**\ A.5.2.1 The glossary release designated as authoritative for a given document version controls meaning.\ A.5.2.2 Where multiple glossary versions exist, the version bound to the receipt/profile artefact by hash and version metadata controls interpretation for that artefact.\ A.5.2.3 Overlays may add jurisdiction-specific clarifications but MUST NOT silently redefine baseline controlled terms; meaning changes require explicit supersession and compatibility notes. A.5.3 **Supersession discipline.**\ A.5.3.1 Any meaning change MUST be executed via a status/supersession object referencing the prior term version, the new term version, the reason for change, and migration guidance.\ A.5.3.2 Supersession MUST specify reliance impact: which receipts remain valid under prior meaning, what verification procedures change, and whether re-issuance or retesting is required.\ A.5.3.3 Supersession MUST define a transition window where both meanings can be resolved deterministically, including explicit labeling and verifier behavior. A.5.4 **Alias and deprecation rules.**\ A.5.4.1 If two terms are synonyms, the glossary MUST designate one as canonical and the other as an alias, with machine-readable mapping and deprecation timeline if the alias is to be retired.\ A.5.4.2 Deprecated terms MUST remain resolvable for archival verification and historical receipt interpretation for the duration of defined retention and long-lived verification requirements. A.5.5 **Semantic regression testing for terms.** Any change to controlled terms MUST trigger semantic regression tests: verification procedures, conformance harness expectations, overlay composition behavior, and relying-party inference limits MUST be revalidated against gold vectors and negative tests. A.5.6 **Dispute handling.** Terminology disputes that affect reliance MUST be treated as due-process events: docketed, time-bound, and resolved with publishable summaries consistent with handling rules, followed by a controlled supersession or clarification release. --- # 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-a.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.