LLMs confuse millimeters with degrees and generate physically impossible objects. TCSL is a type-safe DSL that turns text into manufacturable 3D models: the parser validates in 50 ms what an LLM fundamentally cannot guarantee.
Six fundamental limitations, backed by peer-reviewed research. Each one is addressed by TCSL at the grammar level.
For an LLM, 100 is just a token string — not 100 mm or 100 inches. A 2024 study by Foundation EGI showed ChatGPT generates a “floating tabletop” when asked to design a table — geometry looks plausible but is physically impossible.
LLMs confuse millimeters, centimeters, and inches when generating CAD code. Foundation EGI (2025): “LLMs may mishandle unit conversions, oversimplify trade-offs, or miscalculate spatial relationships” — making them unreliable for tight-tolerance tasks.
foundationegi.comYann LeCun (Meta AI, 2025): “LLMs lack grounding in the physical world — they cannot build a world model truly grounded in physical reality.” The physical world is “high-dimensional and continuous”; LLMs operate on discrete tokens.
LeCun: World Models vs Word ModelsThe first systematic study of hallucinations in 3D-LLMs (2025) found models generate objects with self-intersections, holes, and impossible joints. Errors are visually undetectable until the manufacturing stage.
arxiv.org/abs/2502.15888LLMs produce geometrically “beautiful” shapes but never verify whether they can be built. The first systematic LLM×CAD survey (ACM CSUR, 2025) confirms: no existing system integrates manufacturing constraints into the generation loop.
arxiv.org/abs/2505.08137 — LLMs for CAD SurveyA 2026 survey of LLM reasoning failures found “models cannot mentally rotate or project 3D volumes”. This confirms: language-only training fundamentally lacks the representations needed for spatial engineering tasks.
arxiv.org/abs/2602.06176 — LLM Reasoning FailuresThe LLM remains the generator. TCSL is the contract between the generator and physical reality. The parser enforces it in 50 ms — no FreeCAD required.
100 is Scalar. 100 mm is Length. The L⁰–L³ type system is closed and checked statically. 732 mm + 45 deg → R001 — error before render.
mm, cm, m, in, ft + area + volume + angle. Units are reserved words. input mm = 5 → E008. Conversion logic lives in the parser, not in the LLM.
Length × Length = Area. Area × Length = Volume. Volume × Length = E015. The physics is in the type system, not in the LLM’s “understanding.”
The parser catches errors without running FreeCAD: types, zone ordering, operation arity, division by zero, negative dimensions, integer counts, export uniqueness.
export panel as Bok_LDSP16mm_1 — the parser validates the name format. The cost estimator extracts material, thickness, part number. One line = two worlds.
Not “type error.” Instead: “dimensional result exceeds L³ range.” Every code links to a spec page with a fix example. The LLM agent gets all errors in one pass and fixes them in a single iteration.
Independent research groups have reached the same conclusion: constraining LLM output through specialized DSLs dramatically improves CAD generation quality.
A solver-aided hierarchical DSL for LLM-driven CAD. Published at Eurographics / Computer Graphics Forum. Key finding: “language design is a powerful complement to model training” for AI-human CAD tools.
arxiv.org/abs/2502.09819Text-to-CAD via CadQuery scripts with chain-of-thought and geometric reward. Achieved 100% valid syntax rate — but only for CadQuery, not for manufacturing-aware constraints.
NeurIPS 2025 PosterGoes further: dimensional type safety (L⁰–L³ + Angle), 4-zone architecture, 32 error codes including manufacturing constraints, export names for cost estimation. Not just syntax — physics.
tcsl-lang.org/specA 732×550×900 mm cabinet with 4 drawers. Same 9 parts, same result — but every value is typed, every formula auto-recomputes.
# ZONE 1: INPUT — customer parameters
input total_width = 732 mm
input total_depth = 550 mm
input side_height = 900 mm
input board = 16 mm
input num_drawers = 4
# ZONE 2: LET — derived calculations
let inner_width = total_width - 2 * board # → 700 mm
let usable_h = side_height - 2 * board # → 868 mm
let drawer_step = usable_h / num_drawers # → 217 mm
# ZONE 3: GEOMETRY — solid construction
left_side = box(board, total_depth, side_height)
right_side = box(board, total_depth, side_height) |> translate(total_width-board, 0mm, 0mm)
bottom = box(inner_width, total_depth, board) |> translate(board, 0mm, 0mm)
# ZONE 4: EXPORT — names for cost estimator
export left_side as Bok_LDSP16mm_1
export right_side as Bok_LDSP16mm_2
export bottom as Dno_LDSP16mm_1Describe a product in natural language → LLM generates TCSL → parser validates → FreeCAD builds → system outputs drawings, BOM, cost estimate. 30 seconds instead of 2–4 hours.
Imagine you run a furniture shop. A customer says: “I want a cabinet, 2 meters tall, 80 centimeters wide, 16 mm chipboard, four shelves.” Today you hire a designer who spends 2–4 hours drawing it in CAD, then manually prepares CNC programs, a bill of materials, and a cost estimate. Any of those steps can introduce an error that only shows up on the shop floor — that’s scrap and lost money.
TextToCAD does the same in 30 seconds. You type what you need; the system generates a full 3D model, drawings, CNC code, materials list, and estimate. Not a “pretty picture” — an object that can actually be manufactured on specific equipment from specific materials.
In TCSL you can’t write just “100” — you must say 100 mm or 45 deg. No existing CAD language in the world enforces this. Confusing millimeters with degrees is physically impossible — the program won’t compile, like a grammatical error in natural language.
A 1.2 m shelf from thin chipboard? Geometrically fine. In practice it sags. TextToCAD checks 15–35 manufacturing rules automatically and self-corrects the code. Like autocorrect that checks physics, not just spelling.
First: syntax correctness (during generation). Second: geometric validity (no self-intersections, holes). Third: manufacturing feasibility (can it be cut, assembled, support load). No system in the world does all three together.
Competitors define “good” as “looks like the right shape.” TextToCAD defines “good” as “can be built.” Manufacturability assessment is used for the first time as part of the reward function during AI training.
Usually 3D modeling and manufacturability checking are separate programs, separate stages, separate specialists. In TextToCAD everything is unified in the TKG v2 engine, which in half a second builds the model, understands which face is a shelf vs. a side panel, validates all rules, and returns the result.
The core — TCSL and the TKG v2 engine — stays the same across industries. Only the rule sets change, plugged in modularly.
Cabinets, shelving, kitchens. Rules: “shelf must not deflect,” “holes on 32 mm grid,” chipboard/MDF/HDF thickness constraints. Cost estimator via export as.
Welded frames, shelving, tube steel structures, sheet metal. Rules: K-factor for bending, flat patterns for laser, TRUMPF/AMADA programs. “500 kg rack, 5 shelves, 40×40 tube” → complete project.
Display cases, reception desks, store shelving. On-site assembly maps, RAL paint specs, accessory BOMs.
Turning, milling, drilling. Threads, fits (H7 tolerance = specific machining), ISO standards. The system generates not just shapes but machining awareness.
Titanium, composites, NURBS surfaces. Certification constraints, full digital traceability of every parameter. The strictest requirements.
IFC export for Revit and equivalents. Building codes, structural engineering standards — but the same principle: describe → get a complete project.
Why this is feasible: the core is the same for all industries. For furniture: “shelf must not sag.” For metal: “bend radius ≥ 2× sheet thickness.” For mechanical: “H7 tolerance requires grinding.” Rules plug in modularly. Integration with any CAD package (KOMPAS-3D, SolidWorks, Fusion 360) uses the standard STEP format — no vendor lock-in.
Customer
Typed literals only. Overridable via GUI/CLI/API.
Engineer
Formulas. Auto-recompute. L⁰–L³ algebra checked statically.
Machine
23 functions. Pipeline |>. Constructors, transforms, booleans.
Cost Estimator
FreeCAD tree names. Format: Element_Material_Number.
“A language that can describe everything can guarantee nothing.
A language that describes exactly what’s needed
guarantees exactly what it promises.”
— TCSL Manifest, §VII
Read the full manifest — 10 principles, 5 commitmentsNot “a program for furniture.” A language for describing physical objects. Furniture is the proving ground. The goal: any industry where material becomes product.