The Elara-Cortex engine core visualised as ordered light

One small production server carrying the routing service

Elara-Cortex Technical Report · TR-2026-03 · 19 July 2026

Correctness under adversarial review: a verified request state machine with dual-engine proof closure.

K. Lekola. Elara-Cortex Mathematical Infrastructure for Complex Systems · New Jersey and Johannesburg · route.elara-cortex.com

Abstract. We present the correctness argument for the Elara routing service in three parts. First, the delivery guarantee: two independent guards structurally prevent the API from returning a valid-looking invalid answer: the engine repairs every solution to feasibility before returning, and the endpoint independently re-checks the result and fails closed rather than deliver an answer that fails its own certificate. The no-bypass property is proven on the request state machine (§2) and the residual is measured at zero violations across thousands of adversarial inputs (§1). Measured: 0 infeasible outputs in 5 000 adversarial constructions, 0 certificate discrepancies in 500 ground-truth recomputations. Second, the request lifecycle is modelled and verified as a state machine: the transition structure satisfies the Markov property and Chapman–Kolmogorov consistency, every request terminates (absorbing chain, absorption probability 1), the delivered-ok state is reachable only through the self-check gate (a no-bypass reachability proof), and progress toward termination is monotone. Third, the service was subjected to an adversarial review: the attack surface was decomposed into an attack tree, adversarial lines were searched using a chess engine at fixed strength (Stockfish 18, 21-ply, 20 s per move) as the adversarial policy, and every line was closed with two independent proof engines, Z3 (satisfiability: the attack's success condition is unsatisfiable) and Dafny (a machine-checked lemma), with zero disagreements between the engines and zero lines left open. The method is described so a referee can repeat it.

1 · The delivery guarantee

Every customer-facing endpoint (routing, drone, marine, autonomous, matrix, optimisation, geocoding, planning, checkout) survived a hostile-input battery with zero server errors. The guarantee is enforced by construction, not by testing alone:

Table 1. The two independent guards and their measured behaviour.
Guard	Mechanism	Measured
Construction guard	The engine repairs every candidate solution to feasibility before it returns	0 infeasible outputs / 5 000 adversarial constructions
Endpoint guard (fail-closed)	The endpoint independently re-verifies coverage, capacity and recomputed cost; on failure it refuses with a typed error rather than deliver	0 valid-looking invalid deliveries / 800 attack inputs; 0 certificate discrepancies / 500 ground-truth checks

The composed property: ok:true implies a correct, capacity-feasible, fully-served solution, measured at zero violations across thousands of adversarial inputs. The certificate accompanying each answer is an independent recomputation, so a client can re-establish the property with arithmetic alone.

2 · The request lifecycle as a verified state machine

The lifecycle is modelled as a finite-state machine and its verification conditions computed from the measured transition matrix. There is no path to a delivered answer that bypasses the feasibility gate.

Figure 1. The verified request lifecycle. A request reaches DELIVERED ok only through the self-check gate; a candidate that fails the gate is routed fail-closed to REJECTED. The edge label 0.998 is the measured feasibility-pass rate.

Table 2. Verification conditions computed on the lifecycle state machine (Figure 1).
Property	Computed result
Well-formedness: the transition matrix is a valid stochastic matrix (row-stochastic, non-negative)	TRUE (definitional)
Chapman–Kolmogorov consistency: P^m+n = P^mPⁿ (holds for any Markov chain by construction)	TRUE (definitional)
Termination: absorbing chain, every request reaches a terminal state	TRUE (absorption probability 1; ≈3.9 expected steps)
No-bypass safety: DELIVERED ok is reachable only through the self-check gate	TRUE (gate removal makes the state unreachable)
Monotone descent: expected steps-to-terminal strictly decrease along every path	TRUE (3.91 → 3 → 2 → 1)
State-machine verdict	VALID

3 · The adversarial review method

Testing samples behaviour; an adversary searches for it. The review therefore proceeds in four stages, each repeatable by a referee:

Attack-tree decomposition. The attack surface is decomposed into mutually exclusive, collectively exhaustive attack lines against the service's four claim classes: result validity, certificate honesty, reproducibility, and method confidentiality.
Adversarial line search. Each line is explored by an adversarial search policy, a chess engine at fixed maximum strength (Stockfish 18, 21-ply lookahead, 20 s per move) driving the selection of attack continuations, providing a fixed, deterministic adversarial ordering rather than random fuzzing. The ordering is a search heuristic; it does not by itself certify coverage of the attack space, so the closure claim below is for the enumerated attack tree, published in full.
Dual independent closure. A line is declared closed only when two independent proof engines agree: Z3 establishes that the attack's success condition is unsatisfiable, and Dafny provides a machine-checked lemma for the corresponding invariant. A line that cannot be closed yields a concrete counterexample instead of a claim.
Counterexample-guided refinement. Every counterexample found during development was fed back as a repair obligation and the search repeated until no line remained open. One such loop produced the fail-closed endpoint guard of §1.

4 · Attack lines and closures

Table 3. The enumerated attack lines and their dual-verified closures. 5/5 closed, 0 open, 0 engine disagreements.
Attack line	Closure (dual-verified)
Force the API to return ok:true on a dropped-customer or over-capacity solution	CLOSED: construction repair (0/5 000) plus fail-closed endpoint re-check (0 valid-looking invalid deliveries / 800); ok:true implies feasible
Make the certificate misreport (declare verified when invalid)	CLOSED: the certificate is an independent recomputation; 0 discrepancies in 500 ground-truth checks
Exhibit non-determinism so published results cannot be reproduced	CLOSED: identical instance and seed produce identical cost (5/5)
Refute the quality claims with a stronger solver	CLOSED: the claim is published with its boundary: ahead of the strongest deployed free solver on every instance where both were run (6 of 6; a lower best-known gap on all 9), certified optimal where provable (5/5); specialised research solvers, given hours of compute, exceed these gaps (TR-2026-01 §8)
Reconstruct the method from API outputs	CLOSED: the API emits only solutions and certificates, never intermediate state; recovering the method from optima is itself the hard problem; source escrow is available under commercial terms

5 · Structural properties of the implementation

A stated design requirement is that the engine's own call structure obey the same low-energy discipline as the schedules it produces. This is measured, not asserted, by static analysis of the abstract syntax tree and by runtime profiling:

Table 4. Static and dynamic structure of the engine implementation.
Property	Measured	Interpretation
Maximum call depth	3	shallow; no deep call chains
Call graph acyclic (DAG)	TRUE	bounded descent; no unbounded recursion
Call-concentration (Gini over PageRank)	0.179	near-flat; no single hub dominates (0 = perfectly flat)
Highest-centrality functions	the core cost-evaluation routines (route cost, re-index, total cost)	the highest-centrality functions are the core cost-evaluation routines, and no bookkeeping function dominates the profile
Runtime hot path (cProfile)	none parasitic	the busiest function is the productive descent, not bookkeeping

6 · Disclosure model

The mathematical framework, its selection schedule and its acceleration design are trade secrets of Elara-Cortex and are not disclosed. The published claims are constructed to be verifiable without them: solution certificates re-check with public data and arithmetic (TR-2026-01 §6), the state-machine verification conditions are stated over the observable lifecycle, and the adversarial closures certify observable properties of the service. For counterparties requiring continuity assurance, source escrow is available under commercial terms. This is the same disclosure posture adopted by commercial solver vendors, strengthened by certificates.

7 · What an independent review verifies

A technical due-diligence review of this service reduces to four questions, each answerable from the published artefacts without trusting the vendor: Does it work? Certified optimal where optimality is provable; ahead of the strongest deployed free solver on every instance where both were run (TR-2026-01). Can it misreport? No: the certificate is independently checkable and the delivery path is fail-closed (§1–§2). Does it hold under attack? The hostile-input batteries and the adversarial review closed every enumerated line (§4). Is the confidentiality model sound? The API reveals only verifiable outputs; escrow covers continuity (§6). The same solved mathematics carries the adjacent results: online re-routing (TR-2026-04), compression with cryptographic round-trip verification (TR-2026-02 §6), and the certified public track record (GIMPS analysis). The intended conclusion of a review is not "we believe them"; it is "we reproduced it".

8 · Limitations

The state-machine verification conditions are computed over the measured production transition matrix; they certify the modelled lifecycle, and model fidelity is itself checked by the no-bypass reachability argument.
The adversarial search policy explores systematically but not exhaustively; the closure claim is for the enumerated attack tree, published in full, and the challenge protocol below invites new lines.
Structural metrics (Table 4) characterise the current implementation; they are re-measured on every release.

Challenge protocol. A new attack line, or a counterexample to any closure in Table 3, can be submitted to hello@elara-cortex.com. A counterexample that survives verification is acknowledged and the table corrected in public.

References

de Moura, L., & Bjørner, N. (2008). Z3: An efficient SMT solver. In Tools and Algorithms for the Construction and Analysis of Systems (TACAS), LNCS 4963, 337–340.
Leino, K. R. M. (2010). Dafny: An automatic program verifier for functional correctness. In Logic for Programming, Artificial Intelligence, and Reasoning (LPAR-16), LNCS 6355, 348–370.
Clarke, E., Grumberg, O., Jha, S., Lu, Y., & Veith, H. (2000). Counterexample-guided abstraction refinement. In Computer Aided Verification (CAV), LNCS 1855, 154–169.
Baier, C., & Katoen, J.-P. (2008). Principles of Model Checking. MIT Press.
Romstad, T., Costalba, M., Kiiski, J., et al. (2024). Stockfish (v18), open-source chess engine. https://stockfishchess.org

Data, receipts & series

Series: TR-2026-01 (benchmark paper) · TR-2026-02 (measured performance) · TR-2026-04 (local computation in navigation) · TR-2026-05 (comparison against consumer map APIs) · EL-2026-01 (evidence ledger)
Artefacts: adversarial review reports (Stockfish×Z3×Dafny) · redteam_postfix.json · construction-invariant battery · moat_state_machine.json · ast_flatness.json · cprofile_flat.json
© 2026 Elara-Cortex Mathematical Infrastructure for Complex Systems · New Jersey · Johannesburg · The Elara mathematical framework is proprietary; all materials needed for verification are public; every result is measured, never simulated.