What Is Deterministic Replay in CAD?

The Reproducibility Problem

Open a CAD model you created six months ago. Does it rebuild to the exact same geometry? In most CAD systems, the answer is “probably, but not guaranteed.”

Feature trees in traditional parametric CAD depend on geometric references (face IDs, edge IDs) that can change when the kernel version updates, when a Boolean operation resolves differently due to floating-point ordering, or when a fillet fails to roll along an edge that has been subtly modified upstream. The result is the dreaded “rebuild failure” — a model that worked yesterday but produces errors today, with no change to any parameter.

This is not a theoretical concern. Manufacturing organizations routinely encounter rebuild failures when migrating between CAD versions, sharing models between sites, or reopening legacy designs for revision. Each failure requires manual intervention by a skilled engineer, costing hours and introducing the risk of undetected geometry changes.

Deterministic replay solves this problem by construction.

What Deterministic Replay Means

A system exhibits deterministic replay if:

1. The same inputs always produce the same outputs
2. The evaluation order is defined and fixed
3. No hidden state (random seeds, ambient environment, floating-point mode flags) affects the result
4. The entire computation can be replayed from a recorded input set and will produce bit-identical output

In CAD terms: given a parameter set and an operation graph, evaluating the graph produces the same geometry on every machine, in every session, now and in the future.

Why Traditional Feature Trees Fail

Traditional parametric CAD uses a sequential feature tree: Sketch 1, Extrude 1, Fillet 1, Cut 1, and so on. Each feature depends on geometric references from previous features — “fillet this edge,” “cut from this face.”

The fragility comes from several sources:

Geometric Reference Instability

When a Boolean operation changes the topology of a solid (splitting faces, creating new edges), the naming of resulting entities is kernel-dependent. Different kernel versions may assign different IDs to the same geometric entity. A downstream fillet that references “Edge 47” may find that Edge 47 no longer exists or now refers to a different edge.

Floating-Point Non-Determinism

IEEE 754 floating-point arithmetic is deterministic on a single machine with a single compiler, but results can differ between:

• Different CPU architectures (x86 vs. ARM)
• Different compiler optimization levels (-O2 vs. -O3, which may reorder operations)
• Different math library implementations (libm varies between platforms)

These differences are small (last bits of precision), but they can cause Boolean operations to resolve differently at surface-surface tangency points, leading to different topologies.

Sequential Dependency Chains

A feature tree is a sequential chain where each feature depends on all previous features. A tiny change early in the chain (a sketch dimension modified by 0.001mm) can cascade through the entire tree, potentially changing topology at every step. There is no mechanism to isolate the impact.

Graph-Based Evaluation

Deterministic replay requires a different architecture: a directed acyclic graph (DAG) of operations with explicitly declared dependencies.

In a graph-based CAD system:

• Each operation node declares its inputs (parameter values, upstream geometry)
• The evaluation order is determined by the dependency graph, not by a sequential list
• No operation depends on implicit state from the ambient environment
• The graph is the complete specification of the model — nothing is hidden

When a parameter changes, only the affected subgraph is re-evaluated. The unaffected portions of the model remain unchanged, not because they happened to rebuild identically, but because they are structurally isolated from the change.

Incremental Re-evaluation

A graph-based system with dependency tracking supports incremental re-evaluation: when a parameter changes, only the nodes downstream of that parameter are recomputed. This is both a performance optimization and a correctness guarantee — nodes not downstream of the change are provably unaffected.

NeuroCAD implements this through its Distributed Constraint Graph (DCG), where each node tracks its dependencies and its evaluation state (clean or dirty). When a parameter is modified, dirty propagation marks only the affected subgraph for re-evaluation, and the evaluation proceeds in topological order.

Audit Trails

Deterministic replay enables audit trails that go beyond “who changed what when.” Because the graph is deterministic, an audit trail can include:

• The exact parameter state at any point in time: not just “radius was changed to 5mm” but the complete parameter set that produces a specific geometry
• Diff between versions: which nodes changed, which parameters were modified, which outputs are affected
• Replay verification: given the parameter state from a historical version, replay the graph and verify that the output matches the recorded geometry checksum

This is particularly valuable in regulated industries (aerospace, medical devices, nuclear) where certification requires proof that the as-designed geometry matches the as-manufactured geometry, and that any change is traceable to a specific parameter modification.

Hash-Based Integrity

In a deterministic system, the output of every node can be hashed. The hash of the root node is a fingerprint of the entire model. If any parameter, any operation, or any dependency changes, the root hash changes.

This enables:

• Tamper detection: if the geometry does not match its recorded hash, something has changed
• Cache validation: if a node’s inputs have not changed (same input hashes), its output is guaranteed to be identical, so the cached result can be reused
• Distributed evaluation: different portions of the graph can be evaluated on different machines, and the hash verifies that the results are consistent

What Deterministic Replay Enables

Reliable Version Control

With deterministic replay, a CAD model can be version-controlled like source code. The operation graph and parameter set are text-representable, diffable, and mergeable. Branching and merging design alternatives becomes a graph operation rather than a “save as” file management exercise.

Reproducible Manufacturing

When a manufacturing partner receives a model, they can evaluate it from the parameter set and operation graph on their own system and verify that the geometry matches the designer’s hash. No “which service pack are you running?” conversations.

Regulatory Compliance

For AS9100, ISO 13485, and similar quality management systems, deterministic replay provides objective evidence that the design is reproducible. The parameter set and operation graph constitute a complete, machine-readable design specification that can be audited.

Long-Term Archival

A deterministic model specification remains valid indefinitely. Unlike a proprietary file format that requires a specific software version to open, a graph-based specification with deterministic semantics can be re-implemented on any platform and will produce the same output.

Summary

Deterministic replay is not a feature — it is an architectural property. CAD systems that evaluate geometry through a well-defined dependency graph with no hidden state produce reproducible results by construction. NeuroCAD’s DCG-based architecture provides this property, enabling reliable version control, reproducible manufacturing, and auditable design histories that traditional sequential feature trees cannot guarantee.