Agent-generated CAD needs a buildability contract

The generated object is code, not a picture

LDraw Nova became a useful engineering case study in early October because it does not stop at text-to-image. The open-source project asks an agent to interpret a design request, produce a plan, write Python that compiles the plan into LDraw, render the result, inspect the images, and revise. The final package can include LDraw source, interactive views, a Blender-editable glTF file, images, and the conversation that produced them.

The launch earned 164 points and 51 comments on Hacker News on October 2. By October 6, GitHub's API reported 277 stars, 21 forks, three open issues, and an October 3 code push. Those are credible signs of developer attention, but not proof that the models are physically sound. The project's own documentation calls the release experimental, identifies slow and expensive generation, lists weak model families, and says large correct models currently favor costly frontier models.

More importantly, the public examples were designed in a medium where impossible geometry can still look persuasive. Current reporting notes that the showcased large models had not been built with real bricks. That gap is the real technical story. If a system produces an executable physical representation, the acceptance question changes from “does it look right?” to “which machine-checkable and human-observed facts justify the word buildable?”

The focused 30-day scan found one strong exact cluster across the repository and Hacker News. Most Reddit matches were generic LEGO or open-model discussions with no LDraw Nova entity match, so they are excluded from popularity claims. Google Autocomplete returned the exact suggestion “ldraw nova,” while the topic did not appear in the sampled US Daily Search Trends feed. The evidence supports a timely mechanism guide, not a mass-market trend narrative.

LDraw Nova turns the model into a program generator

The design choice that makes Nova interesting is its intermediate representation. LDraw is a text-based CAD format with part references, transforms, colors, submodels, and metadata. Instead of asking the model to emit thousands of coordinates directly, Nova gives it instructions, parts-search tools, examples, geometry helpers, renderers, and collision or gap checks. The agent creates a structured plan and Python generator; the generator emits the final .ldr or .mpd artifact.

prompt + constraints + approved inventory
  -> plan.json: intent, submodels, parts, geometry, assembly notes
  -> generator.py: reusable construction logic and transforms
  -> model.mpd: deterministic LDraw artifact
  -> render set: front, rear, side, top, exploded, submodel views
  -> agent inspection and bounded revision
  -> deterministic validators
  -> human assembly review
  -> accepted release or evidence-backed rejection

This is a compiler-shaped workflow. The prompt is a requirement, the plan is an intermediate representation, the Python program is the generator, LDraw is the target language, and rendering is one test backend. That separation matters because each layer can be stored, diffed, hashed, replayed, and tested. A design that changes when the same generator runs twice has a different defect from a design that is deterministic but structurally invalid.

Recent brick-generation research reinforces the value of explicit structure. BrickNet reports that direct pose prediction quickly produces invalid sequences and uses a graph representation centered on connectivity. BrickAnything uses structure-aware tokenization, validity-constrained decoding, and rollback. Brick-Composer's assembly benchmark still finds current multimodal models far from reliable at selecting and placing parts. These projects differ from Nova, but converge on one point: relationships and legal assembly actions must be represented explicitly.

Start Nova only in an environment you control and verify current upstream instructions before running them. The repository currently documents two sibling repositories at the same tag and a Docker build:

git clone --branch v0.6.0 https://github.com/anteloc/ldraw-nova.git
git clone --branch v0.6.0 https://github.com/anteloc/ldraw-nova-docker.git
cd ldraw-nova-docker
docker compose build
docker compose up -d

The documented web app has no login and should run only on a trusted network. Do not expose its HTTP or self-signed HTTPS endpoints to the public internet. Pin repository tags or commits, inspect the compose files, restrict egress and credentials, and record the container-image digest used for the accepted model.

Define buildability as a versioned evidence package

“Buildable” should be a claim with named predicates, not a vibe. A small decorative model and a large Technic mechanism may need different thresholds, but both should identify what was checked, by which tool version, against which parts catalog, and by whom. Use a manifest that binds every artifact and decision.

schema: physical-cad-release/v1
design: tidal-observatory-r3
source:
  promptHash: "sha256:..."
  instructionsHash: "sha256:..."
  planHash: "sha256:..."
  generatorHash: "sha256:..."
  modelHash: "sha256:..."
environment:
  repoCommit: "immutable-sha"
  containerDigest: "sha256:..."
  ldrawLibrary: "2026-09"
checks:
  parse: pass
  missingParts: 0
  illegalColors: 0
  floatingComponents: 0
  collisions: 0
  gridWarningsApproved: 2
  deterministicRebuild: pass
inventory:
  source: approved-parts-list.csv
  unavailableCombinations: 0
assembly:
  instructionHash: "sha256:..."
  impossibleSteps: 0
physicalWitness:
  status: pending
  owner: human-builder
decision: blocked_until_physical_witness

The manifest separates facts from judgment. “Parser accepted UTF-8 and all part references resolved” is a fact. “Two half-stud offsets are acceptable for this decorative joint” is a review decision. “The model stood for 24 hours” is an observation tied to a specific build. The release record should preserve all three without letting a model turn one into another.

Hash the plan, generator, model, inventory, instructions, and test report. If the agent revises any one of them, create a new release candidate. A physical build of revision 2 cannot validate revision 3 merely because the render looks similar. This discipline also makes comparisons useful: teams can tell whether an improvement came from a new prompt, parts catalog, model, generator, or validator.

Run validators in a strict order

A validator should fail cheap defects before expensive ones. Start with file and catalog checks, then resolve hierarchy and transforms, construct a connection graph, test grounding and collisions, compare inventory, inspect assembly order, and only then spend human time on a physical build. A public LDraw Validator project demonstrates this decomposition with a parser, MPD loader, part catalog, spatial index, stud and anti-stud matching, grounding traversal, collision detection, grid checks, and rendering.

def accept(candidate, policy):
    assert parse(candidate.model).errors == []
    assert resolve_parts(candidate.model, policy.library).missing == []
    scene = flatten_submodels(candidate.model)
    graph = connection_graph(scene)
    assert ungrounded_components(graph, scene) == []
    assert illegal_collisions(scene, policy.tolerances) == []
    assert inventory_gaps(scene, candidate.inventory) == []
    assert rebuild(candidate.generator) == candidate.model_hash
    assert instruction_simulation(candidate.steps, graph).blocked == []
    return "READY_FOR_HUMAN_BUILD"

Do not hide warnings behind one score. A 98% “buildability score” can conceal one floating tower or a single impossible trapped part. Preserve issue type, part IDs, transforms, submodel, severity, validator version, screenshot, and disposition. Require a human to approve each exception by reason rather than lowering a global threshold.

Also test deterministic regeneration. Run the pinned generator twice in clean environments and compare canonicalized LDraw output. Normalize only fields explicitly declared non-semantic, such as timestamps. If part ordering changes, decide whether order affects assembly instructions before ignoring the diff.

Move from geometric validity to an assembly witness

A structurally connected final state may still be impossible to assemble. A brick can be trapped inside a closed shell; a submodel can require insertion through solid geometry; a hidden connector can be unreachable; a long cantilever can collapse before later support arrives. Build instructions are therefore part of the evidence, not a presentation accessory.

Generate numbered steps, a parts list per step, submodel boundaries, orientation changes, and detail views for difficult connections. For every step, check that the new part has a collision-free approach path and at least one intended connection after placement. Flag steps that require temporary support, flex, stress, unusual force, or disassembly. LDraw's ecosystem already includes step metadata and tools for instruction creation; use those capabilities instead of deriving instructions from a final render at the last minute.

Inventory is another independent gate. A part may exist in the digital library but not in the selected color, region, quantity, budget, or approved substitute set. Freeze the inventory input before generation when the goal is to build from what a person owns. GitHub issue number 1 on Nova asks for exactly this capability: design based on available blocks. Until the workflow enforces that constraint, inventory validation belongs after generation and before purchase.

The “never silently fix” rule is important. Skilled builders instinctively rotate a part, add support, substitute a color, or change an order. Those interventions are valuable, but they convert the event into a human-assisted repair. Record them and feed them back into a new generated revision. Otherwise the release claim overstates what the agent produced.

Treat the design workspace as an executable build system

Nova executes Python, searches libraries, calls model providers, renders files, and can expose a web interface. That is closer to a development environment than a static creative app. Run it with a non-root user, no personal cloud credentials, scoped provider keys, explicit filesystem mounts, bounded CPU and memory, and restricted network access. Store generated outputs outside the container, but mount only a dedicated working directory.

The repository's AGPL-3.0 license and included attribution material also matter. The project uses community libraries, model files, and tools with their own licenses or public-domain terms. If you redistribute a modified network service, model package, parts library, or generated derivative, review the applicable obligations and preserve attribution. This article does not determine the legal status of any specific output.

Do not treat chat history or model “thinking” as the authoritative design record. It may help debug intent, but the executable plan, generator, model, library version, validation report, and physical witness are what another team can reproduce. This follows the same principle as an AI agent execution receipt: record the effects and artifacts that matter, not merely a persuasive narrative of the run.

Failure modes a beautiful render can hide

Keep the language proportional to the evidence. “Renders successfully,” “passes validator X,” “matches inventory Y,” “instructions completed with two documented substitutions,” and “physically assembled by reviewer Z” are useful claims. “Manufacturable,” “production ready,” or “fully buildable” require a much broader control set than a single LEGO-style prototype.

A seven-step adoption checklist

1. Choose a bounded object. Start with a small static design whose expected parts, scale, budget, and purpose are explicit. Avoid mechanisms, flexible elements, heavy cantilevers, or safety-critical use.

2. Freeze the toolchain. Pin Nova, its Docker companion, model provider and version, parts library, renderers, validators, and environment image. Record licenses and network requirements.

3. Define the contract. Write pass/fail rules for parse, catalog, colors, connections, grounding, collisions, grid, inventory, deterministic regeneration, instructions, and human build evidence before generation begins.

4. Generate multiple candidates. Use the same prompt and budget. Compare constraint failures and repair cost, not only aesthetics. Preserve rejected artifacts so the team can identify recurring weaknesses.

5. Validate independently. Run deterministic checks outside the agent loop. Do not let the same model interpret its own warnings as harmless without evidence.

6. Build the exact revision. Use the frozen inventory and instructions. Log every substitution, manual fix, impossible step, stability issue, and ambiguous orientation.

7. Release with limits. Publish the manifest, validator versions, unresolved warnings, physical witness, and allowed claim. Reopen the decision when any artifact, library, or threshold changes.

FAQ

What is LDraw Nova?

It is an open-source agent toolchain that turns a prompt into a plan, Python generator, LDraw model, renders, interactive views, and editable exports using the LDraw parts ecosystem.

Does a valid LDraw file prove buildability?

No. It proves only that a supported parser can interpret the file. Connections, grounding, collisions, part availability, assembly order, strength, and a physical build remain separate gates.

Why generate Python instead of LDraw directly?

Code provides reusable construction primitives, loops, parameters, and a more familiar surface for current coding models. It also produces a deterministic artifact that can be rerun and diffed. The output still needs domain validation.

Can images be part of the acceptance test?

Yes, as one layer. Multi-angle and exploded renders help reviewers catch aesthetic defects, missing parts, and obvious intersections. They cannot replace connection, collision, inventory, or assembly evidence.

Is this approach limited to LEGO-style models?

No. The pattern applies to any agent-generated design where a structured intermediate representation can be compiled and tested: CAD, circuits, robot trajectories, fabrication plans, and parametric architecture. Each domain needs its own physical and safety gates.