# Annex J

#### J.1 Input formats and normative extraction rules

J.1.1 **Purpose.** This Annex defines the normative rules by which the NXOSI Profile Compiler ingests source standards/policies and produces (i) atomic controls, (ii) executable tests, (iii) deterministic execution plans, and (iv) signed profile packages. These rules are normative for “NXOSI-compliant” compilers.

J.1.2 **Accepted input classes.** The compiler MUST accept, at minimum, the following input artefact classes:

J.1.2.1 **Policy/Standard Artefact (PSA).** The canonical machine-readable representation of policy intent, normative requirements, triggers, control mappings, and testability declarations.

J.1.2.2 **Normative source text.** Human-authored normative text MAY be ingested, but it MUST be mapped into PSA form before it is eligible to produce conformance-relevant outputs. Any compiler claiming “normative extraction” MUST output an explicit extraction report and MUST NOT silently infer obligations.

J.1.2.3 **Profile and overlay artefacts.** The compiler MUST ingest Signed Profile Packages (SPP), overlay packages, parameter sets, and dependency declarations.

J.1.2.4 **Ontology bindings.** The compiler MUST ingest ontology term bindings used for scope, event semantics, and trigger predicates, including ontology semantic version identifiers.

J.1.3 **Normative extraction constraints.** When extracting requirements from non-PSA inputs, the compiler MUST:

J.1.3.1 **Preserve normative modality.** Modal verbs and obligation strength (MUST/SHOULD/MAY) MUST be preserved, not guessed. Where the input is ambiguous, the compiler MUST either (i) emit an operability defect (Part 2 / Part 9), or (ii) mark the requirement as non-compilable until clarified.

J.1.3.2 **Enforce testability discipline.** Every extracted MUST MUST map to at least one testable control or be explicitly classified as “non-testable normative intent” with (i) an allowed reliance tier ceiling, and (ii) required compensating testable controls if reliance requires it.

J.1.3.3 **Declare scope and applicability.** Extracted requirements MUST carry explicit scope: subject entity class, jurisdiction/overlay applicability, time windows (if any), hazard classes (if any), and enforcement points.

J.1.3.4 **Emit extraction evidence.** For each extracted requirement, the compiler MUST output a trace record linking: source fragment reference → extracted requirement ID → control mapping → test mapping. This trace record is part of conformance evidence and MUST be signed.

J.1.4 **Deterministic parsing requirement.** Given identical inputs (including source artefact digests), the extraction results MUST be deterministic. Any heuristic or ML-assisted extraction MAY be used only if it produces deterministic, reviewable outputs and includes declared uncertainty fields and human approval gates prior to publication.

***

#### J.2 Control decomposition library and mapping constraints

J.2.1 **Purpose.** Control decomposition converts normative requirements into atomic, testable controls with explicit inputs, outputs, and pass/fail semantics. This makes standards executable and comparable across implementations.

J.2.2 **Control library requirement.** The compiler MUST use a declared control decomposition library that is:

J.2.2.1 **Versioned and signed** (no silent edits).

J.2.2.2 **Traceable** (each control template has an origin record and rationale).

J.2.2.3 **Constrained** (templates define required fields, permissible parameters, and forbidden ambiguity).

J.2.3 **Atomicity rules.** A generated control MUST be atomic enough that:

J.2.3.1 It has **one primary intent** (one “thing to verify”).

J.2.3.2 It has **explicit pass/fail criteria** (or an explicitly declared probabilistic allowance with thresholds and confidence bounds).

J.2.3.3 It identifies the **enforcement point(s)** where it can be evaluated.

J.2.3.4 It declares the **evidence expectation** (which CRR fields and which AEP references are expected).

J.2.4 **Mapping constraints (normative).** The compiler MUST enforce:

J.2.4.1 **One-to-many allowed, many-to-one constrained.** One requirement MAY map to multiple controls; multiple requirements MAY map to one control only if the control’s semantics satisfy all mapped requirements and the mapping includes an explicit equivalence justification.

J.2.4.2 **No strengthening by accident.** A mapping MUST NOT silently strengthen a SHOULD into a MUST, or add obligations not present in the requirement, unless done via an explicit profile overlay or operator policy layer with recorded rationale.

J.2.4.3 **No weakening by omission.** If a requirement cannot be mapped to testable controls, the compiler MUST emit an operability defect and constrain reliance tiers accordingly.

J.2.4.4 **Handling-aware decomposition.** Controls MUST carry handling class defaults and disclosure ceilings; controls that require sensitive inputs MUST default to Controlled/Restricted and MUST NOT require public disclosure to pass.

J.2.5 **Control input/output contracts.** Each control MUST define:

J.2.5.1 Required inputs (telemetry fields, attestations, configuration snapshots, logs).

J.2.5.2 Output structure (pass/fail, measured values, confidence bounds, and required linkage pointers).

J.2.5.3 Allowed data sources and source trust requirements (including provenance constraints).

J.2.6 **Attestation binding rules.** For controls above defined risk thresholds, the compiler MUST mark attestation as REQUIRED and bind the control to an appraisal policy reference (Annex H).

***

#### J.3 Test generation rules (gold vectors, negative tests)

J.3.1 **Purpose.** Tests operationalize controls into reproducible procedures and establish portability of outcomes. Tests are required for conformance; narrative descriptions are insufficient.

J.3.2 **Test generation requirements.** For each testable control, the compiler MUST generate or reference:

J.3.2.1 A **test procedure** (steps, inputs, evaluation logic).

J.3.2.2 **Pass/fail criteria** including thresholds, tolerances, and declared uncertainty rules.

J.3.2.3 **Evidence capture requirements** (CRR fields, telemetry pointers, linkage to PR/AEP/DKT).

J.3.2.4 **Failure mode semantics** (what constitutes “fail,” “inconclusive,” “degraded,” and required next actions).

J.3.3 **Gold vectors (mandatory).** Each profile release MUST include a minimal set of gold vectors:

J.3.3.1 Known-good cases that SHOULD pass.

J.3.3.2 Known-bad cases that MUST fail.

J.3.3.3 Boundary cases at thresholds to prove determinism and consistent treatment.

J.3.4 **Negative tests (mandatory).** The compiler MUST generate negative tests for:

J.3.4.1 Missing required fields.

J.3.4.2 Invalid signatures and unauthorized issuers.

J.3.4.3 Stale time bindings and replay attempts.

J.3.4.4 Mismatched profile hashes and incompatible versions.

J.3.4.5 Revoked or superseded status conditions.

J.3.5 **Adversarial tests (profile-dependent but required when applicable).** For profiles covering higher-risk domains, the compiler SHOULD include adversarial vectors such as:

J.3.5.1 Equivocation and split-view publication conditions (where proof infrastructure is involved).

J.3.5.2 Poisoned inputs and suspicious provenance chains (where ontology/provenance is involved).

J.3.5.3 Privilege escalation and override abuse patterns (where control plane actions are involved).

J.3.6 **Deterministic test execution.** Tests MUST be runnable deterministically given the same inputs and environment claims; any stochastic components MUST be explicitly declared and bounded, with required repeatability rules.

***

#### J.4 Overlay algebra application and conflict detection rules

J.4.1 **Purpose.** Overlay algebra prevents forks by composing base profiles with jurisdiction/sector/hazard overlays under explicit precedence rules and conflict resolution patterns.

J.4.2 **Overlay precedence (normative).** The compiler MUST apply overlays in an explicit, declared order, at minimum:

J.4.2.1 Base profile.

J.4.2.2 Sector profile(s).

J.4.2.3 Hazard overlay(s).

J.4.2.4 Regional overlay(s).

J.4.2.5 National overlay(s).

J.4.2.6 Operator policy overlay (if allowed by governance).

J.4.3 **Overlay operations.** Overlays MAY:

J.4.3.1 Narrow scope (reduce eligible entities/time/geography).

J.4.3.2 Tighten thresholds (more stringent parameters).

J.4.3.3 Add controls/tests (duty escalation).

J.4.3.4 Add handling constraints (move to more restrictive handling/disclosure).

J.4.3.5 Define carve-outs (explicit exceptions with conditions).

J.4.4 **Prohibited overlay operations (baseline).** Overlays MUST NOT:

J.4.4.1 Remove required artefact linkage semantics.

J.4.4.2 Disable “no silent edits” status discipline.

J.4.4.3 Weaken proof receipt minimum fields or permitted inference limits.

J.4.4.4 Break the ability to perform defined offline verification.

J.4.5 **Conflict detection (mandatory).** The compiler MUST detect and surface:

J.4.5.1 Direct conflicts (two controls with mutually exclusive requirements).

J.4.5.2 Parameter conflicts (incompatible thresholds/timers).

J.4.5.3 Semantic conflicts (same term bound to different ontology semantics without explicit mapping).

J.4.5.4 Handling conflicts (required disclosure exceeds handling ceiling).

J.4.6 **Conflict resolution outputs.** When conflicts are detected, the compiler MUST:

J.4.6.1 Produce a conflict report with affected requirements/controls/tests.

J.4.6.2 Apply an explicit resolution policy (override, carve-out, parameter narrowing, duty escalation) only if authorized by the overlay and governance rules.

J.4.6.3 If unresolved, fail compilation and emit an operability defect object, preventing issuance of an XPL for that composition.

***

#### J.5 Deterministic build requirements and equivalence tests

J.5.1 **Purpose.** Deterministic compilation is required for portability: different compilers should produce functionally equivalent outputs from the same inputs, and changes must be attributable.

J.5.2 **Deterministic build requirement.** Given identical inputs (PSA/SPP/overlays/parameters/ontology version) and the same compiler version, outputs MUST be byte-identical or must produce identical digests for canonical serialized forms.

J.5.3 **Build inputs lock.** The build MUST pin:

J.5.3.1 Compiler version and plugin set.

J.5.3.2 Control library version.

J.5.3.3 Ontology semantic version.

J.5.3.4 All dependency profile versions and overlay artefacts.

J.5.4 **Equivalence testing.** Where implementations differ (e.g., plugin variability), equivalence MUST be proven via:

J.5.4.1 A canonical IR digest for the compiled plan and control set.

J.5.4.2 A required equivalence test suite that verifies semantic invariants (same obligations, same pass/fail semantics, same linkage rules, same clocks).

J.5.4.3 A published equivalence note explaining any acceptable differences (performance/optimization only; not meaning).

J.5.5 **Breaking change rules.** If compilation outputs differ in a way that changes semantics, the compiler MUST:

J.5.5.1 Bump major versions where required.

J.5.5.2 Emit migration guidance.

J.5.5.3 Require status objects and supersession semantics for prior outputs.

***

#### J.6 Output packaging requirements (SPP/XPL/test suites)

J.6.1 **Purpose.** Compiler outputs must be portable, signed, and self-describing so that verifiers can validate without privileged access.

J.6.2 **Required outputs (baseline).** For a successful compilation, the compiler MUST produce:

J.6.2.1 **Signed Profile Package (SPP)** with dependencies, overlays applied, parameters bound, required tests referenced, enforcement points declared, and inter-profile communication declarations.

J.6.2.2 **Execution Plan (XPL)** bound to an OAR and ontology context snapshot, with deterministic execution graph, enforcement points mapping, dependency set, degraded mode behaviors, and failure escalation semantics.

J.6.2.3 **Test suite bundle** containing gold vectors, negative tests, and required verification procedures.

J.6.2.4 **Compilation report** including traceability mappings, conflict reports (if any), operability defect pointers (if any), and equivalence evidence.

J.6.3 **Packaging invariants.** Output bundles MUST include:

J.6.3.1 Unique identifiers and semantic versions.

J.6.3.2 Handling class markers per artefact.

J.6.3.3 Signatures, crypto suite identifiers, time binding.

J.6.3.4 Status pointer fields for later revocation/supersession.

J.6.4 **Portability requirement.** A relying party MUST be able to validate the SPP/XPL/test suite bundle with receipt-only artefacts for the defined reliance tier, and to request controlled evidence only where allowed.

***

#### J.7 Secure release requirements (SBOM/provenance/signatures)

J.7.1 **Purpose.** The compiler itself must “practice what NXOSI requires”: every release must be proof-carrying and supply-chain verifiable.

J.7.2 **Release bundle requirements.** Each compiler release and each compiled output bundle MUST include:

J.7.2.1 SBOM covering the compiler and relevant build tooling (per Annex I).

J.7.2.2 Provenance artefact for the build (per Annex I).

J.7.2.3 Signed manifests and checksums for all published artefacts.

J.7.2.4 Security advisories and patch clocks (when applicable).

J.7.3 **Key separation.** Signing keys for compiler releases MUST be separated from keys used for routine profile publication where feasible, with explicit emergency key policies.

J.7.4 **Dependency governance.** Compiler dependencies MUST be pinned; vulnerability response MUST be docketed with clocks and status semantics.

***

#### J.8 Compiler plugin governance and extension rules

J.8.1 **Purpose.** Extensions enable sector-specific mapping without fragmenting interoperability. Plugin governance ensures replaceable parts and conformance stability.

J.8.2 **Plugin model constraints.** Plugins MAY extend:

J.8.2.1 Parsers for specific normative source formats.

J.8.2.2 Control libraries for sector/hazard specifics.

J.8.2.3 Test vector generators for domain scenarios.

J.8.2.4 Overlay resolution helpers, provided they do not alter overlay algebra semantics.

J.8.3 **Prohibited plugin behaviors.** Plugins MUST NOT:

J.8.3.1 Change normative semantics of baseline artefacts without explicit versioned overlays.

J.8.3.2 Disable conflict detection or downgrade failures to warnings for baseline requirements.

J.8.3.3 Emit outputs that omit required linkage, handling markers, signatures, or status pointers.

J.8.4 **Plugin conformance requirements.** Any plugin used in a conformant build MUST be:

J.8.4.1 Versioned and signed.

J.8.4.2 Declared in the build manifest.

J.8.4.3 Covered by conformance tests demonstrating it preserves required semantics and determinism.

J.8.5 **Extension governance.** Plugins MUST be admitted via recorded governance decisions with:

J.8.5.1 Security review and threat model update.

J.8.5.2 COI/competition-safe participation checks for maintainers.

J.8.5.3 Release discipline (status/supersession; no silent edits).

J.8.6 **Ecosystem compatibility.** Where multiple plugins provide equivalent functionality, the ecosystem MUST converge on shared conformance vectors and equivalence tests so that outputs remain portable across implementations.


---

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