M4 Complete — Temporal Determinism, DB Boundary Validation & Unified Verification Harness

Kernel Milestone: 4 of 6 Previous: Milestone 3 — Monetary Domain Partition & Financial Kernel v2.2 (v5.18.0) Next: Milestone 5 — Boundary Propagation

System Impact
-------------
Ledger integrity:         strengthened
Ledger mutation:          unchanged
Tenant isolation:         unchanged
Financial immutability:   unchanged
State machine:            unchanged
Breaking changes:         none
Replay determinism:       preserved

Invariant Change
----------------
Temporal values crossing the DB/domain boundary are now typed as strings
throughout the financial domain type system, eliminating the driver's
timezone-sensitive Date coercion path. DB query results are validated against
Zod schemas at the service boundary before any mapper executes, with compiler
and CI enforcement preventing regressions.

Why This Matters

M4 addresses two categories of silent failure that the original codebase tolerated: temporal ambiguity and unvalidated DB results. The database driver coerces date and timestamp columns to JavaScript Date objects using server local time — a source of timezone-dependent behaviour that is invisible in tests but surfaces in production. By declaring all temporal fields as string in the financial domain type system, the compiler rejects any mapper that accepts a driver-coerced object without explicit normalisation. This converts a class of silent runtime bugs into compile-time errors.

The DB boundary work closes a different gap: prior to M4, query results were accessed with no runtime verification of the column shapes returned. A schema migration adding or renaming a column would silently produce missing values in mapped objects, surfacing only as display errors or incorrect calculations. The Zod schema layer validates every result row before the mapper executes. Unexpected columns fail immediately rather than passing through. The satisfies keyword on the mapper return replaces an unsafe cast, allowing the compiler to verify mapper completeness against the domain type.

AX-BND-001 is closed in M4 at the standard and enforcement level: the runtime schema layer, compiler-checked mapper pattern, and CI boundary gate are all delivered, with the invoice service as the reference implementation. M5 propagates this closed pattern across the remaining services. The reference implementation demonstrates the three-layer enforcement model: Zod runtime validation, TypeScript compiler checking via satisfies, and a CI gate that scans service and route files for unvalidated boundary crossings.

Threat Closure

Proof Anchors

Compiler layer — AX-TMP-001:
  Domain type system: kernel temporal fields now cross the DB/domain boundary
  as strings rather than Date, with compiler enforcement surfacing any mapper
  that attempts to pass driver-coerced temporal objects through unchanged.

Compiler layer — AX-BND-001:
  Invoice service mapper: `satisfies` domain type check — compiler verifies
  every field against the domain type; unsafe cast removed.

Runtime layer — AX-BND-001:
  Boundary schemas with .strict() validate all invoice query results at the
  service boundary before mapper execution. Unexpected columns fail
  immediately as P1.

CI layer — AX-BND-001:
  Boundary CI gate scans service and route files for query result accesses
  without a nearby schema parse call. Exits non-zero, blocking build.

Security Posture Change

Prior to this release, temporal field handling and DB result shapes were both Class O guarantees — dependent on developer discipline, driver behaviour, and TypeScript generics that the runtime did not enforce. A driver update, a schema migration, or a timezone misconfiguration could silently corrupt financial values with no observable error at the point of failure. Both are now Class M: the compiler enforces temporal typing, Zod enforces boundary shape, and the CI gate prevents regressions.

Unified Verification Harness

scripts/run-harness.sh is the single entry point for all kernel verification gates. Previously, the eight verification scripts had to be run individually with no consolidated output. The harness runs them in dependency order — compiler first, database gates last — and produces a summary table showing each gate’s pass/fail status and elapsed time. Exit 0 means all gates passed.

bash scripts/run-harness.sh              # all 8 gates
bash scripts/run-harness.sh --fast       # skip database gates (no DB required)
bash scripts/run-harness.sh --sql-only   # database gates only (post-migration)

Verification Record

Post-commit:
  V1  pnpm build — clean, 0 TypeScript errors
  V2  Boundary CI gate — PASS, 0 violations
  V3  Ordering determinism gate — PASS, 0 violations, 113 files scanned
  V4  Constraint coverage check — PASS, 74 constraints, 100% coverage
  V5  Axiom coverage verifier — PASS, 21 delivered axioms, 0 violations
  V6  Double-entry conservation — PASS, 6/6 checks
  V7  Monetary constraints — PASS, 12/12 checks
  V8  RLS policy symmetry — PASS, 5/5 checks
  Full harness: 8/8 gates passed — mathematically closed

M4 Axiom Delivery Record

M4 Closure Statement
--------------------
M4 is now closed. The milestone's five axioms establish deterministic identity,
temporal representation, retry semantics, query ordering, and validated DB
boundary entry into the financial domain. Together they remove the remaining
silent provenance and replay ambiguities left open after M3.

Operational Impact

Temporal safety. Every temporal value from the database is now a string at the type boundary. No mapper can silently accept a timezone-coerced object — the compiler flags it at build time.

Boundary failures are loud. A schema mismatch at the DB boundary produces an immediate 500 identifying the exact field that failed. There is no silent corruption path.

Single harness command. One command verifies the entire kernel — 8 gates covering compiler output, static analysis, constraint coverage, axiom registry integrity, double-entry conservation, monetary invariants, and RLS symmetry — with a consolidated pass/fail summary.

Ledger readiness. With M4 complete, the query layer is deterministic, temporal values are normalised, and service boundaries are validated. The provenance foundations required for the M6 cryptographic audit trail are in place.

Kernel Status