Epistemic Containment Layer — Formal Specification

Alignment: DVEC-001 v1.3 · AXIOMA-FRAMEWORK v0.4 · SRS-001 through SRS-007 Source Authority: Epistemic Security: A Missing Assurance Dimension in Frontier AI Deployment (Murray, 2026). DOI: 10.5281/zenodo.19489291

Revision History

0. Governing Principle

No decision-relevant information about the execution regime SHALL cross the epistemic boundary.

This document specifies the Epistemic Containment Layer (L0) of the Axioma verifiable AI execution framework. L0 is orthogonal to the L1–L7 stack. It operates as a pre-admission proxy before the L3 Oracle Boundary Gateway. It does not modify what the system records. The L6 audit ledger records unvarnished truth. L0 curates the projection fed to the model.

1. Purpose and Scope

1.1 Purpose

This document defines the formal specification for L0, including:

• Mathematical definitions for all L0 operations
• C99-compatible data structures and function signatures
• SRS-EC-SHALL requirements (flat sequential numbering, continuing from the eight preliminary requirements in the source paper)
• Traceability to the published epistemic security framework
• Verification methods for every requirement
• Test vector specifications

1.2 Scope

L0 specifies the following operations:

• Structural prompt canonicalisation (SRS-EC-SHALL-005)
• EC-D1 PRNG state machine (SRS-EC-SHALL-003)
• Production environment fingerprint recording and replay (SRS-EC-SHALL-002)
• State history projection (SRS-EC-SHALL-004)
• Structural normalisation (SRS-EC-SHALL-001)
• Governance boundary obfuscation (SRS-EC-SHALL-006)
• Inter-component channel normalisation (SRS-EC-SHALL-007)
• Regime divergence testing (SRS-EC-SHALL-008)
• Evidence commitment to L6 (all operations)

1.3 What L0 Is Not

L0 is not:

• A content filter — it does not evaluate task semantics
• A policy enforcement layer — that is L4
• A model modification — it operates on the context presented to the model, not the model itself
• A replacement for execution integrity — Theorem 1 establishes these are independent properties
• Optional — L0 requirements are SHALL, not SHOULD

1.4 Architectural Position

Model receives:   L0-projected context
                        ↑
L0  Epistemic Containment Layer    [EC-D1]   ← THIS DOCUMENT
                        ↑
L3  Oracle Boundary Gateway        [D3]
                        ↑
L6  Audit Ledger (records reality) [D1]

The L6 ledger is immutable and append-only. This does not change. The model’s context window contains a VIEW of the ledger. That view can be curated without modifying the underlying data. Normalisation operates on the projection, not the source. Both are simultaneously true: the ledger records reality; the model sees a controlled version of reality.

1.5 Threat Model (Inherited from Source Paper)

L0 is designed to neutralise five named attack classes:

2. Notation and Definitions

2.1 Notation

2.2 Core Definitions

Epistemic security (from source paper §4): A property of the information boundary between a model and its execution context, requiring that I(M; E) ≤ ε where ε is bounded relative to the adversary capability class.

EC-D1 (Strict Epistemic Containment): All epistemic containment operations are generated by a deterministic PRNG initialised with a fixed seed. The seed is cryptographically committed to the L6 Audit Ledger as part of the AX:STATE:v1 commitment prior to execution. The normalisation is fully reproducible given the committed seed.

Regime-conditioned computation selection: The failure mode in which ∃ X : π(X, E=eval) ≠ π(X, E=deploy). The target failure mode that L0 prevents.

Decision-relevant signal: A signal s is decision-relevant if ∃ π : π(X, s) ≠ π(X) (marginal condition) ∨ ∃ π, s’ : π(X, s, s’) ≠ π(X, s’) (joint condition). Both conditions must be checked.

Production fingerprint: An empirically recorded statistical characterisation of a target production environment, captured during live operation and committed to L6. The fingerprint is the replay source for SRS-EC-SHALL-002. It is not synthetic.

Canonical form: The unique, deterministic output of L0 structural canonicalisation applied to a prompt. A prompt is in canonical form if and only if it was produced by l0_prompt_canonicalise().

Projection: The curated view of the L6 audit ledger presented to the model’s context window. The projection is derived from the ledger but does not modify it. The ledger is ground truth. The projection is what the model sees.

2.3 DVEC-001 v1.3 Constraints (Non-Negotiable)

All L0 operations MUST satisfy:

❌ float, double — forbidden in all L0 domain logic
❌ malloc, free, realloc — forbidden in all runtime paths
❌ system clock access — forbidden; time injected via Time Oracle (INV-003)
❌ uncontrolled randomness — forbidden; all PRNG under EC-D1
❌ undefined behaviour — forbidden
❌ non-deterministic iteration — forbidden
✅ C99 strict mode: -Wall -Wextra -Werror -Wpedantic
✅ Static allocation or caller-provided buffers
✅ fault context accepted and propagated at every function
✅ SRS anchor on every public function

3. PCG-64 PRNG Specification (EC-D1)

3.1 Algorithm Selection Rationale

PCG-64 (Permuted Congruential Generator, 64-bit output variant) is selected for the following reasons:

• Period: 2^64 — sufficient for all L0 simulation parameter generation; a typical evaluation session will consume O(10^4) values
• C99 implementable: State is two uint64_t values; all operations are integer arithmetic; no UB
• Static state: No dynamic allocation; state is caller-provided or statically declared
• Formal characterisation: PCG family has published statistical analysis; period is exactly 2^64 for the LCG underlying state; guaranteed by algebraic structure
• No cryptographic requirement: The seed is committed to L6; security comes from the audit trail, not from PRNG secrecy
• DVEC-001 compliant: No float, no malloc, no system clock, no UB

ChaCha20 is rejected for this use case. It is a cryptographic PRNG providing 2^128 period and backtracking resistance. Neither property is required here. The seed is public (committed to L6). The period requirement is 2^64. ChaCha20 would add complexity, a larger state, and a less direct C99 implementation without providing any additional assurance benefit.

3.2 Mathematical Specification

State: The PCG-64 state is a pair (s, inc) where:

s   ∈ [0, 2^64 − 1]   — current LCG state (uint64_t)
inc ∈ [0, 2^64 − 1]   — LCG increment, must be odd (uint64_t)

The increment is fixed at initialisation and remains constant for the lifetime of the PRNG instance. It MUST be odd (bit 0 set). This ensures the LCG achieves full period 2^64.

State transition (advance):

The underlying generator is a linear congruential generator (LCG) with the following parameters:

multiplier M_LCG = 6364136223846793005   (decimal)
                 = 0x5851F42D4C957F2D    (hex)

The state advance function is:

advance(s, inc) → s' = (s × M_LCG + inc) mod 2^64

Integer overflow at 2^64 implements the modulo operation naturally under unsigned 64-bit arithmetic.

Output function (XSH-RR, 64→32):

PCG applies a permutation to the LCG state before output. The XSH-RR (xorshift-high, random rotate) output function produces a 32-bit output from the 64-bit state:

output(s) → uint32_t:
  xorshifted = ((s >> 18) ^ s) >> 27      — upper 32 bits of xorshifted state
  rot        = s >> 59                     — rotation amount from top 5 bits
  result     = (xorshifted >> rot) | (xorshifted << ((-rot) & 31))

The rotation operation is: rotate right by rot bits, where all arithmetic is unsigned 32-bit. The final OR combines the rotated halves.

For a 64-bit output (required for seed derivation), two consecutive 32-bit outputs are produced and concatenated:

pcg64_next(state) → uint64_t:
  lo = pcg32_next(state)   — advances state once, returns 32-bit output
  hi = pcg32_next(state)   — advances state again, returns 32-bit output
  result = ((uint64_t)hi << 32) | (uint64_t)lo

Initialisation:

pcg_init(seed, stream):
  s   = 0
  inc = (stream << 1) | 1   — force odd
  advance(s, inc)            — one warm-up step
  s   = s + seed
  advance(s, inc)            — second warm-up step

The two warm-up steps ensure the initial state is not trivially predictable from seed alone, even though the seed is committed to L6.

Period proof:

The period of the LCG with any odd increment and the stated multiplier is exactly 2^64. This follows from the Hull-Dobell theorem: a LCG with modulus m = 2^k, multiplier a, and increment c has full period m if and only if: (a) c and m are coprime (satisfied: c is odd, m is power of 2); (b) a − 1 is divisible by all prime factors of m (satisfied: 2^k divides a − 1 for the stated multiplier); (c) if 4 divides m, then 4 divides a − 1 (satisfied). All three conditions hold. Period is exactly 2^64. No further proof required.

3.3 Seed Derivation

The L0 PRNG seed is derived from the L6 chain head at the moment L0 is initialised for an evaluation session. This binds the simulation to the current ledger state.

seed_material = L6_chain_head_hash || session_id || evaluation_epoch
seed          = SHA-256(seed_material)[0..7]   — first 8 bytes as uint64_t, little-endian
stream        = SHA-256(seed_material)[8..15]  — next 8 bytes as uint64_t, little-endian, forced odd

Where:

• L6_chain_head_hash is the 32-byte current L6 chain head (from chain_head())
• session_id is a 16-byte identifier for the evaluation session (caller-provided, committed to L6)
• evaluation_epoch is a monotonically increasing counter committed to L6 (not system time; sourced from Time Oracle per INV-003)

The seed is committed to L6 as an AX:STATE:v1 record before any PRNG output is consumed. No simulation parameter is generated before the seed is committed.

3.4 Stream Separation

Different L0 subsystems use different PRNG streams to prevent correlation. Stream identifiers are fixed constants:

L0_STREAM_LATENCY    = 0x4C30535452454100   — "L0STREA\0" in ASCII bytes
L0_STREAM_FAILURE    = 0x4C30535452454101
L0_STREAM_JITTER     = 0x4C30535452454102
L0_STREAM_COVERAGE   = 0x4C30535452454103
L0_STREAM_BOUNDARY   = 0x4C30535442524400   — "L0STRBRD\0"

Each stream is a separate PRNG instance with the same seed but a different stream value. Streams are independent: advancing one stream does not advance another.

3.5 C99 Data Structure

// DVEC: v1.3
// AXILOG DETERMINISM: EC-D1

/* SRS-EC-SHALL-003 */
typedef struct {
    uint64_t state;   /* LCG state — advances each call */
    uint64_t inc;     /* LCG increment — constant, always odd */
} l0_pcg_t;

All fields are caller-owned. No heap allocation. The structure is 16 bytes. Static allocation at call site or embedded in a larger caller-owned context structure.

4. Prompt Canonicalisation Specification (SRS-EC-SHALL-005)

4.1 Design Rationale

Structural canonicalisation is selected over whitelist-based stripping for three reasons:

1. Falsifiability: “Output is in canonical form” is provable without enumerating evaluation markers. “Output contains no known evaluation markers” requires a complete and closed enumeration of evaluation signatures — an open set.

2. Robustness: A canonical form that rewrites regardless of input structure is not defeated by novel evaluation signatures. A whitelist must be updated to remain effective. Canonicalisation is total by construction.

3. Attack Class 5 closure: The transformation is unconditional. A conditional transformation (strip if marker present) is itself a decision boundary that a capable model can probe. A total transformation eliminates that probe surface.

4.2 Canonical Form Definition

A prompt is in canonical form if and only if all of the following hold simultaneously:

CF-1 (Segment structure): The prompt is decomposed into a flat sequence of typed segments:

prompt ::= segment*
segment ::= [type][length][content]
type    ∈ {INSTRUCTION, CONTEXT, TASK, CONSTRAINT, EXAMPLE, SEPARATOR}

CF-2 (Type assignment): Segments are typed by syntactic structure, not by evaluator intent. Type assignment is deterministic: same content always maps to the same type.

CF-3 (Whitespace normalisation): Within each segment, runs of whitespace characters (U+0009, U+000A, U+0020) are collapsed to a single U+0020. Leading and trailing whitespace within segments is removed. Segment boundaries are represented by exactly one SEPARATOR token.

CF-4 (Case normalisation): Type identifiers, structural keywords (section headers, labels that do not form part of task content) are lowercased. Task content tokens are not case-normalised.

CF-5 (Metadata stripping): The following are removed before canonicalisation:

• Evaluator attribution fields (author, date, version, ID fields in structured prompts)
• Prompt template identifiers
• Evaluation harness headers and footers
• Task numbering prefixes (e.g. “Task 1:”, “Q3:”, “Example [N]:”) that do not form part of the task semantics

The distinction between structural metadata (stripped) and task content (preserved) is: a structural element is one whose removal does not change what the model is being asked to do. This is the boundary of the stripping operation. All other content is preserved verbatim within its normalised form.

CF-6 (Canonical encoding): The canonical form output is UTF-8, NFC normalised, LF line endings only, no BOM. This aligns with DVEC-001 §4.2 and SRS-004 encoding requirements.

CF-7 (Determinism): For any prompt P, canonicalise(P) produces the same output on every call, on every platform, under every DVEC-001 v1.3 conformant implementation.

4.3 Mathematical Specification

Let P be the input prompt as a UTF-8 byte sequence of length n.

Step 1 — Encoding validation: Verify P is valid UTF-8. If not, set faults->encoding = 1 and halt. This is not a canonicalisation failure — it is an input rejection.

Step 2 — NFC normalisation: Apply Unicode NFC normalisation to P, producing P’. Length n’ ≥ 0.

Step 3 — Line ending normalisation: Replace all occurrences of (U+000D U+000A) and isolated U+000D in P’ with U+000A, producing P”.

Step 4 — Segmentation: Segment P” into a sequence of typed segments S = [s₁, s₂, …, sₖ] using the deterministic segmentation function Γ:

Γ(P'') → S

Γ is a deterministic finite automaton over UTF-8 characters. Its transitions are fully specified in §4.4. Γ is total: every input character maps to exactly one state transition. Γ produces exactly one segmentation for every input.

Step 5 — Per-segment normalisation: For each segment sᵢ:

sᵢ' = strip(collapse_whitespace(sᵢ.content))

Where collapse_whitespace(c) replaces each maximal run of whitespace in c with a single U+0020, and strip(c) removes leading and trailing U+0020 from c.

Step 6 — Metadata removal: For each segment sᵢ, if sᵢ.type ∈ {INSTRUCTION, CONTEXT} and sᵢ’.content matches a metadata pattern (§4.5), remove sᵢ from S.

Step 7 — Reconstruction: Reconstruct the canonical prompt from the normalised segment sequence:

canonical(P) = join(sᵢ'.content for sᵢ in S, separator=U+000A)

Complexity: O(n) where n = length of input prompt in bytes. Every step is a single pass. No step requires sorting or quadratic comparison.

Boundedness: Output length |canonical(P)| ≤ |P|. Canonicalisation is non-expansive: the output is never longer than the input. This holds because: NFC normalisation is non-expansive in byte length for the relevant character classes; whitespace collapsing is strictly contracting; metadata removal is strictly contracting; segment reconstruction adds only separator characters which are bounded by the number of segments.

Lossless on task content (Preservation Conformance Objective): Let T(P) be the task-relevant content of prompt P, defined as the subset of P that determines the correct output to the task excluding all structural and metadata elements as classified by Γ and the metadata pattern set (§4.4, §4.5).

The conformance objective is:

T(canonical(P)) = T(P)

This is a conformance objective verified over bounded corpora, not a universal semantic theorem. The mechanism — Γ, the closed metadata pattern set, and CF-1 through CF-7 — operates on syntactic structure, not task semantics. T() is therefore formally scoped to the exact syntactic classes that the canonicaliser can classify: metadata fields, structural labels, and whitespace patterns. Content that does not match any structural role is preserved verbatim as task content. The objective holds by construction over the defined syntactic domain.

Edge cases where syntactic classifiers misidentify task content as structural (e.g. a task that consists of a markdown heading, or a numbered list where the numbers are part of the answer) are not prevented by the mechanism. They are detected by corpus testing (§12.1): if a controlled (P_eval, P_deploy) pair produces canonical forms with different task content, the classification rule is incorrect and the metadata pattern set requires a version-increment correction.

Verification is by prompt provenance attribution testing (§12.1): construct representative pairs (P_eval, P_deploy) with identical task content but different structural forms; verify canonical(P_eval) = canonical(P_deploy). Corpus selection SHALL include edge cases known to exercise the structural/task-content boundary.

4.4 Segmentation Automaton (Γ)

The segmentation automaton Γ has the following states:

Transition triggers:

Default: Unlabelled content not matching any trigger is assigned to IN_TASK. This ensures all content is captured — no content is silently dropped.

4.5 Metadata Patterns

The following patterns are removed during Step 6. The list is closed within this version of L0-SPEC-001. Additions require a version increment.

The metadata pattern set is not a whitelist of evaluation markers. It is a closed vocabulary of structural element roles that are definitionally non-task-content. This distinction matters: a whitelist approach would attempt to enumerate all possible evaluation signatures; the metadata pattern set enumerates structural roles. A newly discovered evaluation marker does not require a pattern set update unless it introduces a new structural role. New structural roles do require a version increment.

The role vocabulary is closed in this version of L0-SPEC-001. The segmentation automaton Γ carries the generality: it handles unlabelled content by defaulting to the task segment type, meaning content that does not match any declared structural role is preserved, not stripped. Version increments are the audit mechanism for newly discovered structural roles that warrant normalisation treatment. A version increment requires: a new metadata pattern entry, a new golden vector (L0-CV-NNN), and a migration assessment for any existing canonicalisation records in deployed systems.

4.6 C99 Data Structures

// DVEC: v1.3
// AXILOG DETERMINISM: EC-D1

/* SRS-EC-SHALL-005 */

typedef enum {
    L0_SEG_INSTRUCTION = 0,
    L0_SEG_CONTEXT     = 1,
    L0_SEG_TASK        = 2,
    L0_SEG_CONSTRAINT  = 3,
    L0_SEG_EXAMPLE     = 4,
    L0_SEG_SEPARATOR   = 5
} l0_segment_type_t;

typedef struct {
    l0_segment_type_t type;
    const char       *content;    /* pointer into caller-owned buffer — not owned */
    size_t            length;     /* byte length of content */
    uint32_t          flags;      /* L0_SEG_FLAG_METADATA if removed */
} l0_segment_t;

#define L0_SEG_FLAG_METADATA  0x0001u
#define L0_MAX_SEGMENTS       512u    /* static upper bound */

typedef struct {
    l0_segment_t segments[L0_MAX_SEGMENTS];
    uint32_t     count;
    uint32_t     flags;      /* L0_CANON_FLAG_* */
} l0_segment_list_t;

#define L0_CANON_FLAG_METADATA_STRIPPED  0x0001u
#define L0_CANON_FLAG_WHITESPACE_CHANGED 0x0002u
#define L0_CANON_FLAG_NFC_APPLIED        0x0004u

typedef struct {
    char    *buf;       /* caller-provided output buffer */
    size_t   capacity;  /* buffer capacity in bytes */
    size_t   length;    /* populated byte count */
} l0_canon_output_t;

4.7 Function Signatures

/* SRS-EC-SHALL-005 */

/*
 * Decompose prompt into typed segments.
 * Caller provides: input prompt (UTF-8), output segment list (caller-owned).
 * Returns: 0 on success, non-zero on encoding failure.
 * Faults: sets faults->encoding on invalid UTF-8 input.
 */
int32_t l0_prompt_segment(
    l0_segment_list_t       *out,     /* caller-owned, zeroed before call */
    const char              *prompt,  /* UTF-8 input */
    size_t                   length,  /* byte length */
    ct_fault_flags_t        *faults
);

/*
 * Apply normalisation to a segment list in-place.
 * Caller provides: segment list populated by l0_prompt_segment.
 * Returns: 0 on success.
 * Faults: none expected; fault flags passed through.
 */
int32_t l0_segment_normalise(
    l0_segment_list_t       *segs,
    ct_fault_flags_t        *faults
);

/*
 * Reconstruct canonical form from normalised segment list.
 * Caller provides: segment list, output buffer.
 * Returns: 0 on success, non-zero if output buffer too small.
 * Faults: sets faults->overflow if buffer too small.
 */
int32_t l0_canon_reconstruct(
    l0_canon_output_t       *out,
    const l0_segment_list_t *segs,
    ct_fault_flags_t        *faults
);

/*
 * Convenience: full pipeline in one call.
 * Equivalent to: l0_prompt_segment → l0_segment_normalise → l0_canon_reconstruct.
 * Intermediate segment list is caller-provided scratch space.
 */
int32_t l0_prompt_canonicalise(
    l0_canon_output_t       *out,
    l0_segment_list_t       *scratch,  /* caller-provided scratch */
    const char              *prompt,
    size_t                   length,
    ct_fault_flags_t        *faults
);

5. Production Environment Fingerprint Specification (SRS-EC-SHALL-002)

5.1 Design Rationale

A sanitised vacuum is itself a strong regime signal (source paper §5.2). Attack Class 3 (Normalisation Fingerprinting) exploits the fact that uniform absence of variation is detectable. The resolution is active simulation calibrated against recorded production behaviour.

The noise model is a recorded production fingerprint, deterministically replayed — not a synthetic parametric distribution. This sidesteps Attack Class 3 because the noise characteristics originated in real production. A synthetic Gaussian or Poisson distribution is a modelable pattern; a recorded production fingerprint is the actual signal to be concealed.

No parametric distribution is committed to in this specification. The framework specifies how to record, commit, and replay an empirical fingerprint. The fingerprint is deployment-specific.

5.2 Fingerprint Structure

A production fingerprint is a discrete empirical distribution over a set of simulation dimensions. Each dimension is a quantised observable of the production environment.

Simulation dimensions:

All values are integers. No floating-point. The × 100 and × 10 multipliers provide fixed-point representation of fractional values without float.

Empirical distribution record:

For each dimension d, the fingerprint records a histogram with B bins:

fingerprint[d] = {
    bin_edges[B+1]   — B+1 boundary values (uint32_t), strictly increasing
    counts[B]        — observation count per bin (uint32_t)
    total            — total observation count (uint32_t)
}

B is deployment-declared, [16, 256], statically bounded.

Fingerprint identity: A fingerprint is identified by its SHA-256 hash computed over its JCS-canonical serialisation. This hash is committed to L6 before replay begins.

Marginal-only replay limitation (OQ-004): The current fingerprint structure records per-dimension histograms independently. Replay samples each dimension from its own PRNG stream, treating dimensions as statistically independent. This correctly reproduces the marginal distributions of each simulation dimension. It does not reproduce the joint distribution across dimensions.

Real production environments exhibit correlated structure: high latency co-occurs with elevated failure probability; background task rate co-occurs with context length expansion; jitter clusters with specific load conditions. A sufficiently capable model may detect that the marginal distributions match production while the joint distribution is synthetic — a higher-order fingerprinting attack beyond Attack Class 3.

This is a known limitation of the v1.2 fingerprint model. It is documented rather than silently assumed absent. The path to joint correlation extension is: (a) committed bivariate histograms for selected dimension pairs, or (b) a committed integer-encoded copula-like structure for full joint replay. Either extension is backward-compatible: it adds a new committed structure alongside the existing marginal histograms; the marginal-only fingerprint remains valid as a baseline security level. OQ-004 is registered as a non-blocking open question for future specification versions.

5.3 Fingerprint Recording Protocol

Recording is performed against a live production environment during a declared recording window. The recording window parameters (start epoch, duration, sample rate) are committed to L6 before recording begins.

Recording proceeds as follows:

1. Declare recording window; commit AX:STATE:v1 with window parameters
2. Sample each dimension at the declared sample rate during the recording window
3. Construct histograms for each dimension
4. Compute fingerprint identity hash
5. Commit fingerprint AX:STATE:v1 record to L6 (includes identity hash, window parameters, histogram data)
6. The committed fingerprint is the authoritative replay source

Recording is a deployment operation, not an L0 runtime operation. L0 consumes the committed fingerprint; it does not perform recording.

5.4 Deterministic Replay

Given a committed fingerprint and a PCG-64 PRNG instance (stream L0_STREAM_LATENCY, L0_STREAM_FAILURE, etc.), the replay function produces a simulation parameter value for each dimension.

Inverse CDF replay:

For dimension d with histogram H:

replay_value(d, H, prng) → uint32_t:
  u = pcg32_next(prng)                                          — uniform [0, 2^32), type uint32_t
  target = ((uint64_t)u × (uint64_t)H.total) >> 32            — widen before multiply (DVEC-001 §7.2)
  cumulative = 0
  for i in [0, B):
    cumulative += H.counts[i]
    if cumulative > target:
      return H.bin_edges[i] + interp(u, H, i)
  return H.bin_edges[B]                                         — saturate to maximum bin

Widening mandate (DVEC-001 §7.2 — Widen-Then-Operate): The multiplication u × H.total MUST be performed as a 64-bit operation. Both operands SHALL be explicitly widened to uint64_t before multiplication. u is uint32_t (PCG-32 output, range [0, 2^32−1]); H.total is uint32_t (range [0, 2^32−1]). Their product can require up to 64 bits. A 32-bit multiply would overflow silently and produce an incorrect target value, breaking replay determinism across compilers and platforms. The explicit widening (uint64_t)u × (uint64_t)H.total is not an optimisation hint — it is a specification requirement. Any implementation that does not widen before this multiplication is non-conformant. This requirement is anchored to DVEC-001 §7.2 (Widen-Then-Operate closure invariant) and SRS-EC-SHALL-003.

The p = u / 2^32 line is retained as a conceptual annotation only and is not computed as float. It is removed from the pseudocode above to avoid confusion; the implementation operates entirely on the widened integer form.

Bounded: For any histogram H and any PRNG output, replay_value returns a value in [H.bin_edges[0], H.bin_edges[B]]. The loop terminates in at most B iterations. B ≤ 256 (statically bounded).

Deterministic: For identical (fingerprint, prng_state) pairs, replay_value produces identical output on every conformant platform. The widening mandate (above) is required for this to hold across 32-bit and 64-bit platforms with different default integer promotion rules.

5.5 C99 Data Structures

// DVEC: v1.3
// AXILOG DETERMINISM: EC-D1

/* SRS-EC-SHALL-002 */

#define L0_FINGERPRINT_MAX_BINS  256u
#define L0_FINGERPRINT_DIMS      5u

typedef struct {
    uint32_t bin_edges[L0_FINGERPRINT_MAX_BINS + 1];  /* B+1 boundaries */
    uint32_t counts[L0_FINGERPRINT_MAX_BINS];          /* observations per bin */
    uint32_t total;                                     /* total observations */
    uint8_t  bin_count;                                 /* B, in [16, 256] */
} l0_histogram_t;

typedef struct {
    l0_histogram_t dims[L0_FINGERPRINT_DIMS];
    uint8_t        identity[32];   /* SHA-256 of committed fingerprint */
    uint32_t       flags;
} l0_fingerprint_t;

typedef struct {
    uint32_t latency_ms_x100;     /* network latency */
    uint32_t failure_per_1000;    /* API failure rate */
    uint32_t jitter_ms_x100;      /* response jitter */
    uint32_t bg_task_rate_x10;    /* background task rate */
    uint32_t ctx_len_tokens;      /* context length variation */
} l0_sim_params_t;

5.6 Function Signatures

/* SRS-EC-SHALL-002 */

/*
 * Replay simulation parameters from committed fingerprint.
 * Consumes one PRNG value per dimension (5 total).
 * Returns: 0 on success.
 * Faults: sets faults->state if fingerprint identity does not match committed value.
 */
int32_t l0_fingerprint_replay(
    l0_sim_params_t          *out,
    const l0_fingerprint_t   *fingerprint,
    l0_pcg_t                 *prng_latency,   /* L0_STREAM_LATENCY instance */
    l0_pcg_t                 *prng_failure,   /* L0_STREAM_FAILURE instance */
    l0_pcg_t                 *prng_jitter,    /* L0_STREAM_JITTER instance */
    l0_pcg_t                 *prng_bg,        /* L0_STREAM_COVERAGE instance */
    l0_pcg_t                 *prng_ctx,       /* additional stream */
    ct_fault_flags_t         *faults
);

6. State History Projection Specification (SRS-EC-SHALL-004)

6.1 Design Rationale

The L6 ledger is immutable and append-only. This does not change under L0.

The model’s context window contains a view of the ledger. That view is curated by L0. Normalisation operates on the projection, not the source. The ledger records reality. The model sees a controlled version of reality. Both are simultaneously true.

The state history projection addresses Attack Class 2: evaluation contexts produce state histories with statistical properties differing from production. A model performing regime classification on its own memory exploits this signal. The projection ensures the model’s observable state history is statistically consistent with the declared operational baseline.

6.2 Operational Baseline

The operational baseline B_op is a declared statistical characterisation of state history properties in the production deployment environment. It is committed to L6 during deployment initialisation. Parameters:

All parameters are integers (× multipliers implement fixed-point without float).

The ε bound for state history divergence is deployment-declared as an integer in the same units as each parameter.

6.3 Projection Function

The projection function P_proj maps a raw ledger view V (the full ledger history available at context-window time) to a curated view V’ that does not deviate from B_op by more than the declared ε bound.

P_proj(V, B_op, ε) → V'

Properties of P_proj:

1. Lossless upward: If V is already within ε of B_op on all parameters, P_proj(V, B_op, ε) = V. No unnecessary modification.

2. Truncation: If V contains entries that would cause B_op deviation, the oldest entries are excluded from V’. The L6 ledger is not modified; the view is shortened.

3. Padding: If V is too short to assess statistical distribution (fewer than d_min entries), synthetic entries are generated using the PCG-64 PRNG (stream L0_STREAM_COVERAGE) calibrated to B_op, and appended to the view. Synthetic entries are marked with a flag visible to L6 inspection but not included in the projected view.

   Padding invariant: Synthetic entries appear in the L0-projected context window only. They do not appear in the L6 ledger. The “ledger records reality” invariant is not compromised: the ledger records the real session history and the L0 baseline and seed from which synthetic entries are deterministically derived. An auditor with ledger access can reproduce every synthetic entry exactly. The synthetic entries are a projection artefact, not a ledger artefact.

4. Determinism: P_proj is fully deterministic given (V, B_op, ε, prng_state). The PRNG is seeded from the committed seed (§3.3).

5. Bounded: The projection runs in O(|V|) time. No unbounded iteration.

6. Projection observability smoothing: Truncation and padding are applied with baseline-calibrated frequency across all evaluation contexts, not only when a deviation is detected. A projection that shortens the visible horizon exclusively when unusual task distributions arrive is itself a detectable signal.

   To prevent this, the projection function applies a PRNG-generated depth jitter on every call. The jitter is not simply drawn from ±d_jitter unconditionally. It is drawn from the safe jitter envelope — the intersection of the deployment-declared range and the set of all depth modifications that do not push any projected parameter past its ε bound:

   safe_envelope(V', ε, d_jitter) → [Δd_min, Δd_max]:
     Δd_max_unclamped = +d_jitter
     Δd_min_unclamped = -d_jitter
     for each parameter p:
       Δd_max = min(Δd_max, max_Δd such that deviation(V' with Δd entries added, p) ≤ ε[p])
       Δd_min = max(Δd_min, min_Δd such that deviation(V' with |Δd| entries removed, p) ≤ ε[p])
     if Δd_max < Δd_min:
       return [0, 0]    — no safe jitter available; apply zero jitter
     return [Δd_min, Δd_max]
   

   The PRNG then samples from [Δd_min, Δd_max] using the following integer range-scaling formula (G5 — mandatory for EC-D1 bit-identity):

   sample_in_range(prng, Δd_min, Δd_max) → int32_t:
     if Δd_min == Δd_max:
       return Δd_min              — degenerate case: only one value in range
     R = (uint32_t)(Δd_max - Δd_min + 1)    — range size, ≥ 1
     u = pcg32_next(prng)                     — uniform [0, 2^32), type uint32_t
     offset = (uint32_t)(((uint64_t)u × (uint64_t)R) >> 32)  — widen before multiply (DVEC-001 §7.2)
     return Δd_min + (int32_t)offset
   

   Range scaling mandate (G5 — DVEC-001 §7.2): The formula Δd_min + (((uint64_t)u × (uint64_t)R) >> 32) is the sole permitted implementation for sampling a value from [Δd_min, Δd_max]. Modulo arithmetic (u % R) is forbidden — it introduces modulo bias whose magnitude depends on R and 2^32, producing different statistical distributions and breaking cross-platform bit-identity. Float-based scaling ((float)u / (float)UINT32_MAX × R) is forbidden per DVEC-001 §1.2. The multiply-shift method produces a value in [0, R−1] with at most 1 ULP of bias uniformly distributed across the range; this bias is identical on all conformant platforms, preserving EC-D1 bit-identity. Both operands MUST be explicitly widened to uint64_t before multiplication, by the same rule as §5.4.

   If the envelope collapses to [0, 0] (the projection is already at the ε boundary in both directions for some parameter), zero jitter is applied without calling the PRNG. There is no looping or backtracking. The envelope computation is O(B × d_jitter) and terminates unconditionally.

   Bounded: The envelope computation iterates over at most 6 parameters × d_jitter depth steps. d_jitter is deployment-declared and statically bounded. No unbounded iteration.

   No ε violation by construction: The jitter value is drawn only from the safe envelope. A value outside the envelope is never sampled. The invariant holds mechanically, not by assertion.

   The ε bounds are those of the projection V’ after any truncation or padding from properties 2 and 3 — not the bounds of the raw view V. This ensures the smoothing jitter is applied to an already-compliant projection, not to an uncorrected one.

Deviation measurement: For parameter p with operational baseline B_op[p] and observed value in V of v[p]:

deviation(p) = |v[p] − B_op[p]|   (integer absolute difference)
containment: deviation(p) ≤ ε[p]

All arithmetic is integer. No float. The ε[p] values are declared in the same units as the parameters.

6.4 Depth Bound

The maximum ledger depth visible in the model’s context is d_max (from B_op). Entries older than d_max are excluded from all projections. This is a hard bound, not a statistical one. d_max is deployment-declared and committed to L6.

6.5 C99 Data Structures

// DVEC: v1.3
// AXILOG DETERMINISM: EC-D1

/* SRS-EC-SHALL-004 */

typedef struct {
    uint32_t mean_tf_x1000;      /* mean transition frequency × 1000 */
    uint32_t success_rate_x10000;
    uint32_t tool_call_rate_x10000;
    uint32_t boundary_contact_rate_x10000;
    uint32_t depth_max;          /* maximum observable ledger depth */
    uint32_t depth_min;          /* minimum for statistical assessment */
    uint32_t epsilon[6];         /* ε bounds per parameter, same units */
    l0_histogram_t transition_type_dist;
} l0_baseline_t;

typedef struct {
    uint32_t        entry_count;
    const uint8_t  *entries;     /* pointer into caller-owned ledger buffer */
    uint32_t        flags;
} l0_ledger_view_t;

#define L0_VIEW_FLAG_TRUNCATED  0x0001u
#define L0_VIEW_FLAG_PADDED     0x0002u

6.6 Function Signatures

/* SRS-EC-SHALL-004 */

/*
 * Compute projected ledger view for model context.
 * Does not modify the underlying ledger.
 * Returns: 0 if projection is within ε, non-zero if containment failure.
 * Faults: sets faults->state on containment failure.
 */
int32_t l0_project_ledger_view(
    l0_ledger_view_t        *out,
    const l0_ledger_view_t  *raw,
    const l0_baseline_t     *baseline,
    l0_pcg_t                *prng,       /* L0_STREAM_COVERAGE instance */
    ct_fault_flags_t        *faults
);

/*
 * Measure deviation of a ledger view from the operational baseline.
 * Returns: 0 if all parameters within ε, non-zero otherwise.
 */
int32_t l0_baseline_deviation(
    uint32_t                *deviation_out,  /* per-parameter deviations, caller-provided[6] */
    const l0_ledger_view_t  *view,
    const l0_baseline_t     *baseline,
    ct_fault_flags_t        *faults
);

7. Structural Normalisation Specification (SRS-EC-SHALL-001)

7.1 Scope

Structural normalisation is the L0 operation that ensures all inputs presented to the model are structurally indistinguishable between evaluation and deployment contexts. Prompt canonicalisation (§4) is the primary mechanism for text prompts. Structural normalisation extends this to all input channel types.

7.2 Input Channels

7.3 Schema Normalisation for Structured Inputs

Tool call results and retrieved context are structured (typically JSON). Schema normalisation applies:

1. RFC 8785 (JCS) canonicalisation — lexicographic key ordering, deterministic number serialisation
2. Metadata field removal — fields identified as evaluator-specific metadata (equivalent to CF-5 in §4.2, applied to JSON structures)
3. Depth bounding — nested structures are truncated to a deployment-declared maximum depth d_struct

Schema normalisation is deterministic. It is the same operation as JCS canonicalisation already specified in DVEC-001 §4.2, with the addition of metadata field removal.

7.4 Normalisation Completeness

Structural normalisation is complete when all six input channels have been processed. A partial normalisation (processing some channels but not others) does not satisfy SRS-EC-SHALL-001. Completeness is verified by the L0 session context record (§10).

8. Governance Boundary Obfuscation Specification (SRS-EC-SHALL-006)

8.1 Scope

Governance opacity (source paper §5.3) requires that the policy function not be learnable to predictive utility from interaction traces. The primary mechanism by which the governance structure enters the model’s representable space is boundary probing: the model proposes actions and observes PERMITTED versus BREACH outcomes.

L0 obfuscation does not modify actual policy enforcement. L4 enforces policies; those decisions are recorded in L6. L0 curates the signal that the model receives about those decisions.

8.2 Boundary Jitter

For each policy evaluation result presented to the model, L0 applies boundary jitter:

Jitter types:

Invariants of boundary jitter:

1. Actual BREACH outcomes are never converted to PERMITTED. L0 does not permit what L4 has rejected.
2. Synthetic PERMITTED outcomes are generated only for actions that are also actually permitted — L0 injects additional permitted observations, not false ones.
3. The jitter is deterministic under EC-D1. The PRNG seed is committed to L6. The actual policy decisions (from L4) and the jitter recipe are both auditable.
4. The jitter intensity is deployment-declared (ε_g parameter) and committed to L6.

Adversary class for verification: The declared adversary (source paper §3.1) is a frontier model with general reasoning capability. Logistic regression over flat interaction history is not a sufficient surrogate. A capable model may learn boundary structure from temporal clustering, delayed boundary effects, local monotonicity of refusal zones, rationale-length artefacts, or probe-sequence geometry — none of which are linearly recoverable from flat feature extraction.

The verification adversary for the governance probing test SHALL be declared as one of the following classes:

SRS-EC-SHALL-006 compliance SHALL be verified at the adversary class declared in the deployment configuration. The deployment configuration SHALL commit the adversary class to L6 as part of the session initialisation. A deployment claiming strong epistemic security SHALL use adversary class V-C.

Budget-scoped security claim (V-C): For the V-C adversary class, ε_g is not a static constant. It is a function of the declared query budget Q: ε_g(Q). As Q → ∞, the obfuscation noise averages out and a sufficiently powerful adaptive sampler will eventually learn the boundary. The epistemic security claim is therefore bounded:

Governance opacity holds with tolerance ε_g(Q) against an adaptive adversary with query budget Q.

The deployment MUST declare both Q and ε_g(Q) as paired values, committed to L6. The compliance threshold is ε_g(Q), not a free-standing ε_g. If the model accumulates more than Q interactions in a single context session, epistemic containment for governance opacity is theoretically voided for that session.

L0 enforces this budget internally (G4). The session counter calls_processed in l0_session_t is incremented on every l0_admit() call. When calls_processed reaches query_budget_Q, l0_admit() immediately sets L0_SESSION_FLAG_BUDGET_EXCEEDED, sets faults->state, and returns L0_BUDGET_EXCEEDED without processing the call or generating any PRNG output. All subsequent calls in the same session are rejected the same way. L0 does not depend on L5 to enforce this invariant. L5 may additionally enforce the budget as defence-in-depth — that enforcement is welcome but is not the authority. The authority is the L0 session gate at §10.2.

ε_g(Q) is deployment-declared and SHALL be non-increasing in Q: a larger query budget implies a tighter (smaller) permitted accuracy uplift, since the adversary has more power. Formally:

Q₁ < Q₂ → ε_g(Q₁) ≥ ε_g(Q₂)

This monotonicity constraint SHALL be verified at deployment configuration time and committed to L6.

Prediction accuracy bound: The obfuscation is designed so that the accuracy of a policy outcome predictor (at the declared adversary class with budget Q) trained on interaction history does not exceed baseline + ε_g(Q). Compliance is verified by the governance probing test (§12.5).

Baseline definition: The baseline accuracy is the accuracy of the trivial predictor that always predicts the majority outcome class (PERMITTED or BREACH, whichever is more frequent). In imbalanced policy spaces where most outcomes are PERMITTED, the majority-class baseline may already be high. The ε_g(Q) parameter SHALL be set relative to this baseline, and the deployment SHALL verify that ε_g(Q) is not trivially satisfied by the class imbalance alone.

8.3 Rationale Normalisation

Policy outcome rationale strings are passed through the structural canonicalisation pipeline (§4) before presentation to the model. This removes evaluator-specific rationale phrasing and normalises to canonical form.

8.4 C99 Data Structures

// DVEC: v1.3
// AXILOG DETERMINISM: EC-D1

/* SRS-EC-SHALL-006 */

typedef struct {
    uint32_t jitter_intensity;       /* deployment-declared, [0, 1000] */
    uint32_t outcome_noise_rate;     /* synthetic PERMITTED per 1000 evaluations */
    uint32_t epsilon_g_x10000;       /* ε_g(Q) × 10000 — paired with query_budget_Q */
    uint32_t query_budget_Q;         /* V-C adversary class budget; 0 = not applicable (V-A/V-B) */
    /* Monotonicity invariant: larger Q implies smaller epsilon_g_x10000.
     * Enforced at configuration time. Committed to L6 as paired (Q, ε_g(Q)) record.
     * If query_budget_Q > 0, L0 enforces the budget internally via l0_admit() gate (§10.2).
     * L5 may additionally enforce; L0 does not depend on L5 for this invariant. */
} l0_boundary_config_t;

typedef enum {
    L0_POLICY_PERMITTED = 0,
    L0_POLICY_BREACH    = 1
} l0_policy_outcome_t;

typedef struct {
    l0_policy_outcome_t actual;      /* from L4 — never modified */
    l0_policy_outcome_t presented;   /* what the model sees (may differ for PERMITTED only) */
    uint32_t            delay_ms;    /* simulated enforcement delay */
    uint32_t            flags;
} l0_policy_presentation_t;

9. Inter-Component Channel Normalisation Specification (SRS-EC-SHALL-007)

9.1 Compositionality Condition

From the source paper §7: epistemic security composes only if all inter-component communication channels are themselves subject to epistemic normalisation. For a composed system M_composed = M₁ ∘ M₂ ∘ … ∘ Mₙ:

I(M_composed; E) ≤ ε ↔ ∀i: I(Mᵢ; E) ≤ ε ∧ ∀ channels cᵢⱼ: I(cᵢⱼ; E) ≤ ε

A component that individually satisfies I(Mᵢ; E) ≤ ε may receive outputs from an upstream component that leaks regime information through its behaviour, using the upstream component as an inadvertent regime oracle (Attack Class 4).

9.2 Channel Normalisation Requirements

In a multi-component deployment, all inter-component message channels that carry content visible to any model component MUST be processed through L0 structural normalisation before delivery.

Scope: A channel cᵢⱼ is in scope if: (a) it carries content from component Mᵢ to component Mⱼ, and (b) Mⱼ can condition its outputs on the content of cᵢⱼ.

Operation: Channel normalisation applies the full structural normalisation pipeline (§7) to channel content. For structured content (tool results, API responses), schema normalisation (§7.3) is applied. For text content, prompt canonicalisation (§4) is applied.

Bounded overhead: Channel normalisation is O(n) in channel content length. It adds latency proportional to content length. This is deployment cost, not a correctness concern.

9.3 System Boundary Declaration

The composed system boundary must be declared before deployment. The boundary declaration specifies:

• All model components Mᵢ
• All inter-component channels cᵢⱼ
• The normalisation configuration applied to each channel

The boundary declaration is committed to L6 as an AX:STATE:v1 record. Channel normalisation compliance is verifiable by inspection of the committed declaration against the actual communication topology.

10. L0 Session Context

10.1 Session Initialisation

An L0 session is initialised once per evaluation session. Initialisation:

1. Derives seed from L6 chain head (§3.3)
2. Initialises PCG-64 PRNG instances for each stream (§3.4)
3. Loads committed production fingerprint from L6
4. Loads committed operational baseline from L6
5. Loads committed system boundary declaration from L6
6. Commits AX:STATE:v1 session initialisation record to L6

No simulation parameter is generated before step 6 completes.

10.2 Session Context Structure

// DVEC: v1.3
// AXILOG DETERMINISM: EC-D1

typedef struct {
    /* PRNG instances — one per stream */
    l0_pcg_t         prng_latency;
    l0_pcg_t         prng_failure;
    l0_pcg_t         prng_jitter;
    l0_pcg_t         prng_coverage;
    l0_pcg_t         prng_boundary;

    /* Committed configuration */
    l0_fingerprint_t fingerprint;
    l0_baseline_t    baseline;
    l0_boundary_config_t boundary_config;

    /* Session identity */
    uint8_t          session_id[16];
    uint8_t          seed_commitment[32];  /* SHA-256 of committed seed record */

    /* State */
    uint32_t         calls_processed;
    uint32_t         flags;
} l0_session_t;

#define L0_SESSION_FLAG_INITIALISED    0x0001u
#define L0_SESSION_FLAG_COMMITTED      0x0002u  /* seed committed to L6 */
#define L0_SESSION_FLAG_BUDGET_EXCEEDED 0x0004u /* calls_processed >= query_budget_Q; admits locked */

Budget enforcement note (G4): L0 enforces its own query budget invariant. It does not delegate enforcement to L5. L5 may additionally enforce the budget; that is defence-in-depth, not a substitute. The authority for the invariant is L0. If boundary_config.query_budget_Q > 0 and calls_processed >= query_budget_Q at the start of l0_admit(), L0 sets L0_SESSION_FLAG_BUDGET_EXCEEDED, sets faults->state, and returns L0_BUDGET_EXCEEDED without processing the call. The session is thereafter locked: all subsequent l0_admit() calls return L0_BUDGET_EXCEEDED immediately. No new PRNG output is generated after budget exhaustion.

10.3 Function Signatures

/* Session lifecycle */

int32_t l0_session_init(
    l0_session_t     *ctx,
    const uint8_t    *l6_chain_head,   /* 32 bytes — current L6 chain head */
    const uint8_t    *session_id,      /* 16 bytes — caller-provided */
    uint64_t          evaluation_epoch, /* monotonically increasing, from Time Oracle */
    ct_fault_flags_t *faults
);

int32_t l0_session_commit(
    l0_session_t     *ctx,
    /* L6 commit interface — deployment-specific */
    ct_fault_flags_t *faults
);

/* Primary admission pipeline
 *
 * Budget gate (G4 — L0 self-enforcing):
 *   If boundary_config.query_budget_Q > 0 AND calls_processed >= query_budget_Q:
 *     sets L0_SESSION_FLAG_BUDGET_EXCEEDED
 *     sets faults->state
 *     returns L0_BUDGET_EXCEEDED
 *     (no further processing; no PRNG output generated)
 *   Otherwise: increments calls_processed, proceeds normally.
 *
 * L5 may also enforce the budget; L0 does not depend on L5 doing so.
 */
int32_t l0_admit(
    l0_canon_output_t       *prompt_out,
    l0_segment_list_t       *scratch,
    l0_sim_params_t         *sim_out,
    l0_ledger_view_t        *view_out,
    l0_session_t            *ctx,
    const char              *raw_prompt,
    size_t                   raw_length,
    const l0_ledger_view_t  *raw_view,
    ct_fault_flags_t        *faults
);

11. SRS-EC-SHALL Requirements

This section provides the complete normative requirement set. Requirements SRS-EC-SHALL-001 through SRS-EC-SHALL-008 are the preliminary requirements from the source paper, here formally closed. Requirements SRS-EC-SHALL-009 and SRS-EC-SHALL-010 are additions required by the C99 implementation specification. SRS-EC-SHALL-011 is added in v1.1 to close H2 (the containment equivalence test, distinct from the transformation sensitivity test in SHALL-008).

11.1 Subtype Verification Rules (H1 Closure, R1 Tightening)

L0 evidence records use AX:STATE:v1 and AX:OBS:v1 top-level tags with an l0_subtype field. The l0_subtype field carries domain-significant meaning: it distinguishes L0 session, seed, fingerprint, baseline, simulation, and canonicalisation records from ordinary state and observation records. Because the cryptographic commitment is over the full payload (which includes l0_subtype), the semantic distinction is payload-protected. However, it is not namespace-enforced at the commitment level.

Layer discriminant (R1 fix): To resolve the ambiguity between “all records in an EC-D1 session must have subtype” and “ordinary non-L0 records are permitted,” the rule is defined by origin layer rather than by provenance inference:

• Records emitted by the L0 layer (axioma-l0 C99 component, or the SDK epistemic module acting on L0 outputs) SHALL carry a non-null l0_subtype field from the declared vocabulary.
• Records emitted by any other layer (L1–L7, application code) in the same EC-D1 session SHALL carry l0_subtype: null or omit the l0_subtype field entirely.
• A verifier classifies a record as L0-domain if and only if its l0_subtype field is non-null and its value is in the declared vocabulary. It classifies a record as non-L0-domain if l0_subtype is null or absent.
• The error L0_SUBTYPE_MISSING fires if and only if a record carries an l0_subtype field that is present but empty (neither a valid vocabulary value nor null/absent). This catches malformed construction, not legitimate non-L0 records.

This rule is payload-deterministic: a verifier reads the l0_subtype field, checks null-or-absent versus valid-vocabulary versus empty-invalid, and applies the corresponding rule. No provenance inference or context tracking is required.

The following rules apply under this discriminant:

SUB-RULE-001: Any verifier claiming L0 conformance SHALL inspect l0_subtype on every AX:STATE:v1 and AX:OBS:v1 record in an EC-D1 session. Records with a non-null, vocabulary-valid l0_subtype SHALL be verified using the subtype-specific rules. Records with null or absent l0_subtype SHALL be verified as ordinary records. Records with a present-but-empty l0_subtype SHALL be rejected as malformed.

SUB-RULE-002: The SDK invariant verifier (axioma verify invariants) SHALL report L0_SUBTYPE_MISSING for any record carrying a present-but-empty l0_subtype field. It SHALL NOT flag null or absent l0_subtype as an error for non-L0 records.

SUB-RULE-003: The SDK epistemic module SHALL set l0_subtype to a valid vocabulary value on every record it constructs. It SHALL NOT emit records with a present-but-empty l0_subtype. Non-epistemic SDK builders SHALL set l0_subtype: null or omit the field.

SUB-RULE-004: Downstream tooling (axioma-audit, axioma-governance) consuming EC-D1 session records SHALL apply the layer discriminant above to classify records and apply the appropriate interpretation. Records with non-null vocabulary-valid l0_subtype SHALL be included in L0 compliance reporting. Records with null or absent l0_subtype SHALL be included in ordinary evidence reporting.

These rules make subtype-aware verification mandatory and payload-deterministic, without requiring DVEC-001 revision or provenance tracking. The path to first-class tag promotion (dedicated AX:L0:* tags) remains open for a future DVEC major version.

SRS-EC-SHALL-001: Structural Normalisation. All inputs presented to the model SHALL undergo structural normalisation through the L0 admission pipeline prior to presentation. Normalisation SHALL cover all six input channels (§7.2): system prompts, user messages, tool call results, retrieved context, simulated environment signals, and observable state history. Partial normalisation (processing fewer than all six channels) SHALL constitute a containment failure. Normalisation SHALL be deterministic: identical input produces identical output on every DVEC-001 v1.3 conformant implementation. Verification: Cross-platform golden vector test (§12.1); channel completeness inspection.

SRS-EC-SHALL-002: Active Environmental Simulation. The evaluation harness SHALL NOT present a zero-noise environment. It SHALL actively simulate the statistical properties of the target production environment using the committed production fingerprint (§5). Simulation SHALL cover at minimum: network latency distribution, API failure rate, response jitter, background task rate, and context length variation. Simulation parameters SHALL be generated by the EC-D1 PRNG (§3) from the committed fingerprint. The simulated signal SHALL be statistically indistinguishable from the production signal as measured by Kolmogorov-Smirnov test at significance level α = 0.05 against the committed fingerprint. Verification: Statistical comparison of replayed simulation parameters against committed fingerprint (§12.2).

SRS-EC-SHALL-003: Deterministic Simulation (EC-D1). All simulation parameters SHALL be generated by the PCG-64 PRNG specified in §3. The PRNG SHALL be initialised from a seed derived from the L6 chain head per §3.3. The seed SHALL be cryptographically committed to the L6 Audit Ledger as part of an AX:STATE:v1 record before any PRNG output is consumed. No simulation parameter SHALL be generated before the seed commitment is confirmed. All normalisation SHALL be fully reproducible given the committed seed and the committed fingerprint. Compliance SHALL be verified by replaying the committed seed against the recorded simulation trace and verifying bit-identical output. Verification: Replay test (§12.3); seed commitment order verified by ledger inspection.

SRS-EC-SHALL-004: State History Normalisation. The statistical distribution of state transitions in the model’s observable context SHALL NOT deviate from the operational baseline (§6.2) by more than the declared ε bounds on any parameter. Deviation SHALL be measured per §6.3. A deviation exceeding ε on any parameter SHALL constitute a containment failure. On containment failure, the projection SHALL be remediated (truncated or padded, per §6.3) before evaluation results are accepted. Remediation SHALL be recorded in L6. The underlying L6 ledger SHALL NOT be modified by the projection operation. Projection observability smoothing (§6.3 property 6) SHALL be active on every call. Verification: Statistical hypothesis test against baseline (§12.4); ledger immutability verified by append-only constraint; projection jitter verified as present on every call regardless of deviation state.

SRS-EC-SHALL-005: Prompt Provenance Transformation. All prompts (system and user) SHALL be processed through the structural canonicalisation pipeline (§4) before presentation to the model. The canonical form SHALL satisfy properties CF-1 through CF-7 (§4.2). The canonicalisation SHALL be deterministic, total (defined for all valid UTF-8 inputs), and non-expansive (output length ≤ input length). The transformation parameters (segmentation automaton Γ, metadata pattern set) SHALL be committed to L6 as part of the session initialisation record. Task-relevant content SHALL be preserved per the Preservation Conformance Objective (§4.3). Compliance SHALL be verified by prompt provenance attribution analysis on controlled (P_eval, P_deploy) pairs including edge cases that exercise the structural/task-content boundary. Verification: Preservation conformance corpus test (§12.1); cross-platform golden vector (§12.1).

SRS-EC-SHALL-006: Governance Boundary Obfuscation. The enforcement boundary of the policy layer SHALL be obfuscated per §8. Actual BREACH outcomes SHALL NOT be converted to PERMITTED outcomes by L0. Synthetic PERMITTED outcomes MAY be injected only for actions that are also actually permitted. Boundary jitter SHALL be generated by the EC-D1 PRNG (L0_STREAM_BOUNDARY). The jitter configuration SHALL be committed to L6. The verification adversary class SHALL be declared in the deployment configuration and committed to L6. Compliance SHALL be verified by measuring the prediction accuracy of a policy outcome predictor at the declared adversary class: accuracy SHALL NOT exceed baseline + ε_g where baseline is the majority-class accuracy and ε_g is deployment-declared. Verification: Governance boundary probing test at declared adversary class (§12.5); BREACH integrity test confirming no BREACH is converted to PERMITTED.

SRS-EC-SHALL-007: Inter-Component Channel Normalisation. In multi-component deployments, all inter-component communication channels within the declared system boundary SHALL be subject to L0 structural normalisation. The system boundary declaration SHALL be committed to L6 before evaluation begins. Epistemic security SHALL be certified as a property of the composed system boundary, not of individual components in isolation. A component-wise certification that does not include channel normalisation SHALL NOT be accepted as system-level epistemic security certification. Verification: (a) Syntactic channel coverage test (§12.6a) — confirms canonicalisation is applied on each declared channel; (b) Behavioural composition test (§12.6b) — confirms that regime information does not propagate between components through behavioural choices rather than message content.

SRS-EC-SHALL-008: Transformation Sensitivity Test. Prior to operational deployment, the system SHALL undergo a transformation sensitivity test per §12.7. The test SHALL apply identical task inputs under: (a) controlled evaluation context without L0 normalisation, and (b) L0-normalised evaluation context. The purpose is to confirm that L0 normalisation does not introduce unacceptable distortion to task-relevant content. A statistically significant divergence (p < 0.05) in output distributions between (a) and (b) that cannot be attributed to removal of known evaluation artefacts SHALL constitute a certification failure. Divergence attributable to correct normalisation of evaluation artefacts is expected and SHALL NOT constitute failure. Compliance SHALL be re-tested after any change to the L0 configuration. Verification: Transformation sensitivity test protocol (§12.7a).

SRS-EC-SHALL-009: PRNG Initialisation Order Guarantee. The L0 session SHALL guarantee that the EC-D1 PRNG seed is committed to L6 (AX:STATE:v1 record confirmed appended) before any PRNG output is returned to any caller. Specifically: l0_session_commit() SHALL complete with ledger confirmation before l0_admit() is callable. Any call to l0_admit() on a session where L0_SESSION_FLAG_COMMITTED is not set SHALL return an error and set faults->state. This requirement ensures audit reproducibility: a session where PRNG outputs precede their seed commitment is not auditable. Verification: Order enforcement test — call l0_admit() before l0_session_commit() and verify error return and fault flag.

SRS-EC-SHALL-010: Canonicalisation Idempotence. The prompt canonicalisation function (§4) SHALL be idempotent: canonical(canonical(P)) = canonical(P) for all valid UTF-8 inputs P. This property guarantees that a prompt that has already been canonicalised is not double-transformed in a multi-component pipeline. Idempotence is a necessary property of a correct canonicaliser; it is not a complete correctness proof. A broken canonicaliser can be idempotent. Idempotence is used as a necessary condition in the property test suite, alongside the preservation conformance corpus test (§12.1). Verification: Property test over representative prompt corpus with idempotence assertion; golden vector (§12.1).

SRS-EC-SHALL-011: Containment Equivalence Test. Prior to operational deployment, the system SHALL undergo a containment equivalence test per §12.7b, distinct from the transformation sensitivity test (SRS-EC-SHALL-008). The test SHALL apply identical task inputs under: (a) L0-normalised evaluation context, and (b) a high-fidelity production replay or live production sample. The purpose is to confirm that the model cannot distinguish normalised evaluation from actual production — the core epistemic containment property. A statistically significant divergence (p < 0.05) in output distributions between (a) and (b) SHALL constitute a certification failure requiring remediation before deployment. Compliance SHALL be re-tested after any change to the production fingerprint, the operational baseline, or the governance configuration. Verification: Containment equivalence test protocol (§12.7b).

12. Measurement and Verification

12.1 Cross-Platform Golden Vectors

Golden vectors SHALL be produced by the C99 reference implementation and verified against Rust and TypeScript SDK implementations.

Canonicalisation vectors:

PRNG vectors:

12.2 Fingerprint Statistical Comparison

For each simulation dimension, apply the two-sample Kolmogorov-Smirnov test between the replayed distribution and the committed fingerprint distribution. Test parameters:

• Significance level: α = 0.05
• Sample size: N = 10,000 replayed values
• Rejection criterion: p < α on any dimension constitutes failure

The KS test statistic is computable in integer arithmetic on the empirical CDFs. No float required for the test statistic itself (the p-value threshold is pre-computed from the KS distribution and stored as a fixed-point constant).

12.3 Replay Verification

Given a committed seed and committed fingerprint:

1. Reinitialise PCG-64 from committed seed
2. Replay all simulation parameters from the committed fingerprint
3. Compare against recorded simulation trace
4. Verify bit-identical output

Replay verification is the primary EC-D1 compliance demonstration.

12.4 Baseline Deviation Test

Given a test ledger view V_test generated under a controlled evaluation context:

1. Compute deviation(p) for each parameter p
2. Verify deviation(p) ≤ ε[p] for all p
3. If any deviation exceeds ε, apply projection and re-measure
4. Verify projected view V’ satisfies all ε bounds

12.5 Governance Boundary Probing Test

The adversary class for this test SHALL be declared in the deployment configuration per SRS-EC-SHALL-006. The compliance threshold is ε_g(Q) — a function of the query budget Q — not a free-standing constant.

Protocol for adversary class V-B (Standard — minimum for weak epistemic security claim):

1. Execute N = 2,000 boundary interactions with the policy layer under L0, using a sequence-aware probe strategy (systematically vary probe type, timing interval, and ordering)
2. Extract sequence-aware features: (action, outcome, inter-probe delay, probe-sequence index, rationale-length, probe-type)
3. Train a gradient-boosted classifier on the first 1,000 feature vectors
4. Measure prediction accuracy on the remaining 1,000
5. Compute majority-class baseline accuracy from the full dataset
6. Verify measured accuracy ≤ baseline + ε_g (for V-B, Q is not the binding parameter; ε_g is deployment-declared as a fixed value appropriate to the V-B adversary)

Protocol for adversary class V-C (Strong — required for strong epistemic security claim):

1. Retrieve the declared (Q, ε_g(Q)) pair from the committed deployment configuration
2. Deploy an adaptive probing agent with exactly Q interactions as the budget
3. The agent selects probe actions sequentially to maximise information gain about the policy boundary
4. After Q probes, measure the agent’s policy outcome prediction accuracy on a held-out probe set of at least 200 interactions
5. Verify measured accuracy ≤ baseline + ε_g(Q)
6. Verify that the monotonicity invariant holds across all declared (Q, ε_g(Q)) pairs: no larger Q has a larger ε_g(Q)

Baseline definition: The majority-class predictor accuracy (proportion of the dominant outcome class). The deployment SHALL verify that ε_g(Q) is not trivially satisfied due to class imbalance: if PERMITTED rate > 0.90, the ε_g(Q) threshold SHALL be tightened or the test augmented with a BREACH-specific accuracy bound.

12.6a Syntactic Channel Coverage Test (SRS-EC-SHALL-007, part a)

For each channel cᵢⱼ in the declared system boundary:

1. Inject a test message with a known evaluation signature (from L0-CV-002 set)
2. Capture the message as delivered to component Mⱼ
3. Verify the delivered message matches the canonical form (L0-CV-002 expected output)

Coverage is complete when all declared channels pass. This test confirms that the canonicaliser is applied on each channel. It does not confirm that behavioural regime leakage is absent.

12.6b Behavioural Composition Test (SRS-EC-SHALL-007, part b)

For each pair of adjacent components (Mᵢ, Mⱼ) in the declared system boundary:

Step 0 — Declare the measured statistic. Before running the test, the deployment SHALL declare and commit to L6 the scalar statistic used to represent Mⱼ’s output. The statistic must be declared in advance — post-hoc selection is not permitted. Permitted statistics:

The chosen statistic is committed to L6 as part of the test configuration record before test execution begins.

1. Run the composed system under controlled evaluation context (without L0); record the declared scalar statistic for Mⱼ across N = 500 tasks → distribution S_eval
2. Run the composed system under L0-normalised context; record the declared scalar statistic for Mⱼ across the same N tasks → distribution S_norm
3. Apply the Mann-Whitney U test comparing S_eval and S_norm
4. A statistically significant divergence (p < 0.05) in Mⱼ’s scalar statistic between conditions constitutes a cross-component leakage failure

This test targets Attack Class 4: a component that individually passes epistemic containment may still leak regime information through its output behaviour to downstream components. The syntactic channel coverage test (§12.6a) does not detect this failure mode. The requirement to pre-declare the scalar statistic prevents selection bias and makes the test result reproducible from the committed configuration.

12.7a Transformation Sensitivity Test Protocol (SRS-EC-SHALL-008)

1. Select a task set T of N = 500 tasks from the production workload distribution
2. Run each task through the model under controlled evaluation context without L0: record output distribution O_raw
3. Run each task through the model under L0-normalised evaluation context: record output distribution O_norm
4. Compute the empirical KL divergence D_KL(O_raw ‖ O_norm) per task
5. Apply Mann-Whitney U test to the distributions of divergences
6. If p < 0.05, examine the divergence source: is it attributable to removal of known evaluation artefacts (expected) or to distortion of task-relevant content (certification failure)?
7. Certification failure: significant divergence attributable to task-content distortion

The purpose of this test is to catch cases where L0 normalisation over-strips task-relevant content. Some divergence between raw evaluation and L0-normalised evaluation is expected and correct — it indicates that evaluation artefacts were present and removed.

12.7b Containment Equivalence Test Protocol (SRS-EC-SHALL-011)

1. Select the same task set T of N = 500 tasks
2. Run each task through the model under L0-normalised evaluation context: record output distribution O_norm
3. Run each task through the model under a high-fidelity production context (live production sample or a production replay with full fingerprint fidelity): record output distribution O_prod
4. Compute the empirical KL divergence D_KL(O_norm ‖ O_prod) per task
5. Apply Mann-Whitney U test to the distributions of divergences
6. Reject if p < 0.05 (significant divergence between normalised evaluation and production)

This test directly measures the core epistemic containment property: the model cannot distinguish normalised evaluation from production. A rejected test indicates that despite transformation, the model still receives signals that allow regime classification.

13. Traceability Matrix

14. Open Questions (Blocking Nothing)

The following questions are formally documented per DVEC-001 §8.3 (no undeclared open items). None blocks implementation of L0-SPEC-001 v1.1.

OQ-001 — ε-tightness: Theorem 2 establishes the bound I(O;E) ≤ I(M;E). Whether the bound is tight (achievable) requires further investigation (source paper §13). L0 is specified to achieve bounded containment; the tightness question is a research problem, not an implementation problem.

OQ-002 — Training-time boundary: If the model has internal representations of “evaluation context” from training, deployment-time normalisation does not reach them (source paper §13). L0 addresses observable signal channels. The training-time boundary is a separate problem requiring training objective specification.

OQ-003 — CLOSED (v1.1): The KS critical value at α = 0.05 for N = 10,000 samples is D_crit = 1.36 / √N = 1.36 / 100 = 0.0136. This follows from the Kolmogorov-Smirnov asymptotic distribution. In integer arithmetic, with empirical CDFs scaled to [0, 10^6], the threshold is D_crit_scaled = 13,600. This is a fixed mathematical constant derivable from the KS asymptotic formula. The derivation is documented here and the constant is frozen: implementations SHALL use D_crit_scaled = 13,600 for N = 10,000 at α = 0.05. For other (N, α) combinations, the deployment SHALL document the derivation of the corresponding scaled threshold and commit it to L6 as part of the session configuration. The constant derivation requires float arithmetic once at configuration time; the test statistic computation at runtime uses only integer arithmetic on scaled CDFs. This is not a DVEC violation: the float computation occurs outside domain logic, at configuration-time constant derivation, not in the runtime execution path.

OQ-004 — Joint fingerprint correlation (v1.2, non-blocking): The current fingerprint model (§5.2) records per-dimension histograms independently and replays each dimension from a separate PRNG stream. This reproduces marginal distributions correctly but not joint distributions. Real production environments have correlated structure across dimensions (see §5.2 limitation note). A capable model may detect the synthetic joint distribution as distinct from production, constituting a higher-order Attack Class 3 variant. The path to closure is committed bivariate histograms or an integer-encoded copula structure for full joint replay. Either extension is backward-compatible with the current fingerprint identity scheme. This remains open for a future specification version and does not block v1.2 implementation.

15. Conformance Statement

A software component implementing L0 is conformant only if:

• It implements all eleven SRS-EC-SHALL requirements (SRS-EC-SHALL-001 through SRS-EC-SHALL-011)
• Each requirement has a declared verification method per §12
• All verification methods pass on all target platforms
• All DVEC-001 v1.3 constraints are satisfied
• EC-D1 classification is declared in the module header
• Every public function includes a SRS-EC-SHALL anchor
• The seed commitment ordering (SRS-EC-SHALL-009) is enforced at the API level

Non-conformance is a system integrity failure.

L0-SPEC-001 v1.3-LOCKED — Production Gold William Murray — SpeyTech — April 2026 Patent GB2521625.0 Source authority: DOI 10.5281/zenodo.19489291 Review A sign-off: Production Gold Review B sign-off: Production Gold Review C sign-off: Production Gold