# Annex M

#### M.1 Event bus contract (ordering, idempotency, replay handling, delivery guarantees)

M.1.1 **Purpose.** This Annex defines the normative runtime messaging contract that enables multiple profiles (base/sector/hazard/jurisdiction) to coordinate in real time without semantic drift, handling leakage, or vendor lock-in. The objective is predictable interoperation across NX-3 (Ontology Fabric), NX-4 (Triggers/OAR), NX-6 (Check Runtimes), NX-8 (Rails), and NX-10 (Standards-as-Code Runtime).

M.1.2 **Event bus role.** The event bus is the transport and delivery contract for *profile events*—machine-readable signals emitted by NXOSI components and consumed by profiles and runtimes to:

M.1.2.1 Evaluate triggers and attach obligations (TRG→OAR).

M.1.2.2 Coordinate cross-profile dependencies (e.g., hazard overlay tightening a sector profile).

M.1.2.3 Propagate execution outcomes (CRR/PR status changes, drift signals, exception objects).

M.1.2.4 Drive monitoring clocks and remediation escalations.

M.1.3 **Delivery semantics classes.** The bus MUST support, at minimum, two delivery semantics classes, declared per topic/message type:

M.1.3.1 **At-least-once delivery** (default) with idempotency requirements (M.1.7).

M.1.3.2 **Exactly-once effective processing** (optional) implemented via idempotency keys + deduplication windows + deterministic handlers; implementations MAY differ, but conformance is measured by observable effective-once behavior.

M.1.4 **Ordering contract.** Because global ordering is expensive and often unnecessary, ordering MUST be scoped and explicit:

M.1.4.1 The bus MUST guarantee *per-key ordering* for a declared ordering key (e.g., `subject_id`, `docket_id`, `oar_id`, or `entity_id`) when a message type declares `ordering.required=true`.

M.1.4.2 If ordering is not guaranteed for a message type, the message type MUST declare `ordering.required=false`, and consumers MUST be designed as commutative/idempotent under reordering.

M.1.4.3 Where both are possible, the message type MUST declare which ordering key is normative and testable.

M.1.5 **Causality and traceability.** The bus MUST preserve causal linkage:

M.1.5.1 Every message MUST carry a trace context (see M.2) linking it to the originating artefacts (e.g., TRG, OAR, XPL, CRR, PR, DKT, STO, CPAR) as applicable.

M.1.5.2 Consumers MUST emit derived events with trace context that preserves parent-child relationships.

M.1.6 **Delivery receipts and backpressure.** The bus MUST provide a mechanism for:

M.1.6.1 Delivery acknowledgments (for replay control and auditability).

M.1.6.2 Backpressure signaling (to prevent silent drops under stress).

M.1.6.3 Dead-letter or quarantine routing for malformed or handling-violating messages.

M.1.7 **Idempotency contract.** Every message MUST include an `idempotency_key` with defined scope and deduplication expectations:

M.1.7.1 Consumers MUST treat repeated deliveries of the same `idempotency_key` as a no-op after the first effective processing, within a declared deduplication window.

M.1.7.2 Deduplication windows MUST be declared and MUST meet minimums for the relevant operational clocks (verification/remediation/retest/dispute), so that replay cannot force divergent outcomes.

M.1.7.3 Idempotency scope MUST be explicit: per-topic, per-entity, or global.

M.1.8 **Replay handling and retention.** The bus MUST support controlled replay with explicit safety constraints:

M.1.8.1 Replay MUST preserve original message identifiers, time bindings, and trace context.

M.1.8.2 Replayed messages MUST be distinguishable from first-delivery via a `replay_flag` and `replay_reason`.

M.1.8.3 Retention periods for replay MUST be declared per topic and MUST respect handling class constraints and lawful-basis matrices.

M.1.9 **Delivery guarantees and failure behavior.** For each topic/message type, the system MUST declare:

M.1.9.1 Target delivery semantics (at-least-once / effective-once).

M.1.9.2 Ordering requirement and key (if any).

M.1.9.3 Maximum tolerated delay and expiry (linked to clocks).

M.1.9.4 Failure behavior: retry policy, dead-letter behavior, escalation triggers.

M.1.10 **Degraded and offline operation.** The bus MUST support store-and-forward patterns:

M.1.10.1 Local buffering with integrity protection for disconnected or sovereign/air-gapped environments.

M.1.10.2 Deferred publication with preserved time-binding semantics (publish time vs event time MUST both be represented).

M.1.10.3 Deterministic catch-up behavior that does not create false freshness or permit out-of-scope reliance.

***

#### M.2 Message schema requirements (ontology bindings; handling markers; trace context)

M.2.1 **Purpose.** Message schemas are the semantic bridge that prevents “same word, different meaning” failures across profiles and vendors. Schemas MUST be machine-validated and MUST bind message meaning to the ontology fabric.

M.2.2 **Common envelope (mandatory).** Every inter-profile message MUST include a common envelope containing, at minimum:

M.2.2.1 `message_id` (globally unique).

M.2.2.2 `message_type` and `schema_version`.

M.2.2.3 `issuer_id` and authorization reference (role key or equivalent authorization proof pointer).

M.2.2.4 `created_time` (event creation time) and `published_time` (bus publication time), both time-bound.

M.2.2.5 `handling_class` (Public/Controlled/Restricted) and `disclosure_tier`.

M.2.2.6 `idempotency_key` and deduplication scope.

M.2.2.7 `trace_context` (M.2.6).

M.2.2.8 `ontology_bindings` (M.2.4).

M.2.3 **Payload constraints by handling class.** Payload content MUST comply with handling constraints:

M.2.3.1 Public messages MUST NOT contain direct identifiers that reveal restricted entities, sensitive locations, or personal data; where linkage is needed, use opaque identifiers and controlled lookup.

M.2.3.2 Controlled messages MAY contain sensitive operational metadata under declared lawful basis and access controls.

M.2.3.3 Restricted messages MUST be minimized, encrypted where applicable, and routed only to explicitly authorized recipients within approved zones.

M.2.4 **Ontology bindings (mandatory).** Every message MUST bind its semantic meaning to ontology terms:

M.2.4.1 `entity_refs`: canonical entity identifiers referenced by the message.

M.2.4.2 `event_refs`: canonical event identifiers where the message asserts/updates an event.

M.2.4.3 `relation_refs`: canonical relation identifiers where dependencies/ownership/exposure are asserted.

M.2.4.4 `term_set_id` or semantic version pointer for the ontology vocabulary used.

M.2.4.5 `provenance_pointer` for the underlying evidence candidates or transformations, where applicable.

M.2.5 **Uncertainty and confidence (mandatory where applicable).** Messages derived from probabilistic sources MUST declare:

M.2.5.1 Confidence bands, uncertainty measures, and source-class weighting summary.

M.2.5.2 Whether the message is an observation, hypothesis, determination, or correction.

M.2.6 **Trace context (mandatory).** Trace context MUST provide end-to-end linkability:

M.2.6.1 Parent artefact pointers (e.g., `trg_id`, `oar_id`, `xpl_id`, `crr_id`, `pr_id`, `dkt_id`, `sto_id`, `cpar_id`) as applicable.

M.2.6.2 A trace identifier that enables reconstructing the obligation→check→proof→docket chain without accessing controlled evidence by default.

M.2.6.3 A rule that derived messages MUST preserve and extend the trace context, never overwrite it.

M.2.7 **Schema validation and canonicalization.** Messages MUST be:

M.2.7.1 Valid against declared schemas.

M.2.7.2 Canonicalized for signing/verification (stable field ordering, normalization rules).

M.2.7.3 Rejectable deterministically (malformed messages MUST be quarantined, not partially processed).

***

#### M.3 Topic governance and least privilege rules

M.3.1 **Purpose.** Topic governance prevents profile messaging from becoming a covert execution channel, a metadata leakage vector, or a capture surface. Governance is a security control, not an administrative preference.

M.3.2 **Topic taxonomy (recommended baseline).** Topics SHOULD be partitioned by purpose and handling class, such as:

M.3.2.1 Trigger evaluation inputs (observations, anomaly signals).

M.3.2.2 Obligation events (OAR issued/updated/expired).

M.3.2.3 Check and runtime outcomes (CRR completed, drift alerts).

M.3.2.4 Proof events (PR issued, STO updated).

M.3.2.5 Docket workflow events (DKT opened/updated/closed).

M.3.2.6 Correction and dispute events (COR proposed, dispute hold, resolution published).

M.3.3 **Publish/subscribe authorization (mandatory).** Each topic MUST declare:

M.3.3.1 Allowed publishers (role categories and service identities).

M.3.3.2 Allowed subscribers (role categories and service identities).

M.3.3.3 Whether cross-organization subscription is permitted (see M.4).

M.3.3.4 Required handling class and disclosure tier constraints.

M.3.4 **Least privilege rule.** Authorization MUST be least privilege:

M.3.4.1 Components MUST subscribe only to topics required for their declared functions.

M.3.4.2 Human users MUST access messages via the control plane with role-based views and handling enforcement, not raw bus access by default.

M.3.5 **No execution creep rule.** Topics MUST NOT carry instructions that effect regulated actions:

M.3.5.1 Messages MAY request verification, remediation, retest, escalation, or docketing.

M.3.5.2 Messages MUST NOT instruct custody movement, underwriting decisions, market placements, claims payouts, or other regulated execution actions.

M.3.6 **Rate limits and abuse controls.** Topic governance MUST include:

M.3.6.1 Rate limits by publisher identity.

M.3.6.2 Quotas by handling class to prevent Restricted-channel flooding.

M.3.6.3 Automated quarantine triggers for suspicious bursts or repeated schema violations.

M.3.7 **Governance logging.** All changes to topic policies MUST be recorded as governed actions (CPAR), including approvals, effective times, and rollback procedures.

***

#### M.4 Cross-org messaging constraints (federation boundaries)

M.4.1 **Purpose.** Federation requires interoperability without centralizing trust or leaking sovereign data. Cross-org messaging MUST respect sovereign zones, handling classes, and declared reliance semantics.

M.4.2 **Federation boundary rule.** Cross-organization message flows MUST cross an explicit federation boundary component that enforces:

M.4.2.1 Handling class policy (no Restricted content crossing unless explicitly authorized and lawful).

M.4.2.2 Topic allowlists (only declared federatable topics may cross).

M.4.2.3 Identity and authorization checks (role keys, issuer authorization proofs).

M.4.2.4 Metadata minimization (strip or transform non-essential metadata).

M.4.3 **Receipt-first federation.** By default, cross-org interoperability SHOULD prefer:

M.4.3.1 Proof events (PR/STO references) rather than raw evidence or detailed telemetry.

M.4.3.2 Docket summaries suitable for the declared handling class, rather than internal ticket content.

M.4.4 **Selective disclosure workflows.** Where controlled evidence exchange is necessary:

M.4.4.1 Exchanges MUST be mediated by controlled disclosure workflows, not ad-hoc bus payloads.

M.4.4.2 Access logs and lawful basis matrices MUST be satisfied.

M.4.5 **Anti-equivocation and split-view considerations.** Cross-org flows MUST not enable inconsistent views:

M.4.5.1 Where transparency checkpoints are exchanged, checkpoint identities and consistency proofs MUST be verifiable.

M.4.5.2 Federation components MUST record observed checkpoints and anomalies for audit.

M.4.6 **Air-gapped and delayed sync mode.** For sovereign/air-gapped deployments:

M.4.6.1 Cross-org messages MUST support delayed export with preserved time binding.

M.4.6.2 The system MUST declare reliance constraints when messages are stale or delayed.

***

#### M.5 Observability requirements for message flows

M.5.1 **Purpose.** Messaging is a primary source of operational truth. Observability must enable reconstruction of obligation and proof chains, detection of drift and abuse, and audit under degraded conditions—without leaking sensitive metadata.

M.5.2 **Minimum telemetry (mandatory).** The messaging layer MUST emit, at minimum:

M.5.2.1 Publish and delivery timestamps (creation vs publish vs receive).

M.5.2.2 Publisher identity (role marker + authorization pointer) and subscriber group identifiers.

M.5.2.3 Message type, schema version, handling class, and disclosure tier.

M.5.2.4 Trace context identifiers linking to OAR/XPL/CRR/PR/DKT/STO/CPAR as applicable.

M.5.2.5 Delivery outcome (acked, retried, dead-lettered, quarantined) and reason codes.

M.5.3 **Handling-aware logging.** Observability logs MUST be handling-aware:

M.5.3.1 Public logs MUST not reveal Restricted routing patterns, subscriber identities, or sensitive topology.

M.5.3.2 Controlled logs MAY contain operational routing details under access control and retention limits.

M.5.3.3 Restricted logs MUST be minimized and require explicit authorization to access.

M.5.4 **Anomaly detection hooks.** The bus SHOULD provide hooks for:

M.5.4.1 Unexpected publisher detection.

M.5.4.2 Schema violation rates and repeated failures.

M.5.4.3 Replay anomalies and deduplication overflow.

M.5.4.5 Burst and flood patterns suggesting coercion, poisoning, or denial strategies.

M.5.5 **Audit reconstruction.** The system MUST be capable of reconstructing:

M.5.5.1 The sequence of inter-profile messages that led to OAR issuance, check execution, receipt issuance, and docket actions.

M.5.5.2 The points where overrides or exceptions were invoked (via CPAR linkage).

***

#### M.6 Interop tests (cross-vendor, ordering, replay, failure scenarios)

M.6.1 **Purpose.** Interop tests ensure that different implementations of the event bus and consumers can still achieve equivalent operational outcomes. These tests are conformance-critical for real-time interoperability.

M.6.2 **Cross-vendor interop baseline.** The test suite MUST include scenarios where:

M.6.2.1 One implementation publishes and another consumes, and vice versa.

M.6.2.2 Schema versions differ within permitted compatibility ranges.

M.6.2.3 Handling classes are enforced consistently across implementations.

M.6.3 **Ordering tests (mandatory where ordering.required=true).** Tests MUST validate:

M.6.3.1 Per-key ordering preserved under load.

M.6.3.2 Safe behavior under partial ordering (multiple keys interleaving).

M.6.3.3 Deterministic consumer outcomes when ordering is guaranteed.

M.6.4 **Replay tests (mandatory).** Tests MUST validate:

M.6.4.1 Duplicate deliveries do not create duplicate obligations, duplicate receipts, or divergent dockets.

M.6.4.2 Replayed messages preserve time binding and are marked as replayed.

M.6.4.3 Deduplication windows match declared policies and clock constraints.

M.6.5 **Failure and partition tests (mandatory).** Tests MUST validate:

M.6.5.1 Broker outage and recovery without message loss beyond declared tolerances.

M.6.5.2 Network partition with store-and-forward behavior and deterministic catch-up.

M.6.5.3 Dead-letter and quarantine behavior for schema violations and handling violations.

M.6.5.4 Backpressure under surge conditions and non-silent drop enforcement.

M.6.6 **Security abuse tests (mandatory).** Tests MUST validate:

M.6.6.1 Unauthorized publish attempts are rejected and logged.

M.6.6.2 Unauthorized subscribe attempts do not receive messages and are logged.

M.6.6.3 Metadata minimization holds (no leakage across handling classes).

M.6.6.4 Poisoning attempts via message spam trigger quarantine/rate-limiting behavior.

M.6.7 **Acceptance criteria.** An implementation is inter-profile-communication conformant only if:

M.6.7.1 It passes all mandatory ordering/replay/failure/security vectors relevant to the message types it supports.

M.6.7.2 It produces deterministic effective outcomes for obligation attachment and proof issuance under declared semantics.

M.6.7.3 It enforces handling classes, lawful-basis constraints, and federation boundary rules as specified in this Annex.


---

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