A Reference Architecture for Constrained AI-Assisted Design

Bounded generation: Let AI choose within a space where a deterministic engine guarantees validity.

Most attempts to put AI into design tooling adopt a generate-then-fix flow: the model produces an artifact, and downstream steps try to repair it into something valid. For anything that must be manufactured or coordinated, that is backward. 

This article describes an alternative reference architecture, bounded generation, where the space of possible outputs is constrained up front so that everything the system can produce is valid by construction. The rest of this piece focuses on the solution: its components, the interfaces between them, and the decisions that make the guarantee hold.

The Problem With Generate-Then-Fix

When a generative model emits geometry directly, correctness is a post-hoc hope. You validate, you repair, you re-prompt, and you still cannot guarantee the next output is buildable, reproducible, or reviewable. The failure surface is unbounded because the output space is unbounded. The safeguards you bolt on afterward — mesh repair, constraint checking, human rework — are all trying to claw back a property the system never had. The real issue is architectural: validity is treated as something you evaluate for at the end rather than something the system cannot violate.

The Architectural Principle: Bounded Generation

Invert the flow. Define a bounded, valid space first, then let the AI operate only inside it. An expert authors a parametric model whose every parameter combination yields a valid object; the AI selects parameter values; a deterministic engine renders geometry. Correctness moves from a runtime check to a structural property of the system. It is the same instinct behind type systems: rather than validate arbitrary input after the fact, you make invalid states unrepresentable. The parametric model is the grammar, and the parameter bounds are its production rules.

Figure 1. Bounded generation: authority (parametric model), contract (parameters), evaluator (headless run plus metrics), and an advisory AI layer that never emits geometry. Illustrative.

The Four Components of the Solution

The architecture has exactly four parts. Only one is allowed to be non-deterministic, and it is deliberately the part with the least authority.

• Authority (the model). A deterministic parametric model, in our case an Autodesk Dynamo graph, that is the only source of geometry. Nothing else may produce a vertex, and it is the only component that touches a geometry kernel.
• Contract (the parameters). The model's exposed inputs, extracted into a small, typed, bounded schema. This is the only surface the AI and orchestration code read and write.
• Evaluator (the truth). Headless execution for a given parameter vector, followed by a metrics harness that turns the exported geometry into objective numbers.
• Advisory layer (the AI). The only non-deterministic component. It proposes parameter vectors and interprets metrics, with no path to raw geometry. At worst it picks a suboptimal point inside an already-valid space.

The Parameter Schema as a Contract

The schema is a load-bearing interface, and three properties make it work. 

• Semantic naming: a parameter is wall_thickness_mm, not slider_7, so the AI and any reviewer know what they are changing. 
• Authored bounds: because the range comes from a human who understands the design, an out-of-range value is not rejected later; it is unrepresentable. 
• Declared couplings: when two parameters must move together to stay manufacturable, the contract records it so an edit to one propagates instead of silently breaking the part. 

Extracting this is mechanical: a Dynamo .dyn file is JSON, and the exposed sliders already carry their bounds.

parameters:
  - name: wall_thickness_mm   # semantic name, not an opaque id
     type: float
     min: 1.5
     max: 4.0
     couples_with: [rib_height_mm]   # constraint stitching
  - name: base_radius_mm
     type: float
     min: 20.0
     max: 60.0

The Evaluator: Turning Geometry Into Evidence

Running the model headlessly is only half of it; the other half measures what came out. A stdlib metrics harness parses each exported mesh (STL or OBJ) and computes objective properties, so a candidate is judged on measurements rather than on how it looks in a render:

• Export success. Was a mesh actually written? A run can report success and still produce nothing.
• Watertight and manifold. Welding coincident vertices and counting triangles per edge: a solid is watertight when every edge is shared by exactly two triangles, and any boundary or non-manifold edge is a concrete defect.
• Geometry metrics. Enclosed volume, surface area, and bounding box, so variants compare quantitatively against targets.
• Reproducibility fingerprint. A hash of the welded triangles confirms the same vector reproduces the same mesh to tolerance.

Because these checks are deterministic, the valid fraction of a whole parameter sweep can be reported as a number rather than asserted.

Anatomy of a Request

A single design request flows through five stages, and the discipline is in stage three:

1. Resolve intent to a parameter vector within the contract.
2. Execute the engine headlessly with that vector.
3. Reconcile: a zero-exit code only means the file loaded; missing package nodes can silently return null, so check the actual file on disk and the evaluation log before trusting the run.
4. Measure the artifact and return metrics to the advisory layer.
5. The advisory layer iterates or ranks; a human approves.

Treating exit code zero as proof of success is exactly how a pipeline ends up quietly shipping empty results. Inside this boundary, the AI maps intent to parameters, runs guided search, learns a surrogate, and ranks candidates. Outside it is a single thing, producing geometry, which stays with the deterministic engine permanently. Keeping the line there lets you adopt more capable models without adding risk.

What You Gain and the Trade-Offs

• Validity by construction. The buildable-space guarantee removes the largest class of failures.
• Reproducibility and auditability. A design is a vector, verifiable by fingerprint and reviewable as a diff of named parameters, not an opaque mesh.
• Confidentiality. The advisory layer touches only abstract parameters and metrics, so proprietary internals stay in-house.
• The cost. Someone must author the model and its bounds, parameters must be named meaningfully, and large spaces need surrogate models rather than exhaustive sweeps. If you need open-ended novel form, this pattern constrains you on purpose.

Status and Summary

The deterministic substrate, parameter extraction, headless execution, sweeps, and the metrics evaluator are implemented and running on generic models; the AI advisory layer is architecture and roadmap, not benchmarked results. The value of the pattern is that it makes those AI roles safe to add on a foundation that already guarantees validity. Define the valid space first, extract it as a typed contract, measure every result, and confine the AI to choosing inside that space. Constrain the space first, and the AI becomes a trustworthy collaborator inside guardrails instead of an unpredictable geometry generator.