Reproducible Builds Solved 'Works on My Machine'. CAD Never Got the Memo. Until Now.

A flagship article from the NeuroCAD project. Audience: aerospace QA, regulators, CAD vendors, technical leaders.

---

The aerospace audit nobody talks about

Imagine you are an FAA Designated Engineering Representative reviewing the design dossier for a new wing rib. The supplier hands you a CAD file, a STEP export, a printed PDF of the feature tree, and the engineer’s name. You ask one question: “Can you recreate this part, exactly, on a different machine, six months from now, with no human in the loop?”

The honest answer, across every commercial CAD vendor on the planet, is no. Not “yes with caveats.” Not “mostly.” No.

• Reload the same file on a different OS and the GPU may pick a different floating-point summation order, shifting a fillet by sub-micron amounts.
• Replay the same feature history under a newer version of the kernel and a tessellation upgrade silently changes the mesh.
• Re-import the STEP and the topology IDs are renumbered because the importer walks faces in hash-map order.
• Open the file in 2030 with a kernel from 2024 and you may not get the same body back at all.

Software engineers solved this. The Reproducible Builds project¹ showed that an entire Linux distribution (Debian) could be built byte-for-byte identically on independent hardware, by independent rebuilders, years apart. As of 2023, 91% of 709,816 Nixpkgs packages were bitwise reproducible². The trick wasn’t magic. It was discipline: strip timestamps, fix locales, pin tool versions, audit every source of non-determinism, and make a deterministic build a first-class acceptance test.

CAD never got that memo. The geometry community treats “the file opens and looks right” as good enough. For a regulated industry building things that fly, carry patients, or hold pressure, that is a scandalous standard.

NeuroCAD is changing it.

---

What deterministic session replay actually means

NeuroCAD is an SDF-native CAD kernel: instead of a B-rep made of stitched analytic faces and edges, every body is a signed distance field — a function from 3D space to a real number, computed on demand from a graph of operations. A “session” is the recorded sequence of those operations: sketch this, pad that, fillet this edge, suppress this hole, run this Boolean.

Deterministic session replay is the formal claim that if you record the session and replay it on a clean kernel, you get the same SDF, sampled at every point in space, with the same parameter IDs, the same Merkle root, and the same byte-level serialization — across machines, operating systems, GPU vendors, and time.

That is the audio-engineering claim. A digital audio workstation guarantees that a project file rendered today and ten years from now produces the same WAV. The artist’s intent is preserved exactly. CAD has no equivalent. NeuroCAD is the first kernel to write down that contract and test it.

---

The 12-point acceptance contract

The discipline boils down to twelve testable properties³. Each has a canonical citation; together they form what we call the Replay Acceptance Contract:

1. Byte-identical session replay. Same log, same SHA-256 hash, every platform.¹
2. IEEE-754 strict mode. No FMA contraction, no fast-math, bit-identical fp64 across compilers.⁴⁵
3. GPU↔CPU agreement under reductions. Parallel sums match scalar sums or strict mode is enforced.⁶⁷
4. Zero environment leakage. No timestamps, no PIDs, no $USER, no $HOME. diffoscope finds zero deltas.⁸
5. Concurrent worker reorder tolerance. Multi-worker session deterministic regardless of OS scheduling.⁹¹⁰
6. Log compactness and shelf life. A 1h session log fits in 50 MB and replays after 6 months of dormancy.¹¹
7. Subset replay. Replaying nodes {A,B} from session {A,B,C,D} yields the same A,B state.¹⁰
8. Fuzz determinism. A thousand fuzz-generated sessions all replay identically twice in a row.
9. Cross-machine replay. Workstation session replays bit-identically on a server VM.²
10. E-graph rewrite determinism. Equality saturation hits the same iteration count and canonical form.¹²
11. Cryptographic content addressing. Each segment named by SHA-256; Merkle root stable.¹³¹⁴¹⁵
12. 24-hour soak canary. Continuous record→replay loop runs for a day with zero divergence.

Twelve tests. Each one ruthlessly mechanical. Each one falsifiable. Each one is a property that any CAD vendor could implement if they were willing to write the contract down.

This is not a research aspiration. NeuroCAD already pins replay-determinism contracts in code — spatial replay, drafting replay, surface replay, brush-history replay, replay manifest boundary, server-side replay-from-empty — and the wider 12-point soak/cross-machine/e-graph battery is the next milestone (see honest status footer).

---

Why CAD vendors never built this

Three reasons, all historical, none defensible in 2026:

One: B-rep topology is fragile. When your model is a stitched mesh of analytic faces, reordering an edge list is enough to break feature references. CAD vendors learned to live with non-determinism because their data model couldn’t tolerate the kind of canonicalization a hash needs. SDF kernels don’t have that problem — there are no edges to renumber. The whole representation is a function.

Two: GPU performance pressure. The default mode for every modern shader compiler is “trust me, it’s faster.” Fast-math reordering, fused multiply-add, parallel reductions in nondeterministic order. NVIDIA’s own precision whitepaper⁵ is a 30-page warning about how easy it is to lose reproducibility for a 5% speedup. CAD vendors picked the speedup every time. NeuroCAD does the opposite: strict mode is the default, fast mode is opt-in, and any divergence is a test failure.

Three: nobody asked. Until aerospace started losing audits and the FDA started writing software-validation guidance for medical devices, “reproducible CAD” wasn’t a sales feature. It was an engineering virtue with no market. That has changed. Boeing’s MCAS post-mortems, the GE jet engine recall traceability work, the EU Digital Product Passport regulation — all of these put a price tag on provable reproducibility.

NeuroCAD is positioned to set that price.

---

What makes this publishable, and to whom

This is not an incremental improvement. This is a discipline import. The Reproducible Builds project — Lamb & Zacchiroli’s 2021 IEEE Software paper¹⁶, the Debian dashboard, the Nixpkgs case study² — gave software a vocabulary for reproducibility. We are porting that vocabulary into geometric modeling.

That makes this publishable in three audiences at once:

• ACM SIGGRAPH / Transactions on Graphics: Geometric modeling research has never had a reproducibility benchmark. We are providing one. The paper has formal definitions (hash chains, MVCC snapshot isolation¹⁷, floating-point non-associativity⁶), an implementation, and a 12-point evaluation rubric anyone can run.
• ISO TC 184/SC 4 working paper: STEP AP242 and the broader Industry 4.0 standards stack already cover geometric interchange. They do not cover reproducibility. We propose a working paper extending AP242 with a “Replay Determinism Conformance Class” — a checklist any vendor can declare against, the way we declare against IEEE 754 today.
• Engineering procurement: For aerospace, medical, and defense buyers, this is the headline. “First CAD kernel with a deterministic-replay acceptance contract.” Buyers have been asking for that property informally for twenty years. We are the first vendor to offer it as a contract, not a hope.

---

The bigger picture: an evidence graph for geometry

Replay determinism is the floor, not the ceiling. The deeper claim is that every artifact NeuroCAD produces — every SDF, every mesh, every BOM, every drawing — is reachable from a content-addressed history DAG and verifiable against an evidence graph.

If a regulator asks “show me which test verifies that this fillet has the right radius,” NeuroCAD walks the evidence graph and points at a test. If a manager asks “what changed between revision 12 and revision 13,” NeuroCAD diffs two Merkle roots and produces a structurally meaningful answer rather than a binary file diff. If a customer asks “can you reproduce this exact part on your machine?”, the answer is yes, and the proof is a SHA-256.

That entire stack rests on the 12-point Replay Acceptance Contract. Without it, the rest is wishful thinking.

---

Call to action

We are publishing the contract together with an open invitation to ISO TC 184/SC 4 working group conveners, to CAD vendors building next-generation kernels, to aerospace and medical-device QA teams: co-author the working paper with us. The 12 tests are mechanical. The agreement is the hard part.

Reproducible Builds took a decade of patient, unglamorous engineering to turn “works on my machine” from a meme into a solved problem. CAD has the same opportunity, the same techniques, and a much smaller community to convince. NeuroCAD is the first kernel to put up the spec. We invite the rest of the field to argue with it, improve it, and adopt it.

The audit you cannot pass today is the one you can demand tomorrow.

---

Status

What NeuroCAD ships today:

• A replay module in the public API (~1.1k LoC) implementing replay schema versions, scheduler-policy profiles, recorded session bundles, and SHA-256 receipt computation.
• A4 (history-DAG joint replay) fully specified as one of six axioms in the dual-kernel agreement contract (REV11.4).
• Pinned tests in tree: spatial replay, drafting replay, surface replay, brush-history replay, replay-manifest boundary, query replay determinism, slice07 query/replay/export integration, solver slice03 replay-safe receipts and diagnostics, server-side replay-from-empty, L3 state003 replay recovery.
• IEEE-754 strict mode is the default for all kernel arithmetic (no fast-math, no FMA contraction in hot paths).

What is proposed but not yet executed:

• The full 12-test soak battery (especially #6 24h-soak, #9 cross-machine, #3 GPU↔CPU strict-mode agreement at scale, #10 e-graph rewrite divergence canary).
• diffoscope-style binary-deltas tooling for session bundles.
• ISO TC 184/SC 4 working-paper submission.
• Public benchmark corpus (a “Reproducible Builds for CAD” dashboard analogous to the Debian one).

Everything in this post that says “we test” or “we verify” without an explicit “proposed” tag refers to mechanisms already pinned in the code. Everything in the standards pathway section is forward-looking and explicitly flagged as such.

---

Footnotes

1. Reproducible Builds project. https://reproducible-builds.org/. ↩ ↩²

2. Reproducible Builds Nixpkgs case study, 2023 (709,816 packages, 91% bitwise reproducible). https://reproducible.nixos.org/. ↩ ↩² ↩³

3. NeuroCAD internal test catalog, twelve replay-determinism tests with primary citations. ↩

4. IEEE 754-2019, IEEE Standard for Floating-Point Arithmetic, §3.1. ↩

5. N. Whitehead and A. Fit-Florea, Precision & Performance: Floating Point and IEEE 754 Compliance for NVIDIA GPUs, NVIDIA technical whitepaper, 2011. ↩ ↩²

6. R. Iakymchuk et al., Impacts of Floating-Point Non-Associativity on Reproducibility for HPC and Deep Learning Applications, arXiv:2408.05148, 2024. ↩ ↩²

7. J. Demmel and H. D. Nguyen, Fast Reproducible Floating-Point Summation, ARITH-21, 2013. ↩

8. diffoscope — in-depth comparison of files, archives, and directories. https://diffoscope.org/. ↩

9. G. Altekar and I. Stoica, ODR: Output-Deterministic Replay for Multicore Debugging, SOSP 2009. ↩

10. D. Geels et al., Replay Debugging for Distributed Applications, USENIX ATC 2006. ↩ ↩²

11. C. Zamfir et al., Debug Determinism: The Sweet Spot for Replay-Based Debugging, HotOS 2011. ↩

12. M. Willsey et al., egg: Fast and Extensible Equality Saturation, POPL 2021. ↩

13. S. Chacon and B. Straub, Pro Git, 2nd ed., Ch. 10 — Git Internals. ↩

14. R. C. Merkle, A Digital Signature Based on a Conventional Encryption Function, CRYPTO ‘87, 1988. ↩

15. IPFS Merkle DAG specification. https://docs.ipfs.tech/concepts/merkle-dag/. ↩

16. C. Lamb and S. Zacchiroli, Reproducible Builds: Increasing the Integrity of Software Supply Chains, IEEE Software, 2021. ↩

17. H. Berenson et al., A Critique of ANSI SQL Isolation Levels, SIGMOD 1995. ↩