# Annex B

#### B.1 Identifier and namespace rules (global uniqueness; resolvability; collision handling)

B.1.1 **Global uniqueness requirement.** Every NXOSI artefact MUST be globally uniquely identifiable using a stable, immutable identifier that remains valid across sovereign deployments, vendors, and storage backends. Identifiers MUST support offline verification, long-lived archival validation, and deterministic linkage across artefacts.

B.1.2 **Namespace structure.**\
B.1.2.1 Identifiers MUST be namespaced to prevent collision and impersonation. A canonical form SHALL include: **namespace root**, **object class**, **issuer domain**, **object-local identifier**, and **version**.\
B.1.2.2 Namespace roots MUST be reserved and governed for: PSA, SPP, TRG, OAR, XPL, CRR, PR, AEP, DO, GDO, DKT, STO, CPAR, and supporting registries.\
B.1.2.3 Namespace governance MUST include issuance authority, delegation rules, revocation rules, and audit logs for assignment and transfer.

B.1.3 **Resolvable by design.**\
B.1.3.1 Every identifier MUST be resolvable to **(i)** an object metadata record and **(ii)** a status pointer (STO endpoint), even when the full content is not publicly retrievable.\
B.1.3.2 Resolution MUST be handling-aware: Public identifiers may resolve to public-safe metadata; Controlled/Restricted objects must resolve to minimal metadata plus controlled access policy pointers without content leakage.\
B.1.3.3 Offline resolution MUST be supported via signed snapshots or verification bundles that include required metadata and status proofs for defined reliance tiers.

B.1.4 **Collision handling.**\
B.1.4.1 On detection of identifier collision, the registry MUST treat it as a security incident, quarantine the conflicting identifiers, and publish a status update indicating collision and invalidation semantics.\
B.1.4.2 Collision response MUST include a deterministic tie-break mechanism (issuer authorization, signature validation, transparency inclusion) and MUST result in explicit status objects for all impacted artefacts.\
B.1.4.3 Relying-party procedures MUST define required behavior under collision (halt reliance; require status resolution; open dispute docket if needed).

B.1.5 **Canonical IDs vs content addresses.**\
B.1.5.1 NXOSI MAY use content-addressed identifiers (hash IDs) internally, but MUST maintain a canonical stable identifier for each artefact that survives repackaging or storage migration.\
B.1.5.2 Receipts MUST bind to content hashes for integrity, while also carrying canonical identifiers for linkage and discovery.

B.1.6 **Issuer authorization binding.** Issuer identifiers and authorization proofs MUST be resolvable and MUST support revocation. A receipt or status object is invalid if issued by an unauthorized or revoked issuer for that object class.

***

#### B.2 Core schema conventions (required fields, versioning, handling markers, signatures)

B.2.1 **Canonical schema approach.** All NXOSI objects MUST conform to canonical schemas, expressed in a machine-validated format with explicit versioning and strict field definitions. Schemas MUST be stable, deterministic, and testable.

B.2.2 **Required core fields (all objects).** Each object MUST include, at minimum:\
B.2.2.1 `object_id` (canonical global identifier)\
B.2.2.2 `object_type` (PSA/SPP/TRG/OAR/XPL/CRR/PR/AEP/DO/GDO/DKT/STO/CPAR)\
B.2.2.3 `schema_id` and `schema_version` (semantic versioned)\
B.2.2.4 `issuer` (issuer ID + authorization reference)\
B.2.2.5 `issued_at` (time binding)\
B.2.2.6 `handling_class` (Public/Controlled/Restricted)\
B.2.2.7 `reliance_tier` (where applicable)\
B.2.2.8 `status_pointer` (STO endpoint or reference)\
B.2.2.9 `integrity` (hashes, signatures, countersignatures as applicable)\
B.2.2.10 `links` (required cross-references for end-to-end traceability)

B.2.3 **Versioning rules.**\
B.2.3.1 Schema versions MUST be semantic-versioned and include compatibility notes.\
B.2.3.2 Object instances MUST declare their schema version, and verifiers MUST enforce version compatibility rules defined in Part 8/13.\
B.2.3.3 Breaking schema changes MUST be accompanied by migration guidance and conformance vectors.

B.2.4 **Handling markers and disclosure control.**\
B.2.4.1 Handling class is mandatory on every object and MUST be enforced in resolution and export.\
B.2.4.2 Objects MUST support minimal disclosure: public-safe summaries may be generated, but MUST remain linkable to the canonical object ID and MUST not introduce new semantics.

B.2.5 **Signature and integrity conventions.**\
B.2.5.1 Objects that are portable reliance artefacts (PR, STO) MUST be signed.\
B.2.5.2 Objects that drive obligations and governance (PSA, SPP, TRG, OAR, XPL) MUST be signed or anchored with equivalent integrity guarantees and verifiable issuer authorization.\
B.2.5.3 CRR, CPAR, and DKT entries MUST be integrity-protected and linkable; they SHOULD be signed when they affect reliance tier or trigger dispute/correction outcomes.

B.2.6 **Linkage discipline.** Each object MUST include explicit links to its upstream and downstream artefacts, enabling an auditor or verifier to traverse: policy/profile → obligation attachment → execution plan → check runs → receipts → dockets → status/corrections.

***

#### B.3 PSA schema (Policy/Standard Artefact)

B.3.1 **Purpose.** PSA is the canonical normative object representing policy intent and requirements decomposed into controls/tests, with trigger bindings and expected evidence outputs.

B.3.2 **Mandatory PSA fields.**\
B.3.2.1 `psa_id`, `schema_version`, `issuer`, `issued_at`, `handling_class`\
B.3.2.2 `title`, `scope`, `applicability` (entity types, domains, hazard classes)\
B.3.2.3 `normative_requirements` (structured MUST/SHOULD/MAY statements with testability tags)\
B.3.2.4 `control_mappings` (requirement → control IDs)\
B.3.2.5 `test_expectations` (control → test IDs; pass/fail semantics)\
B.3.2.6 `trigger_bindings` (requirement/control → TRG IDs)\
B.3.2.7 `reliance_impact` (per requirement/control where reliance tier changes)\
B.3.2.8 `compatibility` (version floors/ceilings; dependencies)\
B.3.2.9 `status_pointer` and `supersession_chain` (if applicable)\
B.3.2.10 `release_integrity` (SBOM/provenance/signatures for PSA tooling outputs)

B.3.3 **Testability metadata.** Each normative statement MUST be tagged as testable-by-harness, testable-by-procedure, or human-reviewed-with-evidence, with required evidence artefact types specified.

***

#### B.4 SPP schema (Signed Profile Package)

B.4.1 **Purpose.** SPP is the composable runtime-ready package that selects and parameterizes standards/controls/tests for a context (sector, hazard, jurisdiction), including overlays and interoperability declarations.

B.4.2 **Mandatory SPP fields.**\
B.4.2.1 `spp_id`, `profile_name`, `profile_version`, `issuer`, `issued_at`, `handling_class`\
B.4.2.2 `dependencies` (other SPP IDs with version constraints)\
B.4.2.3 `overlays` (jurisdiction overlays applied; precedence order)\
B.4.2.4 `parameters` (thresholds, clocks, scopes, risk tiers)\
B.4.2.5 `composition_rules` (stacking order, conflict resolution policy)\
B.4.2.6 `interop_declarations` (events/messages produced/consumed; ontology bindings)\
B.4.2.7 `required_tests` (test suites/vectors required for conformance)\
B.4.2.8 `enforcement_points` (build/deploy/runtime/procurement/incident/retest coverage)\
B.4.2.9 `expected_outputs` (CRR/PR patterns; evidence quality expectations)\
B.4.2.10 `status_pointer` and `compatibility_notes` (migration, deprecation)

B.4.3 **Portability contract.** SPP MUST declare the minimum dependency set required for interop and the conditions under which receipts remain valid across overlay changes.

***

#### B.5 TRG schema (Trigger definition)

B.5.1 **Purpose.** TRG defines machine-evaluable predicates bound to ontology events and evidence candidates that attach obligations and start clocks.

B.5.2 **Mandatory TRG fields.**\
B.5.2.1 `trg_id`, `issuer`, `issued_at`, `handling_class`\
B.5.2.2 `predicate` (formal logic expression with ontology event bindings)\
B.5.2.3 `scope_binding_rules` (how to select entity sets from ontology context)\
B.5.2.4 `uncertainty_policy` (confidence thresholds; fallback behavior)\
B.5.2.5 `clock_templates` (verification/remediation/retest/dispute/emergency)\
B.5.2.6 `default_reliance_tier` and `default_handling`\
B.5.2.7 `dispute_window_policy` (challenge rights and holds)\
B.5.2.8 `status_pointer` (revocation/supersession)

***

#### B.6 OAR schema (Obligation Attachment Record)

B.6.1 **Purpose.** OAR binds obligations to specific entities, jurisdictions, time windows, and clocks, forming the canonical operational contract for accountability.

B.6.2 **Mandatory OAR fields.**\
B.6.2.1 `oar_id`, `issuer`, `issued_at`, `handling_class`, `status_pointer`\
B.6.2.2 `trigger_ref` (TRG ID), `profile_ref` (SPP ID), `psa_refs` (PSA IDs)\
B.6.2.3 `scope` (entity set IDs, geography, jurisdiction, time window, hazard class)\
B.6.2.4 `clocks` (verification, remediation, retest, dispute, emergency mode)\
B.6.2.5 `enforcement_points` (required coverage for this obligation instance)\
B.6.2.6 `disclosure_policy` (reliance tier, handling defaults, evidence access policy pointer)\
B.6.2.7 `emergency_mode` (eligibility, constraints, mandatory CPAR)\
B.6.2.8 `linkage` (docket pointer; expected PR outputs)

***

#### B.7 XPL schema (Execution Plan)

B.7.1 **Purpose.** XPL is the deterministic compiled plan that drives checks, evidence capture, and failure handling.

B.7.2 **Mandatory XPL fields.**\
B.7.2.1 `xpl_id`, `issuer`, `issued_at`, `handling_class`, `status_pointer`\
B.7.2.2 `inputs` (SPP + overlays + OAR + ontology snapshot hash)\
B.7.2.3 `plan_graph` (ordered checks, dependencies, enforcement points)\
B.7.2.4 `determinism_contract` (equivalence criteria; allowed uncertainty)\
B.7.2.5 `data_dependencies` (required telemetry, attestations, evidence candidates)\
B.7.2.6 `failure_policy` (deny/degrade/quarantine/escalate; docket triggers)\
B.7.2.7 `outputs` (required CRR/PR emission rules)\
B.7.2.8 `replay_protection` (context binding; anti-misuse constraints)

***

#### B.8 CRR schema (Check Run Record)

B.8.1 **Purpose.** CRR records each control evaluation with defined semantics, evidence pointers, and attestation binding where required.

B.8.2 **Mandatory CRR fields.**\
B.8.2.1 `crr_id`, `issuer`, `issued_at`, `handling_class`\
B.8.2.2 `control_id`, `test_id` (where applicable)\
B.8.2.3 `inputs` (hashes/pointers; declared input set)\
B.8.2.4 `outputs` (pass/fail; measured values; justification codes)\
B.8.2.5 `attestation_binding` (claims, appraisal result, freshness) when required\
B.8.2.6 `telemetry_pointers` (trace context; logs; metrics pointers)\
B.8.2.7 `waiver_ref` (if any) with expiry and authority\
B.8.2.8 `oar_ref` and `xpl_ref` linkage\
B.8.2.9 `anti_replay` (context binding metadata)

***

#### B.9 PR schema (Proof Receipt)

B.9.1 **Purpose.** PR is the portable reliance object that travels across vendors and jurisdictions without exfiltrating evidence.

B.9.2 **Mandatory PR fields.**\
B.9.2.1 `pr_id`, `issuer`, `issued_at`, `handling_class`\
B.9.2.2 `subject` (entity set or system ID; minimal metadata)\
B.9.2.3 `scope` (jurisdiction, time window, hazard class, obligation scope reference)\
B.9.2.4 `profile_hash` and `profile_ref` (SPP binding)\
B.9.2.5 `time_binding` (freshness, expiry, anti-replay)\
B.9.2.6 `inclusion_proof_pointer` (transparency publication)\
B.9.2.7 `status_pointer` (STO endpoint)\
B.9.2.8 `reliance_tier` and `permitted_inference_limits`\
B.9.2.9 `selective_disclosure` fields (redaction policy IDs; summary hash)\
B.9.2.10 `links` to OAR/XPL/CRR set and docket reference (as permitted by handling)

***

#### B.10 AEP index schema (Evidence Pack index + retention declaration)

B.10.1 **Purpose.** The AEP index is the portable pointer and policy wrapper around sovereignly retained evidence.

B.10.2 **Mandatory AEP index fields.**\
B.10.2.1 `aep_id`, `issuer`, `issued_at`, `handling_class`\
B.10.2.2 `evidence_zone` (sovereign zone identifier; residency constraints)\
B.10.2.3 `contents_manifest` (hashes of included artefacts; transformation manifests)\
B.10.2.4 `access_policy_pointer` (approval workflow; escrow rules; access logging)\
B.10.2.5 `lawful_basis_matrix_ref` and `purpose_limitations`\
B.10.2.6 `retention_declaration` (min/max retention; destruction triggers)\
B.10.2.7 `disclosure_summary` (public-safe/controlled summaries; redaction policy)\
B.10.2.8 `links` to PR/CRR/OAR/DKT (as permitted)

***

#### B.11 DO schema (Determination Object)

B.11.1 **Purpose.** DO expresses a non-execution determination derived from checks and evidence, suitable for routing into workflows.

B.11.2 **Mandatory DO fields.**\
B.11.2.1 `do_id`, `issuer`, `issued_at`, `handling_class`, `status_pointer`\
B.11.2.2 `determination_type` and `determination_code` (controlled vocabulary)\
B.11.2.3 `basis_refs` (OAR/XPL/CRR/PR references; ontology snapshot hash)\
B.11.2.4 `constraints` (non-execution assertions; no market/claims/custody acts)\
B.11.2.5 `recommended_actions` (routing guidance; playbook refs)\
B.11.2.6 `uncertainty` (confidence bands; declared assumptions)\
B.11.2.7 `docket_ref` (DKT linkage)

***

#### B.12 GDO schema (Graph Determination Object)

B.12.1 **Purpose.** GDO binds determinations to ontology reasoning traces to enable semantic auditability.

B.12.2 **Mandatory GDO fields.**\
B.12.2.1 All DO fields, plus:\
B.12.2.2 `graph_trace` (entities/relations/events referenced; provenance pointers)\
B.12.2.3 `reasoning_manifest` (transformations, rules, inference steps)\
B.12.2.4 `trust_score_context` (inputs and weights; bounded influence compliance flags)\
B.12.2.5 `human_signoff` requirements by reliance tier (approvers; CPAR refs)

***

#### B.13 DKT schema (Docket object)

B.13.1 **Purpose.** DKT is the canonical case file for the lifecycle of obligations, actions, and corrections.

B.13.2 **Mandatory DKT fields.**\
B.13.2.1 `dkt_id`, `issuer`, `opened_at`, `handling_class`\
B.13.2.2 `state` (open/update/pending remediation/retest/closed)\
B.13.2.3 `scope` and `party_refs` (minimal; handling-aware)\
B.13.2.4 `artefact_links` (OAR/XPL/CRR/PR/AEP/DO/GDO/STO/CPAR)\
B.13.2.5 `clock_status` (deadlines and breach status)\
B.13.2.6 `workflow_hooks` (ITSM/SOC/GRC references)\
B.13.2.7 `closure_criteria` and `closure_receipts` (required PRs to close)

***

#### B.14 STO schema (Status object)

B.14.1 **Purpose.** STO is the authoritative status and correction surface for reliance stability.

B.14.2 **Mandatory STO fields.**\
B.14.2.1 `sto_id`, `issuer`, `issued_at`, `handling_class`\
B.14.2.2 `target_object_id` and `target_object_type`\
B.14.2.3 `status_type` (valid/revoked/superseded/scope\_narrowed/expired)\
B.14.2.4 `effective_time` and `validity_window`\
B.14.2.5 `reason_code` (controlled vocabulary)\
B.14.2.6 `supersedes` / `superseded_by` links (where applicable)\
B.14.2.7 `migration_notes` and `reliance_impact`\
B.14.2.8 `dispute_ref` (DKT/COR pointer when status is contested)\
B.14.2.9 `signature` and `authorization_ref`

***

#### B.15 CPAR schema (Control-Plane Action Record)

B.15.1 **Purpose.** CPAR records operator actions as evidence with duty separation and governance constraints.

B.15.2 **Mandatory CPAR fields.**\
B.15.2.1 `cpar_id`, `issuer`, `issued_at`, `handling_class`\
B.15.2.2 `action_type` (approve/deploy/override/waive/freeze/rollback/close)\
B.15.2.3 `actor_role` (role marker; identity minimization) and `authorization_ref`\
B.15.2.4 `object_refs` (affected PSA/SPP/OAR/XPL/CRR/PR/DKT/STO)\
B.15.2.5 `justification` (structured; policy references)\
B.15.2.6 `constraints_applied` (SoD checks; break-glass limits)\
B.15.2.7 `expiry` (for overrides/waivers)\
B.15.2.8 `post_review_required` flags and review deadlines\
B.15.2.9 `audit_export_refs` (where exported)

***

#### B.16 Common envelope schema (crypto suite IDs, time binding, countersignatures, PQ fields)

B.16.1 **Purpose.** The common envelope defines the shared cryptographic and time-binding wrapper used across signed objects, ensuring consistent verification and crypto agility.

B.16.2 **Mandatory envelope fields (for signed objects).**\
B.16.2.1 `crypto_suite_id` (versioned; algorithm set identifier)\
B.16.2.2 `signature` (primary signature) and `signing_key_id`\
B.16.2.3 `issuer_authorization_ref` (issuer authorization proof and status pointer)\
B.16.2.4 `issued_at`, `not_before`, `expires_at` (freshness and validity windows)\
B.16.2.5 `nonce` / `sequence` and `context_binding` (anti-replay; scope binding)\
B.16.2.6 `content_hash` (hash of canonical serialized payload)\
B.16.2.7 `countersignatures` (optional; quorum/dual-control cases)\
B.16.2.8 `transparency_anchor` (optional pointer for inclusion anchoring)\
B.16.2.9 `pq_fields` (optional): `pq_crypto_suite_id`, `pq_signature`, `dual_signing_window`, `pq_migration_clock`

B.16.3 **Canonical serialization.** The envelope MUST specify canonical serialization rules for hashing and signing so that independent implementations produce identical `content_hash` for the same payload.

B.16.4 **Dual-signing and migration.** Where post-quantum transition is active, envelope semantics MUST support dual-signing, explicit migration clocks, and long-lived verification bundles that carry both signature sets and verifier instructions.


---

# 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-b.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.