# Annex K

#### K.1 SAC doctrine and non-goals (no execution creep; assurance-only)

K.1.1 **Purpose.** This Annex specifies the Standards-as-Code (SAC) language layer used by NXOSI to express, compile, evaluate, and prove standards obligations in a runtime-executable form. SAC exists to make obligations *machine-attachable*, *testable*, *portable*, and *correctionable*.

K.1.2 **Assurance-only doctrine.** SAC MUST operate strictly within the assurance perimeter:

K.1.2.1 SAC MAY evaluate policies, compute determinations, generate obligations, drive checks, and produce proof receipts.

K.1.2.2 SAC MUST NOT execute regulated actions (custody, underwriting, placement, market operation, claims execution, settlement, supervisory acts). It may route determinations and generate dockets for external systems.

K.1.2.3 SAC MUST NOT embed hidden discretion that changes obligations without recorded artefacts and review gates; “dynamic” is permitted only when deterministically tied to declared inputs, declared uncertainty rules, and published versioned policy artefacts.

K.1.3 **Non-goals.** SAC is not intended to be:

K.1.3.1 A general-purpose programming language.

K.1.3.2 A replacement for enterprise workflow engines or SOAR/ITSM systems.

K.1.3.3 A secret policy engine that bypasses governance; every policy change MUST be recorded, versioned, and status-governed.

K.1.3.4 A central surveillance mechanism; SAC must be handling-aware and disclosure-minimizing by default.

K.1.4 **Core invariants.** SAC MUST preserve the following invariants across all implementations:

K.1.4.1 **Determinism under declared semantics:** same declared inputs → same outputs.

K.1.4.2 **No silent edits:** every deployed policy revision has an explicit status/supersession trail.

K.1.4.3 **Evidence-first:** every consequential evaluation emits linkable evidence artefacts (CRR/PR/CPAR as applicable).

K.1.4.4 **Sovereignty by default:** receipts are portable; sensitive evidence stays in-zone.

***

#### K.2 DSL and/or IR definition (syntax, typing, constraints)

K.2.1 **Two-layer definition.** SAC MAY be implemented as:

K.2.1.1 A human-facing **DSL** for authoring, plus a canonical **Intermediate Representation (IR)** used for compilation, verification, and execution; or

K.2.1.2 An **IR-only** system with constrained authoring templates that generate the IR.

In both cases, the IR is normative for conformance.

K.2.2 **Normative IR properties.** The SAC IR MUST be:

K.2.2.1 **Canonicalizable** (a deterministic serialization exists that yields stable digests).

K.2.2.2 **Typed** (well-defined types with explicit conversions; no implicit coercions that change meaning).

K.2.2.3 **Side-effect constrained** (no unbounded I/O; no hidden network calls; all external inputs declared).

K.2.2.4 **Handling-aware** (every value and output channel carries handling-class constraints and disclosure ceilings).

K.2.2.5 **Versioned** (IR schema version + policy semantic version).

K.2.3 **Core IR constructs (minimum set).** The IR MUST support at minimum:

K.2.3.1 **Declarations:** policy metadata, scope, jurisdiction/overlay applicability, reliance tier ceilings.

K.2.3.2 **Bindings:** ontology term references (entity types, event types, relations), with ontology semantic version pointers.

K.2.3.3 **Predicates:** boolean logic over declared inputs, including uncertainty-aware predicates (see K.3).

K.2.3.4 **Obligations:** creation of TRG/OAR outputs with clocks, scope bindings, and handling defaults.

K.2.3.5 **Control invocations:** references to controls/tests and enforcement points.

K.2.3.6 **Evidence emissions:** CRR/PR/CPAR linkage requirements.

K.2.3.7 **Status semantics hooks:** references to STO requirements for supersession, revocation, scope narrowing.

K.2.4 **Typing requirements.** The type system MUST include:

K.2.4.1 **Primitive types:** boolean, integer, decimal, string, timestamp, duration, enum, bytes/digest.

K.2.4.2 **Domain types:** entity-id, event-id, jurisdiction-id, profile-id, control-id, risk-class, handling-class, reliance-tier, crypto-suite-id.

K.2.4.3 **Structured types:** records/objects with required/optional fields and schema references.

K.2.4.4 **Collections:** lists/sets/maps with deterministic iteration guarantees where relevant (see K.3).

K.2.5 **Authoring constraints (safety by construction).** The DSL/authoring layer MUST prevent:

K.2.5.1 Unbounded loops or recursion.

K.2.5.2 Non-deterministic functions without explicit declared uncertainty semantics.

K.2.5.3 Access to Controlled/Restricted inputs from a Public output channel.

K.2.5.4 Policy statements that exceed the permitted reliance tier for their evidence strength.

K.2.6 **External input declaration.** Every external data source used in SAC evaluation MUST be declared with:

K.2.6.1 Source identifier and trust constraints.

K.2.6.2 Freshness window and time-binding rules.

K.2.6.3 Provenance requirements for derived values.

K.2.6.4 Handling class and disclosure ceilings.

***

#### K.3 Execution semantics (determinism; evaluation order; side-effect constraints)

K.3.1 **Deterministic evaluation model.** SAC execution MUST be deterministic under the following rule:

K.3.1.1 For any evaluation, the inputs are (i) policy version digest, (ii) ontology snapshot digest and semantic version, (iii) declared data inputs and their digests, (iv) parameter bindings, (v) time source claim, and (vi) compiler/runtime versions.

K.3.1.2 The runtime MUST produce the same outputs (OAR/XPL directives, control invocations, evidence emissions) for identical inputs, except where declared uncertainty semantics explicitly allow bounded variability.

K.3.2 **Declared uncertainty semantics.** Where inputs are probabilistic (e.g., fused signals, anomaly scores), the runtime MUST:

K.3.2.1 Require uncertainty declarations (confidence bands, source provenance, scoring method identifiers).

K.3.2.2 Use threshold semantics that are explicit and testable (e.g., “trigger when confidence ≥ 0.90 for ≥ 15 minutes”).

K.3.2.3 Preserve determinism by evaluating against declared numeric values and bounds, not by re-running stochastic inference inside SAC.

K.3.3 **Evaluation order and concurrency.**

K.3.3.1 The IR MUST define a deterministic evaluation order, or define commutative operations where order is irrelevant.

K.3.3.2 When multiple rules apply, conflict resolution MUST be deterministic and declared (e.g., precedence by profile stack order and overlay algebra).

K.3.3.3 Any parallel evaluation MUST yield equivalent outputs to sequential evaluation, proven via canonicalization rules.

K.3.4 **Side-effect constraints.**

K.3.4.1 SAC evaluation MUST be functionally pure with respect to external state changes; it may emit artefacts and requests, but MUST NOT mutate external systems directly.

K.3.4.2 All “actions” are represented as **routeable outputs** (e.g., DO, docket instructions, check requests) and recorded as CPAR when approved/executed by operators.

K.3.4.3 External calls (if any) MUST be routed through declared adapters with strict allowlists and evidence emission.

K.3.5 **Time semantics.**

K.3.5.1 SAC MUST use a declared trusted time source claim, recorded in outputs.

K.3.5.2 Freshness windows MUST be enforced for time-sensitive inputs; stale inputs MUST cause explicit degraded/inconclusive outcomes, not silent acceptance.

K.3.6 **Handling-aware execution.** At runtime:

K.3.6.1 The handling class of any derived value MUST be at least as restrictive as the most restrictive input contributing to it, unless a governed redaction/summarization function is invoked.

K.3.6.2 Public outputs MUST NOT depend on Controlled/Restricted inputs unless explicitly transformed via approved selective disclosure patterns and recorded as such.

***

#### K.4 Policy lifecycle (authoring, simulation, deploy, rollback, freeze, supersession)

K.4.1 **Lifecycle stages.** SAC policies MUST move through a governed lifecycle:

K.4.1.1 Authoring (draft with linting and constraints checks).

K.4.1.2 Simulation (pre-deploy evaluation against recorded scenarios and gold vectors).

K.4.1.3 Review/approval (separation-of-duties gates; recorded approvals).

K.4.1.4 Deploy (signed release; activation with time-bound rollout controls).

K.4.1.5 Monitor (drift, exceptions, and outcomes tracked with clocks).

K.4.1.6 Rollback (revert to prior version with explicit status record).

K.4.1.7 Freeze (emergency stop-the-line for defined risk scenarios).

K.4.1.8 Supersession (publish successor version with migration/equivalence notes and status semantics).

K.4.2 **Simulation requirements.** Before deploy, the system MUST produce:

K.4.2.1 Simulation report (scenarios, expected outputs, deviations).

K.4.2.2 Blast radius estimation (affected profiles/obligations/controls).

K.4.2.3 Compatibility classification (breaking vs non-breaking) with explicit justification.

K.4.3 **Approval and duty separation.** Deploy/rollback/freeze MUST require:

K.4.3.1 Separation-of-duties (author ≠ approver for defined risk classes).

K.4.3.2 Multi-party approval for emergency actions above defined thresholds.

K.4.3.3 CPAR emission for each lifecycle action with linkage to the affected policy version.

K.4.4 **Rollout controls.** Deploy MUST support:

K.4.4.1 Staging and canary segments.

K.4.4.2 Time-bounded rollout windows.

K.4.4.3 Automatic rollback triggers on defined failure conditions.

K.4.5 **Freeze controls.** Freeze MUST:

K.4.5.1 Halt further policy changes and/or policy evaluation where required.

K.4.5.2 Emit a freeze CPAR with scope, duration, and required post-incident review clock.

K.4.6 **Supersession discipline.** Supersession MUST:

K.4.6.1 Publish an STO describing the supersession and permitted reliance transitions.

K.4.6.2 Include migration notes and equivalence tests (or declare non-equivalence).

K.4.6.3 Maintain verifiability of historical proofs under their original policy version and status state.

***

#### K.5 Equivalence, regression, and semantic drift testing

K.5.1 **Equivalence purpose.** Equivalence testing ensures that changes do not silently alter meaning, and that different runtimes/compilers can interoperate.

K.5.2 **Required equivalence tests.** For non-breaking releases, the publisher MUST provide:

K.5.2.1 Rule-level equivalence tests showing identical outputs for the defined scenario set.

K.5.2.2 Artefact-level equivalence tests showing identical OAR/XPL generation semantics.

K.5.2.3 Verification equivalence tests for receipts and status behaviors.

K.5.3 **Regression testing.** Every release MUST run:

K.5.3.1 Gold vectors (expected pass/fail outputs).

K.5.3.2 Negative tests (malformed inputs, stale time bindings, revoked statuses).

K.5.3.3 Adversarial tests appropriate to the profile class.

K.5.4 **Semantic drift detection.** The lifecycle MUST include:

K.5.4.1 Ontology semantic regression tests (term meaning changes).

K.5.4.2 Policy semantic regression tests (output distributions, obligation attachment changes).

K.5.4.3 Drift reports bound to specific versions and published with status semantics.

K.5.5 **Determinism regression.** Releases MUST prove determinism under repeated runs, including under degraded modes and partial data conditions.

***

#### K.6 Safety guardrails (linting, sandboxing, rate limits, scoped permissions)

K.6.1 **Linting and constraints.** Authoring MUST include:

K.6.1.1 Static checks for determinism violations.

K.6.1.2 Checks for undefined scope, missing clocks, or missing handling markers.

K.6.1.3 Checks for prohibited inferences (e.g., supervisory conclusions under low reliance tiers).

K.6.2 **Sandboxing.** Runtime evaluation MUST execute in a sandbox that:

K.6.2.1 Restricts network access to declared adapters only.

K.6.2.2 Restricts file system access to declared evidence channels only.

K.6.2.3 Prevents access to secrets except via authorized key services.

K.6.3 **Rate limits and abuse prevention.** The runtime MUST implement:

K.6.3.1 Rule evaluation rate limits to prevent denial-of-service.

K.6.3.2 Adapter call quotas to prevent exfiltration via repeated queries.

K.6.3.3 Backpressure behavior under overload, with explicit degraded outputs.

K.6.4 **Scoped permissions.** Policies MUST declare the permissions they require:

K.6.4.1 Which ontology namespaces can be read/written (writes typically via correction paths only).

K.6.4.2 Which enforcement points can be invoked for checks.

K.6.4.3 Which output channels and handling classes are permitted.

K.6.5 **Override constraints.** Any override/break-glass action MUST be:

K.6.5.1 Time-bounded.

K.6.5.2 Logged as CPAR.

K.6.5.3 Subject to post-incident review clocks and potential status changes.

***

#### K.7 Status object integration (no silent edits; migration notes)

K.7.1 **Status integration requirement.** Every deployed SAC policy version MUST have:

K.7.1.1 A status pointer field enabling revocation, supersession, scope narrowing, and validity windows.

K.7.1.2 A published supersession trail when replaced.

K.7.2 **No silent edits enforcement.** Implementations MUST ensure:

K.7.2.1 Policy digests are immutable once published.

K.7.2.2 Any correction or change results in a new version and an STO.

K.7.2.3 Historical proofs remain verifiable against their original policy version and status state.

K.7.3 **Migration notes requirements.** When superseding a policy, migration notes MUST state:

K.7.3.1 Whether semantics are equivalent, narrowed, broadened, or altered.

K.7.3.2 Which obligations/controls/tests changed and why.

K.7.3.3 How reliance should be interpreted across the transition.

K.7.4 **Scope narrowing support.** Where policy changes reduce scope (e.g., jurisdiction carve-outs), scope narrowing SHOULD be used to preserve reliance where possible rather than blanket revocation.

***

#### K.8 Runtime conformance surfaces and required tests

K.8.1 **Conformance surfaces.** A SAC runtime is conformant only if it passes tests for:

K.8.1.1 IR parsing and canonicalization (stable digests).

K.8.1.2 Deterministic evaluation and declared uncertainty handling.

K.8.1.3 Handling-aware execution and disclosure ceilings.

K.8.1.4 Lifecycle controls (simulation gates, deploy/rollback/freeze, CPAR emission).

K.8.1.5 Status integration (revocation/supersession/scope narrowing semantics).

K.8.1.6 Inter-profile communication semantics (ordering/idempotency/replay protection), when supported.

K.8.2 **Required test categories.** The required suite MUST include:

K.8.2.1 Gold vectors validating expected OAR/XPL outputs.

K.8.2.2 Negative tests for malformed IR, missing clocks, missing handling markers, stale time sources.

K.8.2.3 Adversarial tests for privilege escalation attempts and adapter misuse.

K.8.2.4 Drift tests for ontology version changes and policy semantic changes.

K.8.2.5 Degraded-mode tests (offline inputs, partial data, transparency unavailability) ensuring explicit degraded outputs and correct reliance constraints.

K.8.3 **Evidence outputs for conformance.** Conformance execution MUST emit signed, versioned reports and supporting receipts suitable for independent verification, with handling-aware publication rules.


---

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