Why assembly rebuild lag is a measurable engineering problem — and what a real latency contract looks like.

The four-second pause that ate your morning

You opened a 200-part gearbox in SolidWorks. You changed the bore of a single bushing from 12 mm to 12.5 mm. You hit Enter. The cursor turned into a spinner. The mate tree began re-solving. The graphics window froze. Four seconds later — sometimes seven, sometimes eleven, depending on how many configurations the assembly carries — the bushing was 0.5 mm wider and you had a feature-manager full of yellow warning triangles asking you which mate the kernel should drop to keep the assembly consistent.

Multiply that pause by a hundred edits across an afternoon of design work and you have lost half a day to rebuild lag. None of the other 199 parts moved. None of their mates depended, in any real sense, on the half-millimetre you just typed. The kernel had no way to prove that, so it solved everything anyway.

If you have ever lived inside a large assembly in any commercial CAD seat — SolidWorks, Inventor, Creo, NX, Fusion 360 — you know the symptom. You also know the workarounds: lightweight components, suspended sub-assemblies, large-design-review mode, frozen mates, “speedpak” representations, exporting the heavy sub-assemblies as static bodies. None of those are modelling decisions. They are coping mechanisms for a kernel that cannot tell which mates depend on what you changed.

This post is about the underlying reason and what NeuroCAD does differently — specifically, what a measurable, contractual update-latency budget for a 200-part assembly looks like, and what we have actually built so far.

What an assembly really is

A modern parametric assembly is not a collection of parts glued together by mates. Underneath, it is a graph. The nodes are:

Parts, each of which carries its own internal feature tree.
Mates / joints, each of which is a constraint on the relative pose of two parts: coincident, concentric, parallel, distance, gear-ratio, cam-follower, slider, revolute.
Parameters, both inside parts (a hole diameter, a pad length, a chamfer size) and at the assembly level (a distance-mate offset, a gear ratio, a configuration switch).
Sub-assemblies, which are themselves assembly nodes — recursive containers.

The edges of the graph encode dependency: mate M3 depends on the cylindrical face of part P7, which depends on the hole feature inside P7, which depends on the diameter parameter you just typed. Change one number and a small subset of the graph becomes dirty. Everything downstream of the dirty set has to be re-evaluated. Everything that is not downstream of the dirty set should be left alone.

The textbook algorithm for this is forty years old. It is called change propagation over a directed acyclic graph. It is the same algorithm that makes make skip object files that did not change, that makes bazel cache subtree outputs, that makes Salsa and Adapton cache function results. It is not exotic. It is not a research problem. It is a default expectation in every other field of computing where a graph of dependencies is involved.

So why does it not happen in commercial assembly CAD?

Three reasons commercial assemblies over-solve

We do not have the source of the major commercial kernels (Parasolid, ACIS, Cgm), so we cannot speak from inside. But we can read the symptoms — every benchmark thread on every CAD forum repeats them — and we can read what the vendors themselves publish in their help systems and patents.

1. Coarse-grained dependency tracking at the part-level, not the parameter-level. When you change anything inside a part, the entire part is marked dirty. Every mate that touches that part is marked dirty. Every part connected to those mates is marked dirty. The dirty set explodes outward across the assembly. The kernel did not lose track of the dependency — it never had it at the parameter level to begin with.

2. Monolithic constraint solvers that re-solve the whole assembly even for a single dirty mate. The mate solver receives a 6N-dimensional system of pose equations (six DOF per part times N parts), Jacobian, residual, Newton step. When one mate is dirty, the temptation is to hand the entire system to the solver because partitioning the system into independent connected components requires graph analysis the kernel was never asked to perform. So it re-solves all of it.

3. No published latency contract. Onshape’s Assembly Performance panel is the closest public artefact in the industry: it surfaces, per assembly, the wall-clock cost of mate solving, of the regen, of the display update. It is genuinely useful — you can look at an assembly and see why it is slow. But it does not promise anything. It does not say “this assembly’s incremental update will complete in under N milliseconds when you change one parameter”. It is a thermometer, not a thermostat. SolidWorks Lightweight Mode and the various Speedpak / Large Design Review modes are also coping mechanisms — they tell the kernel not to evaluate parts of the assembly at all, in exchange for not being able to mate against them. They do not solve the underlying graph problem; they hide it.

What NeuroCAD does differently

NeuroCAD is built around a single graph that already has the right shape: the Distributed Constraint Graph (DCG). The DCG is the kernel-level dependency structure — every parameter, every feature, every face reference, every mate is a node, and every dependency is an edge. The DCG is the single source of truth for “what depends on what” across the entire session.

Two properties of the DCG are load-bearing for incremental assembly update:

Parameter-level granularity. When you change a hole diameter, the dirty node is the diameter parameter, not the hole feature, not the part. The kernel walks downstream from the parameter and visits exactly the features, faces and mates that consume it.
Composability across parts and assemblies. The DCG does not stop at the part boundary. A mate node has incoming edges from face-reference nodes that live inside their respective parts; a sub-assembly’s internal DCG is a sub-graph of the top-level DCG. There is no special “assembly DCG” layered on top of the part DCG — it is one graph.

That gives us the pre-condition for an incremental update. The actual update step is then a forward dataflow walk: collect the transitive closure of dirty nodes, sort topologically, evaluate each in turn, stop. The mate solver is invoked only on the connected components of mates that are actually dirty. Independent sub-assemblies are not visited at all.

In an SDF-native kernel, that forward walk has one extra benefit. SDFs are total functions of space — there is no edge or face identity that could be invalidated by an upstream topological change. When the bushing diameter changes, the bushing’s SDF re-computes; the cylindrical “face” the mate references is recovered from the SDF on demand; the mate’s contact constraint is re-evaluated. There is no InvalidEdgeReference to roll back from.

What a measurable SLA contract looks like

A latency contract is more than a benchmark. It is a quad of:

A scenario — a specific assembly, a specific edit, a specific machine.
A budget — a wall-clock target for the incremental update (e.g. p95 < 250 ms).
A measurement protocol — exactly which clocks start and stop where, what counts as “done”.
A regression alarm — a CI gate that fails the build if the budget is violated by more than a tolerance.

For NeuroCAD’s first published assembly contract we are using:

Scenario: a 200-part synthetic gearbox with 312 mates, configured with three independent kinematic loops, one parameter group bound to the bushing bore.
Budget: p50 < 80 ms, p95 < 250 ms, p99 < 500 ms, on the reference NUC (Intel Core i7-1360P, 32 GB RAM, native).
Measurement protocol: start the clock when the parameter mutation enters the kernel API; stop it when the dirty closure has been evaluated, mate residuals are below tolerance, and the renderer’s GPU buffers contain the new pose. Three intermediate timestamps in between (closure-walked, mates-solved, buffers-uploaded) so we can attribute regressions.
Regression alarm: the CI workflow runs the benchmark on every merge; if the p95 budget regresses by more than 15% from the rolling baseline, the gate is red.

That is a contract you can hold the kernel to. It is not a thermometer; it is a thermostat with a setpoint and an alarm. If we miss it we know, the gate goes red, and someone fixes it before the regression compounds.

What you can take away today

If you are an assembly engineer evaluating CAD tools, three questions to ask any vendor:

When I change one parameter in one part, how many parts and mates does the kernel re-evaluate? The answer should be a finite, predictable number — the size of the downstream dirty closure — not “all of them”.
Is there a published latency target for incremental update on a reference assembly, with a regression gate that enforces it? Anything less is a thermometer without a thermostat.
Does the kernel report which mates were re-evaluated and why? If you cannot inspect the dirty set, you cannot debug performance regressions in your own assemblies.

NeuroCAD’s answer to all three is “yes, by construction” for the first, “in progress, with the contract published” for the second, and “yes, via the DCG inspector” for the third. We will measure ourselves against that publicly, and the gate will be in CI.

That is the entire promise. Not “fast assemblies”. Measured incremental updates with a contract you can read and a regression alarm you can rely on.

Status

DCG core (parameter-level dependency tracking, dirty propagation, topological re-evaluation): implemented in the public API. This is the load-bearing structure and it is real.
Per-part feature DCG re-evaluation: working in the Part Design lane.
Assembly-level DCG extension (mates as DCG nodes, cross-part edges, joint solver invoked on dirty components): partial. The data model is in place; the solver invocation strategy still re-solves a larger superset than strictly necessary in some configurations.
200-part SLA benchmark with the latency contract above: proposed. The synthetic gearbox corpus is being built; the timestamp instrumentation is wired; the CI gate is not yet active. We expect to publish the first measured numbers in the next benchmark window.

We are publishing this post now, before the numbers are in, because the methodology is the publishable contribution. Onshape’s Assembly Performance panel showed the field that latency could be observable. The next step is for an SDF-native kernel to show that, with parameter-level dependency tracking, latency can be contractual.

200-Part Assemblies Grind in SolidWorks. NeuroCAD Treats Update Latency as a Contract.