# Annex S

#### S.1 Telemetry minimum fields and linkage rules (check→receipt→docket→correction)

S.1.1 **Purpose.** This Annex defines the **minimum observability schema and linkage semantics** required for NXOSI to maintain evidence lineage-by-default, support portable proof receipts, enable examiner-operable verification, and operate under degraded conditions—without violating handling discipline or sovereignty constraints.

S.1.2 **Scope.** Applies to observability events emitted by NXOSI components and enterprise adapters across enforcement points (build/deploy/runtime/procurement/incident/retest), including security events, performance events, policy/runtime decisions, and control-plane actions.

S.1.3 **Non-goals.** This Annex does not mandate a specific logging vendor, SIEM platform, telemetry backend, or storage architecture. It defines **what must be observable and linkable**, not how a specific tool implements it.

S.1.4 **Normative invariants.** Observability MUST:

* preserve end-to-end linkage from **obligations → checks → receipts → dockets → corrections**;
* support **receipt-only reliance** where lawful basis prevents evidence disclosure;
* enforce **handling-aware minimization** (no unnecessary identity metadata, no PII leakage);
* be **verifiable and tamper-evident** (integrity protection and time binding).

S.1.5 **Linkage doctrine.** Every observability event that is relevant to a check, receipt, docket, status action, or control-plane action MUST carry sufficient identifiers to support deterministic reconstruction of the lineage chain.

S.1.6 **Canonical linkage set (mandatory).** For any event that participates in NXOSI lineage, the following identifiers MUST be present if the referenced object exists at the time of emission:

* `oar_id` (Obligation Attachment Record identifier)
* `xpl_id` (Execution Plan identifier)
* `crr_id` (Check Run Record identifier) for check-related events
* `pr_id` (Proof Receipt identifier) for proof-related events
* `aep_index_id` (Evidence Pack Index identifier) where evidence packs exist (pointer only)
* `dkt_id` (Docket identifier) where a docket exists or is being created/updated
* `sto_id` (Status Object identifier) where revocation/supersession/scope narrowing is issued/proposed
* `cpar_id` (Control-Plane Action Record identifier) for any operator action or approval step
* `psa_id` and `spp_id` (policy/profile package identifiers) and their versions/hashes for policy-binding

S.1.7 **Cross-reference rules (mandatory).**

S.1.7.1 A **CRR-producing** event MUST include `crr_id`, `control_id`, `oar_id`, `xpl_id`, and the applicable `spp_id` (hash + version).

S.1.7.2 A **PR issuance** event MUST include `pr_id`, `oar_id`, `xpl_id`, and the set (or hash) of `crr_id` values bound into the receipt.

S.1.7.3 A **DKT update** event MUST include `dkt_id`, the referenced `oar_id` (if any), and at least one of `pr_id`, `crr_id`, or `cpar_id` to prove why the docket changed.

S.1.7.4 A **correction-related** event MUST include `sto_id` or `cor_id` (if defined elsewhere), plus the identifiers of superseded objects (e.g., prior `pr_id`, prior `spp_id` version, prior ontology semantic version) sufficient to reproduce reliance resolution.

S.1.7.5 A **CPAR event** MUST include the identifiers of all impacted artefacts (at minimum: `psa_id`/`spp_id`/`oar_id`/`xpl_id`/`dkt_id`/`sto_id` where relevant) and MUST declare authority basis and handling class.

S.1.8 **Time binding (mandatory).** Every event MUST carry:

* an event timestamp with a defined clock source class (trusted, local, offline-approximate),
* an ordering/sequence mechanism sufficient for replay protection within the emitting subsystem,
* optional correlation to transparency checkpoints where relevant (e.g., PR inclusion).

S.1.9 **Integrity protection (mandatory).**

* Events MUST be integrity-protected at rest and in transit (signing or equivalent tamper-evidence).
* For high-impact reliance tiers, event streams MUST support audit-grade tamper detection (append-only log semantics or verifiable hashing strategy) consistent with deployment constraints.

S.1.10 **Minimum event classes (mandatory).** A conformant deployment MUST emit at least:

* check execution start/finish events (per CRR),
* receipt issuance events (per PR),
* status publication events (per STO),
* docket state transitions (per DKT),
* override/break-glass events (per CPAR),
* degraded-mode transitions and sync lag indicators,
* security normalization events per S.3.

***

#### S.2 Trace context requirements and retention minima

S.2.1 **Purpose.** Trace context enables correlation across tools, zones, and organizations without requiring sensitive content. It is required to support reproducible verification and examiner-operable review.

S.2.2 **Trace context fields (mandatory).** Every lineage-relevant event MUST include:

* `trace_id` (global correlation identifier)
* `span_id` (local span identifier)
* `parent_span_id` (if applicable)
* `emitter_component` (NX layer or subsystem: NX-3/4/5/6/7/8/9/10/11)
* `enforcement_point` (build/deploy/runtime/procurement/incident/retest/control-plane)
* `handling_class` marker (Public/Controlled/Restricted)
* `reliance_tier` marker where the event binds to a PR/OAR (informational/operational/audit/supervisory)

S.2.3 **Zone markers (mandatory).** Events MUST include a zone marker sufficient to enforce sovereignty and handling constraints without revealing sensitive topology (e.g., `zone_class = sovereign|portable|airgapped`, plus optional abstract `zone_id`).

S.2.4 **Retention minima (mandatory, tiered).** Retention MUST be driven by reliance tier, lawful basis, and handling class, and MUST be explicitly declared in policy. At minimum:

S.2.4.1 **Receipt lineage retention.** Linkage metadata necessary to verify PR/STO resolution MUST be retained for the maximum validity window of receipts plus the dispute window plus any mandated archival verification period.

S.2.4.2 **Controlled evidence pointers.** AEP index pointers and access logs MUST be retained for auditability for at least the minimum period required to support supervisory reliance where such reliance is permitted.

S.2.4.3 **Degraded-mode logs.** Offline/degraded transition events and sync lag indicators MUST be retained long enough to reconstruct verification constraints during disruptions.

S.2.5 **Retention upper bounds and minimization.** Where lawful basis restricts retention, NXOSI MUST still retain a minimal portability set:

* PR verification artefacts,
* STO timelines,
* conformance reports and test receipts,
* non-sensitive lineage metadata,\
  while ensuring sensitive content remains in-zone or is destroyed per lawful basis.

***

#### S.3 Normalized incident/security semantics mapping requirements

S.3.1 **Purpose.** Security and incident telemetry must be portable across vendors and comparable across deployments. NXOSI therefore requires a normalized semantic layer for incident and security events.

S.3.2 **Normalization obligations (mandatory).** A conformant deployment MUST map local security/incident signals into a **canonical event schema** with stable meanings. Implementations MAY preserve native fields but MUST provide the canonical fields.

S.3.3 **Canonical security/incident event fields (mandatory).**

* `event_category` (security|availability|integrity|privacy|governance|safety)
* `event_type` (normalized type, e.g., intrusion\_attempt, privilege\_escalation, policy\_override, data\_exfil\_suspected, integrity\_violation, outage, degraded\_mode, attestation\_failure, equivocation\_suspected)
* `severity` (normalized ordinal + optional rationale)
* `confidence` (bounded uncertainty declaration)
* `affected_entity_ids` (ontology IDs where available; otherwise abstracted identifiers)
* `affected_scope` (service/system/vendor/region/jurisdiction bounds)
* `detection_method` (telemetry|attestation|human\_report|third\_party\_notice|audit\_findings)
* `required_response_clock` (pointer to OAR clocks or incident clocks)
* `linkage_set` per S.1.6 when applicable

S.3.4 **Security-relevant NXOSI-specific event types (mandatory support).**\
Deployments MUST support normalized types for:

* policy/standard change deployed (SAC lifecycle events),
* override invoked / kill switch engaged,
* receipt issuance / inclusion delayed beyond permitted window,
* status action issued (revocation/supersession/scope narrowing),
* attestation failure / stale measurement,
* ontology poisoning suspected / assertion quarantined,
* transparency anomaly / split-view suspicion (where detectable),
* unauthorized access attempt to controlled evidence (AEP access policy violation).

S.3.5 **Handling-aware semantics.** Normalized events MUST include handling markers and MUST avoid embedding sensitive payloads. Where rich payload is needed, it MUST be held in-zone and referenced by controlled pointers.

***

#### S.4 Handling-aware observability (metadata minimization; redaction rules)

S.4.1 **Purpose.** Observability is a major metadata leakage vector. NXOSI observability must therefore follow strict minimal disclosure rules aligned to handling classes and lawful basis matrices.

S.4.2 **Handling markers (mandatory).** Every event MUST be marked as Public/Controlled/Restricted, and downstream systems MUST enforce:

* controlled export restrictions,
* field-level redaction by class,
* lawful-basis gating for disclosure.

S.4.3 **Metadata minimization (mandatory).** Events MUST NOT include:

* PII unless explicitly required by lawful basis and handling rules,
* unnecessary user identities (prefer role markers),
* raw content of restricted evidence (store pointers in-zone instead),
* secrets, tokens, credentials, or sensitive configuration values.

S.4.4 **Redaction rules (mandatory).**

* For exports outside sovereign zones, Restricted fields MUST be redacted or summarized.
* Controlled exports MUST include disclosure logs and lawful basis assertions.
* Public-safe summaries MUST be limited to permitted inference for the reliance tier and MUST carry explicit inference constraints.

S.4.5 **Cross-border constraints.** Where cross-border transfer is restricted, the observability export MUST consist of:

* receipts and verification outputs,
* status timelines,
* conformance results,
* minimal linkage metadata,\
  with no controlled evidence content.

S.4.6 **Access logging for observability.** Access to Controlled/Restricted observability stores MUST be logged and MUST be queryable for audit, including who accessed what, when, and under what authority basis.

***

#### S.5 Drift detection signals and alert thresholds

S.5.1 **Purpose.** NXOSI must operate continuously, not as periodic audit. Drift detection provides the operational signal loop that triggers retest clocks, tightened obligations, and correction workflows.

S.5.2 **Minimum drift signal categories (mandatory).** A conformant deployment MUST implement signals for:

S.5.2.1 **Policy/standard drift.** Deployed SAC policy differs from declared version; unapproved change attempt detected; mismatch between PSA/SPP versions and runtime enforcement.

S.5.2.2 **Profile/overlay drift.** Overlay updates change effective obligations; incompatibility detected; dependency set changes beyond allowed bounds.

S.5.2.3 **Execution drift.** Check results trend away from baseline; enforcement points missing; check coverage regression; repeated waiver usage beyond thresholds.

S.5.2.4 **Attestation drift.** Freshness windows violated; appraisal failures increase; endorsements revoked; measurement sets change unexpectedly.

S.5.2.5 **Ontology semantic drift.** Meaning changes not superseded; semantic regression tests fail; identity resolution collision spikes; quarantines increase.

S.5.2.6 **Security drift.** Increase in normalized event types such as privilege escalation, override attempts, transparency anomalies, or evidence access violations.

S.5.3 **Threshold declaration (mandatory).** Drift thresholds MUST be:

* explicitly parameterized in profiles/overlays,
* bound to OAR clocks and escalation ladders,
* auditable (threshold values and changes are governed artefacts, not hidden tuning).

S.5.4 **Alert outputs (mandatory).** When a drift threshold is exceeded, NXOSI MUST emit:

* a normalized drift event (S.3),
* linkage to affected OAR/XPL/CRR/PR/DKT objects,
* an escalation action requirement (open docket, retest clock start, or status review recommendation),
* handling-aware summaries suitable for the reliance tier.

S.5.5 **Degraded-mode drift behavior.** In offline/degraded operation:

* drift detection MAY operate locally with cached baselines,
* alerts MUST be queued for later synchronization,
* reliance constraints MUST be displayed in NXCP and exported as evidence.

***

#### S.6 Observability conformance tests (completeness and linkage integrity)

S.6.1 **Purpose.** Observability is only useful if it is consistent, complete, and linkable. This section defines the mandatory conformance tests for observability.

S.6.2 **Completeness tests (mandatory).**

S.6.2.1 **Event emission coverage.** For each enforcement point included in a deployment’s conformance claim, test harnesses MUST verify that:

* check start/finish events exist per CRR,
* receipt issuance events exist per PR,
* docket transition events exist per DKT,
* status events exist per STO,
* CPAR events exist for governed actions.

S.6.2.2 **Field presence.** Tests MUST confirm presence of required fields:

* linkage set (S.1.6) where applicable,
* trace context (S.2.2),
* handling markers (S.4.2),
* normalized semantics (S.3.3).

S.6.3 **Linkage integrity tests (mandatory).**

S.6.3.1 **Chain reconstruction.** Given a PR, the harness MUST be able to reconstruct:\
PR → referenced CRRs → XPL → OAR → TRG context (as available) → DKT entries → STO timeline → CPAR actions\
using only identifiers and permitted pointers under the declared handling class.

S.6.3.2 **No-orphan rule.** Tests MUST flag orphan artefacts and orphan events:

* CRRs without OAR/XPL linkage,
* PRs without CRR linkage,
* Docket state changes without justification linkage,
* status actions without superseded/target IDs.

S.6.3.3 **Tamper-evidence checks.** Where integrity protections are declared, harness MUST verify:

* signature/hashing validity of event bundles,
* monotonic sequencing where required,
* detection of modified or missing records.

S.6.4 **Normalization tests (mandatory).**

S.6.4.1 **Mapping correctness.** Native incident/security events MUST map to normalized `event_category` and `event_type` with required fields.

S.6.4.2 **Handling compliance.** Tests MUST ensure restricted payload is not present in exportable event streams and that redaction is enforced.

S.6.5 **Drift tests (mandatory).** Harness MUST include scenarios that induce drift:

* profile version change,
* overlay parameter shift,
* attestation freshness failure,
* ontology semantic regression,\
  and confirm correct alert emission and docket/clock behavior.

S.6.6 **Conformance reporting outputs.** Conformance results MUST be published as:

* machine-readable signed report,
* human-readable summary (public-safe vs controlled),\
  including explicit statement of coverage limitations (which enforcement points, which event categories, which drift signals).


---

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