All summaries · 2026-09-10

CIT-CAD: Constraint Intent Tree-based CAD Code Generation and Verification

Unknown authors

arXiv:2609.07434 · abstract · pdf · summarized by meta/muse-spark-1.3-contributor on 2026-09-10

The one-paragraph version

This paper tackles a blind spot in text-to-CAD: current systems are judged mainly on whether the final 3D shape looks right, but a CAD program is supposed to be an editable recipe, not just a shape. The authors propose CIT-CAD, a pipeline that first asks a large language model to turn a written description into an explicit plan called a Constraint Intent Tree, then generates CadQuery code from both the description and that plan, then deterministically checks whether the code actually follows the plan and repairs it if not. The plan records what parts should exist, whether each part adds material or cuts it away, what kind of 2D sketch each part starts from, and how parts should touch or align. Across about 26,000 multi-part examples derived from Text2CAD, this scaffold plus check-and-repair improves the share of runnable programs and especially improves construction-level correctness, with larger gains on more complex designs, while final-shape overlap improves only modestly.

The problem they're solving, and why it matters

Natural-language CAD code generation means turning a sentence like “a rectangular plate with two circular holes” into a runnable, editable parametric program. Parametric here means the model is defined by named entities, dimensions, and operations you can later change, rather than a frozen mesh of triangles. In this paper the programming language is CadQuery, a Python library where you typically draw a 2D sketch, extrude it into 3D, meaning pull the flat profile into a solid thickness, and then combine solids with Boolean operations, meaning union to add, cut to subtract, and intersect to keep only overlap.

Large language models, meaning large neural networks trained to generate text and code, can now write such programs, but evaluation usually asks only: does it run, and does the final occupied volume match the reference? The common geometry score is Intersection over Union, meaning the volume shared by generated and reference solids divided by their combined volume. The paper argues this is necessary but coarse. A motivating example is a plate that looks almost right and gets high overlap, yet is missing a hole, uses the wrong additive versus subtractive role, or joins parts in a way that breaks future editing. Overlap alone cannot tell you which of those happened or how to fix it. For real design workflows, where you must edit dimensions, suppress features, or preserve holes and symmetries, the construction history matters as much as the rendered shape.

The key idea, in plain words

The key idea is to make implied construction intent explicit and checkable before and after code generation.

Think of the Constraint Intent Tree, from now on CIT, as a structured shopping list plus assembly notes inferred from the description. The root is the whole object. Branches are grouping nodes that carry no geometry themselves, for example “holes group.” Leaves are physical entities, meaning solids to add or cutting tools to subtract. Each entity carries local expectations such as what kind of sketch outline it should have and whether it adds or cuts. Pairs of entities carry relational expectations such as whether they should overlap in volume, touch on a face versus an edge or point, share coplanar faces meaning flat faces lying in the same plane, or share an axis meaning cylindrical features lined up on the same center line.

The tree is deliberately lighter than a full CAD program. It does not try to guess every missing coordinate. It keeps only the structural and semantic constraints that should be preserved. That same tree then serves two jobs: it guides the code writer so naming and decomposition are less ambiguous, and it defines the answer key for a separate, non-AI checker that inspects the generated code.

How it actually works, step by step

Consider a concrete case from the paper: a rectangular block plus two circular through-holes.

First, infer the tree. An LLM reads the description and must output valid JSON with stable snake-case identifiers, meaning lower-case names with underscores like sketch_hole_1, one node per physical solid or cutting tool, and null for anything uncertain rather than invented numbers. For the plate example, it might create a base node expecting a rectangular sketch and additive role, and two hole nodes expecting circular sketches and subtractive role, plus a relation that the holes intersect the base and share an axis pattern.

Second, generate code conditioned on the tree. A second LLM call receives both the description and the tree and must write Python that imports CadQuery as cq, creates one variable per tree entity using the exact expected variable name, builds each entity with a Workplane sketch followed by extrusion, combines them with union or cut according to additive versus subtractive role, and stores the final result in a variable named solid.

Third, extract two comparable constraint sets with deterministic rules, meaning fixed code and geometry analysis rather than another LLM guess. The expected set comes from normalizing the tree annotations. The executed set comes from inspecting the generated program: static analysis of the syntax tree finds extrusion assignments, recovers sketch calls, classifies sketch type, and infers Boolean role from union and cut expressions, while actually running the program and inspecting the resulting solids yields relations like contact and overlap. Both sides are converted to the same short form: a map from entity and field to value, and a canonical list of relation triples where entity order is sorted so comparison is order-invariant.

Fourth, verify by exact matching. In words: an expected entity field is satisfied only if that variable exists in the generated code and its extracted value equals the expected value; an expected relation is satisfied only if that exact canonical triple appears in the extracted relations. A program is valid only if all expected entity and relation checks pass. Failures are localized to specific nodes or relations, for example “missing entity sketch_hole_2” or “wrong Boolean role,” rather than a single global geometry score.

Fifth, repair with safeguards. The validator’s localized feedback plus locked constraints, meaning constraints already satisfied that must be preserved, are given back to the LLM for revision. A candidate revision is accepted only if it keeps all previously locked constraints and strictly reduces the count of remaining violations. This is why the authors claim regression-free accepted repairs: by construction, an accepted step cannot break what already worked. The loop stops when there are no violations, when a candidate fails to improve, or when a repair budget, reported as two iterations by default and up to five in some runs, is exhausted.

What they showed — results, honestly, with limitations

The evaluation uses multi-entity samples derived from Text2CAD, starting from about 178,000 samples, filtering to about 151,000 valid pairs, then keeping 26,783 samples with at least two extruded entities. Descriptions are augmented with numeric parameter summaries extracted by an LLM from the held-out reference code, because original descriptions often lack dimensions needed to run. The reference code is used only for geometry scoring and grouping, never as input to generation. Metrics are Valid Syntax Rate meaning share that runs and yields a solid, mean and median overlap, Success Rate meaning share with overlap above 0.95, and Constraint Satisfaction Rate meaning share of tree-derived constraints satisfied by the generated code.

Across three backbones — DeepSeek-Coder-V2-Lite-Instruct, Qwen3-A3B-Instruct, and GPT-5.4-mini — CIT-CAD improves executability and especially constraint satisfaction over direct prompting. For example, overall Valid Syntax Rate rises from 74.1% to 83.3% for DeepSeek, 78.0% to 85.1% for Qwen3, and 87.2% to 90.4% for GPT-5.4-mini. Constraint Satisfaction Rate roughly doubles: 14.8% to 28.3% for DeepSeek, 16.7% to 31.8% for Qwen3, and 16.7% to 37.7% for GPT-5.4-mini. Gains grow with complexity; DeepSeek on designs with seven or more entities jumps from 9.6% to 36.1% satisfaction, about a 276% relative gain. Geometry gains are smaller: mean overlap moves only from 29.0% to 29.2% for DeepSeek and 32.6% to 32.8% for Qwen3, with a larger but still modest 31.2% to 32.3% for GPT-5.4-mini. Median overlap and high-overlap success improve more clearly for GPT-5.4-mini.

Two other findings matter. Sample-level correlation between overlap and constraint satisfaction on Qwen3 is near zero, Pearson around 0.02 and Spearman around 0.02 in text, plotted as essentially 0.00, supporting the claim that looking right does not mean built right. Iterative repair on Qwen3 lifts average satisfaction from 18.2% before repair to 21.6%, 25.0%, 28.4%, then 28.9%, a 10.7 point absolute or 58.8% relative gain, mostly in early rounds. Remaining violations concentrate in fine-grained sketch fields, especially sketch type and whether a sketch is a single connected profile, rather than high-level relations.

Limitations are stated frankly in the appendix and should temper enthusiasm. If the inferred tree is wrong, the verifier faithfully checks the wrong intent. The checker only covers its implemented vocabulary and does not prove full CAD equivalence or handle tolerances, manufacturing rules, or arbitrary parametric dependencies. The dataset is filtered to multi-entity cases where description and code entity counts agree, plus numeric augmentation from reference code, so it tests parameter-aware specification following more than pure qualitative prompting. It is also unclear from the text what exactly “GPT-5.4-mini” refers to, so that backbone result is best read as reported rather than independently verified.

Why this might matter to me

If you care about spatial reasoning in LLMs and vision-language models, this is a concrete test where language must posit parts, roles, and relations, not just describe an image. Overlap rewards can hide missing holes or flipped additive-versus-subtractive logic; the CIT forces the model to commit to contact, coplanarity, shared axes, alignment, and symmetry in a form a geometry engine can falsify. That pattern — language proposes a world structure, a simulator checks it, localized errors drive repair — is directly relevant to world models where an internal model of space and causality must stay consistent under edits, not just render plausibly once.

For text-to-CAD and parametric geometry, the contribution is construction-aware synthesis: variable naming tied to intent, sketch-then-extrude discipline, and Boolean roles as first-class constraints. For 3D generation and scene representation, the lesson is compositional. Instead of scoring a whole scene by global similarity, represent objects as entities with pairwise relations and verify them monotonically, keeping what works while fixing what violates. The bottleneck the authors find, namely fine-grained sketch grounding, points to where to invest next: better 2D profile understanding, dimension grounding, and relation-aware local editors that can fix a circle versus rectangle or a disconnected profile without rebuilding the whole assembly.

Terms worth knowing