Source-linked AI summary
CIT-CAD: Constraint Intent Tree-based CAD Code Generation and Verification
Yali Du, Hui Sun, San-Zhuo Xi, Ming Li
TL;DR
Geometry-only metrics such as IoU can miss construction errors in generated CAD programs. CIT-CAD represents design intent in a Constraint Intent Tree, uses it to guide generation and verification, and repairs localized violations; its evaluation reports broader improvements, while execution dependence and limited constraint coverage bound interpretation.
Problem
Final-geometry similarity is necessary but coarse because it cannot localize errors in decomposition, features, Boolean roles, or relations.
Method
CIT-CAD infers a Constraint Intent Tree, conditions CAD generation on it, compares CIT-derived expected constraints with program-extracted constraints, and uses localized mismatches for repair.
Results
CIT-CAD improves overall CAD-generation performance, including geometric- and constraint-level quality, especially on structurally complex multi-entity designs and across LLM backbones.
Takeaways & Limitations
Making construction intent explicit provides a program-level view of CAD correctness that complements final-shape IoU.
Takeaways & Limitations
Constraint satisfaction measures only the vocabulary supported by the deterministic analyzer, not complete CAD equivalence.
Abstract
from arXiv · showhide
Natural-language Computer-Aided Design (CAD) code generation aims to turn design intent into executable and editable parametric programs. Large language models (LLMs) make this goal increasingly practical, but useful systems must preserve the construction process behind the rendered geometry. Existing benchmarks and methods mostly focus on how closely the generated CAD model matches the reference geometry, often using metrics such as Intersection over Union (IoU). Such metrics can miss errors in part decomposition, construction hierarchy, Boolean operations, sketch structure, and geometric relations. This gap calls for a representation that makes design intent explicit and lets a system check generated code against that intent. We propose CIT-CAD, a framework that infers a Constraint Intent Tree (CIT) from the input description to represent the intended entities, hierarchy, operations, and relations. The tree has two roles: it guides CAD code generation and defines expected constraints for verification. The framework extracts actual constraints from the generated program, compares them with the expected constraints, and uses mismatches to localize and repair design violations. Experiments show that the framework improves CAD generation performance, with larger gains on more complex multi-entity designs. By turning design intent into an explicit and checkable object, this work is the first attempt to move text-to-CAD generation beyond rendered-geometry matching toward construction-aware synthesis, verification, and repair.
I. INTRODUCTION
CIT-CAD addresses the limits of geometry-only CAD evaluation by making construction intent explicit and checkable. It uses this intent to guide generation, verify constraints, and repair violations, improving performance especially for structurally complex designs.
- CAD programs encode editable construction procedures involving sketches, extrusions, Boolean operations, and geometric relations, not only final shapes.
- IoU and other geometric measures can miss wrong decomposition, missing features, incorrect Boolean roles, and violated relations.
- CIT-CAD infers a CIT, generates code conditioned on it, derives expected constraints, extracts executed constraints, and localizes violations for repair.
- A Constraint Intent Tree records expected entities, construction hierarchy, operations, and relations implied by natural-language descriptions.
- Repairs are accepted only when they preserve satisfied constraints and reduce remaining violations.
- CIT-CAD improves executability, constraint satisfaction, and overall performance across LLM backbones, with stronger gains on structurally complex multi-entity designs.
B. Intermediate Intent Representations for Code Generation
CIT-CAD uses a construction-aware intermediate representation between natural-language descriptions and executable CAD code. The CIT captures hierarchical, geometric, and semantic constraints that guide generation and support deterministic validation.
- Intermediate representations can make code generation more controllable, but CAD requires representing construction intent beyond syntactic plans or coding steps.
- CIT-CAD infers a CIT from a description, generates a program conditioned on the description and tree, derives expected constraints, and extracts executed constraints for comparison.
- A CIT is a tuple whose nodes represent entities or groups, edges encode construction hierarchy, attributes encode node constraints, and relations encode inter-node constraints.
- Constraint checking covers entity-level properties and relation-level conditions such as contact, intersection, coplanarity, and shared axes.
- The CIT omits underspecified low-level numeric details while retaining construction intent needed for generation and validation.
C. CIT Constraint Annotation
CIT-CAD annotates inferred intent with entity- and relation-level constraints, then uses the resulting CIT to structure code generation and verification.
- Constraint vocabulary: CIT-CAD divides its constraint vocabulary into entity-level properties and relation-level spatial or semantic relations.Entity constraints describe individual construction entities, while relation constraints describe interactions among entities.
- Constraint vocabulary: Entity-level constraints include Sketch type, Is connected, Is open profile, and Boolean role.These fields capture sketch structure and whether an entity contributes additively or subtractively.
- Constraint vocabulary: Relation-level constraints include Intersection, Contact type, Has coplanar faces, and Has shared axis.They are selected because they are common in multi-entity CAD programs and can be extracted deterministically.
- CIT inference: CIT inference produces a normalized JSON tree whose schema specifies nodes, constraints, relations, and stable naming conventions.The prompt requests one node per physical solid or cutting tool and null values for uncertain constraints.
- CIT-guided generation: Conditioning generation on the CIT provides a construction scaffold and lets the validator compare extracted code constraints with intended nodes and relations.The generated program is required to create variables for CIT entities and compose them according to their Boolean roles.
F. Deterministic Constraint Extraction
CIT-CAD converts CIT intent and generated-program observations into comparable normalized constraint sets, then deterministically verifies satisfaction and localizes violations.
- Constraint normalization: CIT-CAD derives expected constraints from the CIT and executed constraints from the generated program.The two sets are represented as CT = (ET, QT) and CP = (EP, QP).
- Constraint normalization: CIT-to-constraint conversion maps node annotations to entity fields and relation annotations to canonicalized relation triples.Unspecified values are removed, and relation participants are sorted so comparison is order-invariant.
- Program extraction: Program analysis extracts entity and relation constraints using static AST analysis and runtime geometric reasoning.AST analysis recovers sketch operations and Boolean roles from extrude, union, cut, and intersect expressions.
- Verification: Deterministic validation separates uncertain LLM interpretation from the fixed analysis used to decide whether generated code satisfies CIT requirements.The validator and geometry engine do not rely on blindly trusting the LLM output.
- Verification: Verification checks exact equality between expected and executed entity-field constraints and set membership for canonicalized relation constraints.Missing expected entities cause all associated constraints to be marked violated.
- Verification: The validator partitions expected constraints into satisfied and violated sets and reports validity together with constraint identifiers.The partition is consumed by the repair loop.
- Violation localization: Every violated constraint is localized to its corresponding CIT node, relation, or subtree.This turns failures into actionable feedback about missing nodes, incorrect sketch fields, or unsatisfied relations.
H. Localized Reflexion Repair
Localized validation feedback drives an iterative repair loop that accepts only constraint-preserving improvements, preventing regressions while reducing remaining violations.
- Repair feedback: After each validation round, CIT-CAD sends violated entities, relations, CIT paths, and repair guidance to the LLM.The repair prompt includes the description, CIT, current code, and validation feedback.
- Monotonic repair: The repair process maintains satisfied constraints in a locked set while tracking the current accepted program and violated set.This state supports monotonic acceptance across repair iterations.
- Algorithm: Algorithm 1 takes the description, CIT, initial program, and repair budget, and returns a verified or best accepted CAD program.The repair budget is represented by the maximum number of attempts K.
- Acceptance: A candidate repair is accepted only when validation preserves previously satisfied constraints and strictly reduces remaining violations.Otherwise, the previous accepted program is retained.
- Guarantee: Accepted repairs are regression-free with respect to the CIT-derived constraint set.The proposition follows because any newly violated locked constraint causes rejection.
- Termination: The number of accepted repairs is bounded by the initially violated constraints, although termination may occur earlier because of iteration limits or rejected candidates.This bound follows from strict progress in the number of violations.
IV. DATASET AND METRICS
The evaluation uses multi-entity Text2CAD samples with descriptions, held-out reference programs, and generated programs, enabling both geometry- and construction-level assessment.
- Dataset: The evaluation set is constructed from Text2CAD and contains multi-entity samples.Each sample includes a natural-language description, a held-out reference CAD program, and generated programs from evaluated methods.
- Metrics: The evaluation measures generated programs from both geometry-level and construction-level perspectives without providing the reference program during generation or CIT inference.This setup supports construction-aware evaluation while preventing reference-program input to generation.
A. Data Source and Sample Selection
The evaluation uses a filtered multi-entity subset of Text2CAD and combines executable-code, geometry, and construction-level measures. Natural-language descriptions drive CIT inference, while reference programs are reserved for geometry-level evaluation.
- The benchmark begins with about 178K Text2CAD samples and retains 151K valid text-to-CAD pairs after removing missing descriptions, missing programs, and duplicates.
- The final evaluation subset contains 26,783 multi-entity samples, excluding single-entity programs with limited hierarchy, Boolean composition, or inter-entity relations.
- Each natural-language description is the generator and CIT stage input, while the reference CAD program is used only for geometry-level evaluation and entity-count grouping.
- Evaluation combines valid syntax rate, geometry-level success, IoU, and CIT-based Constraint Satisfaction Rate.Valid syntax rate counts executable programs that produce valid solids; CSR measures preservation of intended construction processes, complementing IoU.
V. EXPERIMENTS
Experiments compare direct generation with CIT-CAD across LLM backbones, entity complexities, geometric similarity, repair iterations, and construction-constraint violations. CIT-CAD improves execution and constraint satisfaction, with larger gains on complex designs, while sketch-level reconstruction remains the main error source.
- Experimental setup: CIT-CAD compares direct Vanilla generation with CIT-conditioned generation followed by constraint-guided validation and repair across three LLM backbones.The evaluated backbones are Qwen3-A3B-Instruct, DeepSeek-Coder-V2-Lite-Instruct, and GPT-5.4-mini.
- RQ1: Backbone and complexity: CIT-CAD consistently improves execution success, with larger gains as reference entity count increases for the open-source backbones.The comparison groups results by reference entity count and evaluates how construction complexity affects performance.
- RQ1: Backbone and complexity: 276.0%: DeepSeek-Coder’s CSR improvement on samples with seven or more entities, compared with 86.5% on two-entity samples.GPT-5.4-mini shows positive aggregate changes after excluding unavailable generated files, including 125.7% in CSR.
- RQ2: Geometry versus constraints: Pearson r = 0.022 and Spearman ρ = 0.023: IoU and CSR are nearly uncorrelated on Qwen3 samples.The result supports using CSR as a complementary metric because final-shape overlap does not reliably predict construction-intent preservation.
- RQ3: Constraint-guided repair: 10.7% absolute improvement: Qwen3’s average CSR rises from 18.2% before repair to 28.9% after iterative repair.The largest gains occur in early iterations, while later improvements diminish and motivate early stopping when violations no longer decrease.
- RQ4: Violated constraints: CIT-CAD reduces normalized violations across all evaluated backbones, but sketch type and connectivity remain the dominant failure modes.Relation-level violations occupy smaller portions of the distribution, while fine-grained local sketch reconstruction remains the main bottleneck.
C. Qualitative Analysis (Case Study) ®
The case study shows that CIT-CAD exposes construction-level errors that visual similarity can miss, then uses localized constraint violations to guide targeted repair.
- Case Study: Vanilla generation can produce a visually plausible model with high IoU while omitting an intended subtractive feature.In Sample 00931238, the main cylindrical body and central hole are generated, but the side through-hole is missing.
- Case Study: CIT-CAD detects the omitted side hole as a violated constraint involving a missing or incorrect subtractive entity.The violation identifies the construction role that needs correction rather than treating the error as an undifferentiated geometry mismatch.
- Case Study: Localized feedback lets repair focus on correcting the violated construction role and inserting the required cut operation.This avoids blindly regenerating the entire model and targets the specific missing construction step.
- Case Study: After repair, the model recovers the intended side-hole structure, reaching 99.99% IoU and 100% CSR.These results illustrate recovery at both the geometric and constraint levels.
- Case Study: The broader conclusion is that CIT-CAD converts construction errors into interpretable repair signals that improve alignment with the intended construction scaffold.The framework complements final-shape comparison with program-level structural checking.
A. Constraint Intent Tree Extraction
CIT-CAD uses a two-stage prompt pipeline: extract a Constraint Intent Tree, generate CadQuery code from it, then validate and repair the program using localized constraint feedback.
- Constraint Intent Tree Extraction: The initial generation stage first extracts a Constraint Intent Tree from the description and then generates executable CadQuery code conditioned on that tree.The two calls separate intent extraction from code generation while keeping both stages tied to the same design description.
- Constraint Intent Tree Extraction: The tree extraction prompt creates nodes for physical solids or cutting tools and records supported sketch properties and Boolean roles.Additive solids use boolean_role=true, while subtractive cutting tools use boolean_role=false.
- Constraint-Guided Repair: The repair stage receives the description, inferred CIT, current code, and deterministic validation feedback identifying violated entity or relation constraints.Feedback also records localized CIT paths and constraints that should be preserved.
- Constraint Validation: CIT-CAD converts expected CIT constraints and generated-program constraints into a shared short-constraint representation before verification.Expected constraints are traced to CIT node paths, while generated constraints are extracted from program and geometry analysis.
- Constraint Validation: Validation checks entity fields by exact equality and relations by membership in a canonicalized relation set rather than fuzzy matching.A relation is counted as violated when the expected contact or relation type is absent or different, even if final geometry has non-zero IoU.
IX. DATASET PREPROCESSING
The evaluation data is constructed by joining valid Text2CAD descriptions and programs, then filtering for multi-entity cases and augmenting inputs with extracted parameters.
- Dataset Construction: The preprocessing joins normalized natural-language and CadQuery records, removes missing or duplicate entries, and yields 151K valid text-to-CAD pairs.The resulting pool is the starting point for later construction-aware filtering.
- Dataset Construction: The final construction-aware subset retains samples with at least two explicit extruded entities in the reference CAD program.An implementation-level parser counts construction entities to enforce the multi-entity requirement.
- Dataset Construction: Preprocessing also estimates entity counts mentioned in descriptions so the textual and code-derived construction complexity can be aligned.This filtering is intended to expose the multi-entity structure evaluated by CIT-CAD.
- Parameter Augmentation: Parameter augmentation appends compact summaries of dimensions, transformations, entity counts, and Boolean composition to the natural-language inputs.The summaries are extracted from held-out reference CadQuery code before generation.
X. EXPERIMENTAL CONFIGURATION
The experiments compare Vanilla generation with the full CIT-CAD pipeline across multiple LLM backbones, while identifying limitations tied to intent extraction, detector coverage, data selection, and execution-based evaluation.
- Experimental Configuration: Vanilla directly generates standalone CAD programs, whereas CIT-CAD performs CIT extraction, conditioned generation, deterministic validation, localized repair, and candidate acceptance.Both methods consume the same augmented natural-language descriptions.
- Experimental Configuration: The experiments use Qwen3-30B-A3B-Instruct, DeepSeek-Coder-V2-Lite-Instruct, and GPT-5.4-mini through compatible chat-completion endpoints.The open-source and closed-source backbones are evaluated under the reported endpoint configurations.
- Experimental Configuration: The default implementation uses two repair iterations, while some extended GPT runs use five iterations.The number of iterations is controlled by the max-reflexion-iters setting.
- Threats to Validity: CIT-CAD depends on the quality of inferred CITs, because missed entities or incorrect relations cause the verifier to check the wrong intent.Fixed formatting, null values for uncertainty, and multiple backbones reduce but do not remove this variance.
- Threats to Validity: CSR covers only the deterministic analyzer's implemented vocabulary and is not a complete proof of CAD equivalence.Supported constraints include sketch fields, Boolean roles, intersections, contact types, coplanar faces, and shared axes, but not all CAD intents.
- Threats to Validity: The dataset filters for multi-entity samples with matching textual and code-derived entity counts, while parameter augmentation makes the setting closer to parameter-aware specification following.Consequently, the evaluation may underrepresent single-solid or purely qualitative-prompt settings.
- Threats to Validity: Execution-based metrics depend on successful CadQuery execution and deterministic geometry analysis, so small API errors can penalize partially recoverable intended shapes.Runtime failures are treated as invalid outputs and affect both geometry- and constraint-level metrics.