Determinism
This page is intentionally forensic. The point is not to promise universal magic; it is to show what UPE means by determinism, what is verified today, and how a buyer can reproduce that evidence.
Latest verified snapshot
[UPE] determinism proof started at 2026-04-06 hash_run_1=0x64D24F0A3FB9921E hash_run_2=0x64D24F0A3FB9921E MATCH=true [UPE] SUCCESS
What determinism means in UPE
- Same inputs
- Same simulation path within the defined scope
- Same outputs within the same binary / runtime lane
- Replay, snapshot, and state hash support as part of the workflow
Guarantee levels
Level 1 — Repeated-run
Guaranteed signal: same binary, same input, same runtime setup, matching hashes across repeated runs.
Level 2 — Cross-compiler
Observed and logged, but not universally guaranteed as bit-identical across all compiler implementations.
Level 3 — Cross-platform
Not marketed as universally bit-exact by default; each platform should be validated through its own proof lane.
What you verify
Run-to-run stability
Same binary, same seed, same output hash within the proof lane.
Replay consistency
Replay outputs can be inspected rather than treated as a black box.
Snapshot restore parity
Restored scenes should return to the expected reference path within the declared scope.
Hash comparison
CRC64 state hashes make the proof surface concrete and reviewable.
Reference demos
Local reproduction
python scripts/run_buyer_determinism_proof.py # or manually cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DUPE_BUILD_TESTS=ON -DUPE_DETERMINISTIC=ON cmake --build build --parallel tools\run_determinism_proof.bat build
Evidence links
- `proof/RUNS/determinism_*.log` — summary proof logs with extracted hashes.
- `det_run1_*.txt` and `det_run2_*.txt` — repeated-run outputs for comparison.
- `gcc_output.log` and `clang_output.log` — compiler-specific drift visibility artifacts where captured.