# Annex L #### L.1 Composition model (stacking, dependency resolution, precedence) L.1.1 **Purpose.** This Annex defines the normative rules by which Signed Profile Packages (SPPs) are composed into an executable profile stack, with overlays applied without forking the base standards. The objective is to make multi-jurisdiction, multi-sector obligations interoperable and verifiable at runtime, while preserving proof portability and correctionability. L.1.2 **Profile stack definition.** A *profile stack* is an ordered set of profiles, overlays, and parameters that yields a deterministic Execution Plan (XPL) and a deterministic set of conformance expectations (controls/tests/receipts). L.1.3 **Stacking order (normative).** Unless explicitly superseded by an overlay’s declared precedence rule, the canonical stacking order MUST be: L.1.3.1 Base baseline profiles (cross-sector minimums). L.1.3.2 Sector profiles (domain-specific obligations). L.1.3.3 Hazard overlays (event-class overlays that tighten/attach obligations under defined hazard conditions). L.1.3.4 Jurisdiction overlays (regional, then national, then local/operator policy constraints), applied as *narrowing overlays* by default. L.1.3.5 Operator policy overlays (organization-specific policies), applied last and prohibited from weakening mandated obligations unless explicitly permitted by higher-precedence overlays. L.1.4 **Dependency resolution.** Each SPP MUST declare: L.1.4.1 Direct dependencies (required base profiles, required hazard overlays, required ontology semantic versions). L.1.4.2 Compatibility ranges for dependencies (semantic version floors/ceilings). L.1.4.3 Conflicts (known incompatibilities) and required resolution strategy. L.1.4.4 Required conformance suites and receipt patterns expected from the composed stack. L.1.5 **Deterministic resolution rule.** The composition engine MUST be deterministic: L.1.5.1 Given the same set of SPPs, overlays, parameters, and ontology snapshot, it MUST produce the same ordered stack, conflict decisions, and XPL outputs. L.1.5.2 Any ambiguity MUST be resolved by declared precedence and conflict rules, never by runtime discretion. L.1.6 **Precedence sources.** Precedence is determined by: L.1.6.1 The canonical stacking order in L.1.3. L.1.6.2 Explicit overlay precedence declarations (only permitted where not prohibited by this Annex). L.1.6.3 Jurisdiction hierarchy rules (global baseline → regional overlay → national overlay → operator policy), subject to non-weakening constraints. L.1.7 **Non-weakening baseline.** Unless a higher-precedence authority explicitly allows relaxation, overlays MUST be *monotonic tightening*: L.1.7.1 They MAY add obligations, tighten thresholds, reduce permitted exceptions, shorten clocks, expand evidence requirements, or raise required reliance tiers. L.1.7.2 They MUST NOT remove mandatory baseline controls, weaken required integrity primitives, or broaden permitted inferences for lower evidence strength. L.1.8 **Composition output artefacts.** Composition MUST produce: L.1.8.1 A resolved profile manifest (ordered list with hashes, versions, and dependency closure). L.1.8.2 A conflict-resolution report (what conflicted, how resolved, and why). L.1.8.3 Parameter binding report (final parameter values, origin, and precedence). L.1.8.4 An XPL determinism digest and conformance expectations list. *** #### L.2 Conflict taxonomy (hard conflicts, soft conflicts, parameter conflicts) L.2.1 **Purpose.** Conflict taxonomy exists to ensure predictable outcomes, prevent silent weakening, and enable test-driven interoperability across implementations. L.2.2 **Hard conflicts (non-composable).** A *hard conflict* exists when: L.2.2.1 Two profiles require mutually exclusive behaviors at the same enforcement point with no declared resolution mechanism. L.2.2.2 Two profiles define incompatible semantics for the same control identifier without an explicit supersession relationship. L.2.2.3 An overlay attempts to weaken a non-weakening baseline requirement (see L.1.7) without explicit authorization. L.2.2.4 A dependency compatibility range is violated (e.g., required ontology semantic version not satisfied). L.2.2.5 Handling class constraints are violated (e.g., a Public artefact would require Controlled/Restricted content). L.2.3 **Soft conflicts (composable with declared choice).** A *soft conflict* exists when: L.2.3.1 Two profiles express different acceptable methods to meet the same obligation, and both are valid under a declared selection rule. L.2.3.2 Two controls overlap in scope but can be satisfied concurrently with additive checks. L.2.3.3 Two profiles define different clocks for similar obligations, and the stricter clock can be chosen without breaking the other. L.2.4 **Parameter conflicts (resolvable by precedence).** A *parameter conflict* exists when: L.2.4.1 Profiles specify different parameter values for a shared control (thresholds, timers, geographic scope, risk class). L.2.4.2 Overlays require narrower parameter ranges than the base profile. L.2.4.3 Multiple overlays define values and precedence must be applied. L.2.5 **Conflict reporting requirements.** Every conflict MUST be recorded in the composition report: L.2.5.1 Conflict type (hard/soft/parameter). L.2.5.2 Affected controls/tests/artefacts. L.2.5.3 Resolution mechanism and precedence rationale. L.2.5.4 Resulting obligations and impact on proofs/reliance. *** #### L.3 Resolution mechanisms (override, narrowing, carve-outs, escalation) L.3.1 **Resolution principles.** Resolution MUST be: L.3.1.1 Deterministic and reproducible. L.3.1.2 Monotonic (non-weakening) unless explicitly authorized. L.3.1.3 Evidence-preserving (do not create reliance claims stronger than evidence allows). L.3.1.4 Correctionable (resolution can be superseded with explicit status objects). L.3.2 **Override (explicit replacement).** An *override* replaces a requirement or control with a higher-precedence one. Overrides: L.3.2.1 MUST declare what is overridden (identifier and semantic version). L.3.2.2 MUST include migration notes describing equivalence or non-equivalence. L.3.2.3 MUST NOT remove required integrity primitives unless authorized by an explicitly higher authority. L.3.3 **Narrowing (monotonic tightening).** *Narrowing* is the default resolution mechanism and includes: L.3.3.1 Tightening thresholds (e.g., stricter anomaly score thresholds). L.3.3.2 Shortening clocks (verification, remediation, retest, dispute windows). L.3.3.3 Restricting permitted exceptions/waivers. L.3.3.4 Increasing evidence requirements or attestation tiers. L.3.4 **Carve-outs (scoped exceptions).** A *carve-out* excludes a defined scope slice from an obligation due to lawful basis or jurisdiction constraints. Carve-outs: L.3.4.1 MUST be explicit and machine-readable (entity set, geography, time window, purpose). L.3.4.2 MUST preserve proof portability by producing receipts that clearly indicate the excluded scope. L.3.4.3 MUST NOT be used to evade baseline obligations outside the carved scope. L.3.5 **Escalation (raise duty and/or reliance tier).** *Escalation* resolves ambiguity by requiring stronger assurance: L.3.5.1 Raise required attestation tier for the affected controls. L.3.5.2 Raise required EQL or conformance level for permitted reliance. L.3.5.3 Require additional controls (compensating controls) when two standards differ. L.3.6 **Soft conflict selection.** Where multiple valid methods exist: L.3.6.1 The selection rule MUST be declared in the SPP or overlay (e.g., “choose stricter”, “choose least privilege”, “choose lowest disclosure”, “choose maximum portability”). L.3.6.2 If selection is context-dependent, the context predicates MUST be declared and testable. L.3.7 **Failure on hard conflicts.** When a hard conflict remains unresolved: L.3.7.1 Composition MUST fail and MUST NOT produce an XPL for the conflicting portion. L.3.7.2 The system MUST emit a docket entry and a conflict artefact suitable for correction workflow. *** #### L.4 Overlay types (global baseline; sector; hazard; national/regional jurisdiction overlays) L.4.1 **Overlay definition.** An overlay is a profile artifact that modifies or constrains a base stack through declared resolution mechanisms, without forking the underlying baseline identifiers and semantics. L.4.2 **Global baseline overlays.** These define cross-sector minimums intended to be stable and portable. They: L.4.2.1 MUST be non-weakening for any downstream overlays unless explicitly stated by global authority. L.4.2.2 SHOULD minimize jurisdiction-specific assumptions. L.4.3 **Sector overlays.** These tailor obligations for a domain (finance, critical infrastructure, AI/agentic, supply chain): L.4.3.1 MUST declare sector-specific entity models and ontology bindings. L.4.3.2 MUST declare enforcement-point expectations typical for the sector. L.4.3.3 SHOULD include sector-specific conformance vectors and adversarial tests. L.4.4 **Hazard overlays.** These activate under defined hazard events: L.4.4.1 MUST bind triggers to ontology event types and declared uncertainty rules. L.4.4.2 MUST specify clock changes (e.g., shorten remediation, impose retest cadence). L.4.4.3 MUST specify degraded-mode behaviors where hazards degrade telemetry/connectivity. L.4.5 **Jurisdiction overlays.** These encode lawful basis and disclosure constraints: L.4.5.1 Regional overlays apply cross-border portability and supervisory expectations. L.4.5.2 National overlays apply local lawful basis, retention, critical entity definitions, and restricted disclosure rules. L.4.5.3 Jurisdiction overlays MUST prefer carve-outs and handling constraints over semantic rewrites. L.4.6 **Overlay metadata requirements.** Every overlay MUST declare: L.4.6.1 Authority and applicability (jurisdiction identifiers, sector identifiers, time validity). L.4.6.2 Precedence and non-weakening posture. L.4.6.3 Handling class defaults and disclosure ceilings. L.4.6.4 Compatibility constraints and deprecation timelines. *** #### L.5 Proof portability rules under overlays L.5.1 **Portability objective.** Proof receipts MUST remain verifiable across jurisdictions and overlays without requiring re-audit, while accurately expressing scope and limitations. L.5.2 **Receipt binding requirements under overlays.** Every Proof Receipt (PR) MUST bind: L.5.2.1 The resolved profile manifest digest (including overlay closure). L.5.2.2 The jurisdiction applicability set (what overlays applied and why). L.5.2.3 The scope binding (entity set, geography, time window) and any carve-outs. L.5.2.4 The declared reliance tier and permitted inference constraints. L.5.3 **Overlay transparency without leakage.** Public-safe verification MUST be possible without revealing sensitive jurisdiction details beyond what is necessary: L.5.3.1 The receipt MAY include overlay identifiers and digests without revealing Controlled/Restricted overlay contents. L.5.3.2 Where overlays are Controlled/Restricted, the receipt MUST still permit validation of inclusion and status, and MUST clearly state the reliance ceiling for public verifiers. L.5.4 **Cross-overlay verification rules.** A relying party validating a receipt under a different overlay set MUST: L.5.4.1 Verify the receipt against the issuer’s declared overlay closure. L.5.4.2 Determine whether the relying party’s local overlay requirements are satisfied, using composition equivalence rules and published compatibility notes. L.5.4.3 Where equivalence cannot be established, require additional receipts or treat the receipt as informational only, per reliance tier. L.5.5 **No portability by misrepresentation.** Overlays MUST NOT “rename” obligations to appear compliant. If semantics differ, supersession/migration notes MUST be explicit, and receipts MUST reflect the applied semantics. L.5.6 **Status and correction portability.** Status objects for overlays and profiles MUST be resolvable: L.5.6.1 Offline via cached snapshots where supported. L.5.6.2 Online via status endpoints, including supersession and scope narrowing semantics. L.5.7 **Evidence stays sovereign.** Overlay rules MUST not force cross-border evidence export: L.5.7.1 Receipts travel. L.5.7.2 Evidence packs remain in sovereign zones with controlled disclosure workflows. *** #### L.6 Composition conformance tests (gold vectors and regression lock) L.6.1 **Purpose.** Composition conformance tests ensure that different compilers and runtimes produce equivalent composition outcomes, preserving interoperability across vendors and deployments. L.6.2 **Gold vectors (mandatory).** The test suite MUST include gold vectors for: L.6.2.1 Canonical stacking order resolution across base/sector/hazard/jurisdiction/operator layers. L.6.2.2 Dependency closure resolution (including compatible version selection). L.6.2.3 Parameter precedence (including narrowing and stricter-clock selection). L.6.2.4 Carve-out semantics (scope exclusions correctly represented in outputs). L.6.2.5 Deterministic XPL generation from an identical resolved manifest. L.6.3 **Negative tests (mandatory).** The suite MUST include: L.6.3.1 Hard conflict detection (mutually exclusive controls). L.6.3.2 Prohibited weakening attempt detection (overlay tries to relax baseline). L.6.3.3 Handling constraint violation detection (Public output depends on Restricted input without selective disclosure). L.6.3.4 Incompatible dependency range detection. L.6.4 **Regression lock.** Every release of the composition engine MUST: L.6.4.1 Re-run the full vector set. L.6.4.2 Emit signed conformance reports with manifest digests and outcome hashes. L.6.4.3 Publish compatibility notes when outcomes differ, and label the change as breaking or non-breaking. L.6.5 **Cross-implementation interop tests.** Plugfest-style tests SHOULD require: L.6.5.1 Multiple independent implementations composing the same input set. L.6.5.2 Bit-for-bit agreement on resolved manifest digests and conflict decisions (or formally equivalent results under canonicalization rules). L.6.6 **Acceptance criteria.** An implementation is composition-conformant only if: L.6.6.1 It passes all mandatory gold and negative vectors. L.6.6.2 It produces deterministic composition artefacts and reports. L.6.6.3 It enforces non-weakening baseline rules and handling constraints as specified. --- # 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-l.md?ask= ``` 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.