Kernel M4 Phase 0 — Sequential Document ID Correctness (AX-CON-001)

Kernel Milestone: M4 of 6 — Active Previous: Milestone M3 — Monetary Domain (v5.18.0) Next: M4 Phase A — Temporal Determinism & Schema-Derived Validation

System Impact
-------------
Ledger integrity:         strengthened
Ledger mutation:          document number issuance is now atomic
Tenant isolation:         unchanged
Financial immutability:   unchanged
State machine:            unchanged
Breaking changes:         none
Replay determinism:       preserved

Invariant Change
----------------
Document number issuance is now enforced atomically at the database layer via
row-level locking. Duplicate identifiers are structurally impossible.
Concurrent issuance may commit out of order, but the numeric sequence
remains strictly monotonic.

Why This Matters

Every invoice and quote carries a document number that is visible to clients, referenced in correspondence, and must be sequential for UK compliance purposes. Before this release, numbers were generated using a pattern that was vulnerable to a race condition: two concurrent requests could read the same current maximum and produce identical numbers. This was not a theoretical risk — any period of concurrent usage could trigger it.

This release closes that threat entirely. Number issuance now happens inside a single atomic database operation that acquires a row-level lock, increments the counter, and returns the issued number — all within the same transaction as the document insert. No two requests can receive the same number. Sequence gaps may occur if a transaction rolls back after issuance, but duplicate identifiers are structurally impossible. The invariant is mechanically enforced, not operationally managed.

This is the first axiom delivered under Milestone M4 (Provenance), which establishes the correctness of all identifier and sequencing behaviour across the kernel.

Sequential Document ID Correctness

The Previous Approach

The previous approach read the current highest number and added one. Under concurrent load — two users creating invoices simultaneously, or a retry race during a slow request — both reads could return the same value, producing two documents with identical numbers.

Identical document numbers are not merely inconvenient. They create ambiguity in client correspondence, break audit trails, and in some interpretations conflict with HMRC’s requirement for sequential VAT invoice numbering.

The Kernel Fix

A dedicated sequence table now holds one row per document type per organisation. Issuance is performed by a single atomic database operation that acquires a row-level lock, increments the counter, and returns the issued value. No two concurrent requests can receive the same number.

The sequence table is seeded at the database layer and all existing organisations received correct starting values as part of this release. No manual intervention is required.

Enforcement layer: database (migration 080) + runtime (sequence generator) Proof anchor: migration 080, sequence generator

Axiom Registry

AX-CON-001 (Sequential Identifier Correctness) is now delivered in the kernel axiom registry at v1.6. The axiom requires dual-layer enforcement — database and runtime — both of which are now satisfied.

Threat Closure

Kernel Axiom Registry — v1.6

This release includes a full audit and correction pass on the kernel axiom registry. Eight structural defects were identified and corrected, bringing the registry to a mathematically closed state:

• Milestone M4 status advanced from pending to active
• Class M dual-layer enforcement doctrine applied consistently across all axioms
• Class O axioms corrected to use the appropriate enforcement schema
• Milestone deliver lists reconciled with actual axiom status
• All proof anchors verified as mechanical (no operational claims cited as enforcement evidence)

The registry now satisfies its own governance rules across all six milestone gates.

Changes Delivered