Provable Simulation as Verifiable Decision Infrastructure
1The problem: decisions need simulation you can trust
A physics engine that renders a plausible-looking scene is a solved problem. A simulation whose output you are willing to act onis not. The moment a simulation informs a real decision — engage or hold, ship or halt, trust the sensor or not — three questions become unavoidable:
- Reproducibility:if we run the same scenario again, on another machine, do we get the same answer?
- Attribution:when the simulation and reality diverge, is it model error, a real fault, or tampering?
- Defensibility:can we prove, after the fact, what the system computed and why?
For most simulation stacks, the honest answer to all three is "not really." That gap is not a UX problem; it is the difference between a demo and an instrument.
2Why floating-point simulation fails the trust test
IEEE-754 floating-point results depend on compiler flags, fused-multiply-add availability, instruction ordering, and thread scheduling. The same code can produce slightly different last bits on a different CPU, and those tiny differences compound over a simulation's timeline. Three consequences follow:
2. Drift masks faults.If the prediction wanders on its own, you cannot set a tight tolerance between predicted and measured state — because you can't tell model drift from a genuine anomaly. You loosen the threshold, and the monitor goes blind exactly when it matters.
3. Nothing to sign.If the result isn't bit-stable, there is no canonical value to hash, log, or certify. "The simulation ran" is a claim, not evidence.
Determinism is often treated as a nice-to-have for lockstep multiplayer. For decision-grade simulation it is the foundation everything else stands on.
3Why replay is necessary — but not sufficient
Record-and-replay is the first thing a serious simulation stack adds: capture the seed and ordered inputs, and you can reproduce a run. This answers "what happened?" and is essential for debugging and audit. But it has two limits. First, on a float engine, replay is only reproducible on the samebinary — it is not a cross-platform proof. Second, and more fundamentally, replay only tells you about the timeline that actually occurred. It cannot answer the question decision-makers actually ask:
Answering that requires branching the present into alternative futures. Replay is a line; decisions live in a tree.
4Why fork is the missing layer
If a simulation is deterministic and can snapshot/restore its full state, then from any live moment you can forkit: take a snapshot, run branch A under one plan, restore, run branch B under another, and so on. Each branch ends in a state you can score (how good is this outcome?) and address by hash (which exact future is this?). Because the core is deterministic, the same base plus the same plan always yields the same branch — so the set of options you produce is reproducible and defensible, not a one-off Monte-Carlo artifact.
This is the difference between monitoring and decision support:
| Capability | Classic digital twin | Berk DT |
|---|---|---|
| Live state | Monitor | Monitor + Shadow Twinresidual check |
| Past | Replay | Replay + tamper-evident audit chain |
| Future | — | Forkable, scored, hash-addressed futures (Advisor) |
The Advisorforks the present into course-of-action branches and ranks them; the Shadow Twinruns a deterministic copy beside the real asset on the same inputs and raises an alarm the first frame the measured state departs from the prediction. Both are the operational face of the same deterministic core.
5Why hash is the binding that makes it provable
A deterministic run produces, at every step, a 64-bit state_hash — a fingerprint of the full carry-over state. This single value does an enormous amount of work:
- Cross-platform proof:two machines that agree on the hash agree on every bit of the simulation. CI checks this on Linux, Windows, and macOS on every change.
- Tamper-evidence:a run report can be sealed with a metadata-seeded hash chain; altering any frame, parameter, or the seal itself breaks verification. The report is proven not by a signature but by re-runningthe scenario — physics replaces the notary.
- Addressable futures:each forked branch is identified by its result hash, so a course of action can be cited, compared, and reproduced exactly.
- Divergence forensics:comparing two per-frame hash traces pinpoints the first frame where two runs (or a run and reality) parted ways.
6How Berk DT delivers all four
A single Rust core, consumed through a C-ABI (plus Unity, Unreal, and WebAssembly bindings), provides:
- Deterministic:all simulation math is fixed-point (Q32.32) integer arithmetic; trigonometry via CORDIC, square root via a deterministic integer method. No IEEE float touches the state that feeds state_hash.
- Replayable:seed + ordered input + periodic hash reproduce a run exactly and detect divergence; full snapshot/restore serializes the carry-over state to bytes and back, bit-identically.
- Forkable:the Advisor (deterministic what-if tree) and rollback netcode both build on the same atomic snapshot path — a branch can never corrupt its base.
- Provable:cross-platform golden-hash CI, a tamper-evident audit report tool, a divergence debugger, and formal (TLA+) models of the concurrency and decision logic.
7What this unlocks
Defense — decision safety
Course-of-action analysis where the option space is provable rather than a one-off scenario; after-action analysis where a field event can be reproduced bit-for-bit (given deterministically logged inputs) and alternative decision branches explored; air-gapped deployment with no external dependency; auditable autonomy where every decision carries an epistemic state, authority level, and provenance hash.
Industry — operational optimization
An operational future tree for what-if planning (shutdown optimization, supply-chain forks); a shadow twin for predictive maintenance and anomaly/tamper detection with a threshold tight enough to be useful; reproducible audit of every run.
Robotics / AI — sim-to-real verification
Reproducible training and evaluation; deterministic sensor (LiDAR/range) simulation for closed sensor-loop replay; a complementary "ground-truth execution layer" beside GPU training stacks. Train anywhere; execute provably.
8What determinism does notguarantee
The credibility of this entire position depends on being precise about its limits. Overclaiming here is how you lose a technical audience — so we are explicit:
Performance figures are advisory.They are single-machine measurements; no certified worst-case execution time (WCET) is claimed in public material.
No formal certification yet.DO-178C / ISO 26262 and similar are not held today. The core is designed to produce the evidence artifactsthose processes require — hash logs, replay certificate, divergence report, audit trail, requirement traceability, TLA+ models — and to keep the certification path open (stable-only safety core, documented toolchain alignment). "Aligned with" a standard is a claim we do not make without the evidence.
Fork is not free search.The Advisor forks and scores branches deterministically; producing goodoptions still depends on the scoring function and the branch-generation strategy. It is a reproducible evaluation substrate, not an oracle.
These are not weaknesses to hide; they are the boundary that makes everything inside it trustworthy. The strongest version of this pitch is the honest one.
9Reproduce it yourself
Every claim above is backed by artifacts that live in the repository and re-run on demand:
# Determinism: the golden hash is bit-identical on every platform cargo test --release --test determinism_dynamics # Forensic report: generate a run, then re-verify it by PHYSICS (not a signature) cargo run --bin berk-audit -- run cargo run --bin berk-audit -- verify report.json # Scale: at 10,001 bodies, two different broadphases produce the SAME hash cargo test --release --test scale_10k -- --ignored --nocapture # ~1050 tests, 0 failures cargo test
Live, in-browser proofs: the Hash Consensusdemo (the same sim on every device yields the same fingerprint), the CPU ≡ GPU ≡ browseridentity demo, and the Time Traveler (seal the future, then verify it live).
Conclusion
Berk DT is not, at its core, a physics engine, a digital twin, or netcode — those are surfaces. It is a deterministic, auditable, forkable reality engine: an infrastructure for making decisions you can prove. Told as a physics engine, it competes on features it does not need to. Told as verifiable decision infrastructure, it opens a category where the alternative is trust without proof — and in defense, industry, and safety-critical robotics, trust without proof is not enough.