OrionFlow
Research Try it
Research · 2026

A kernel-independent IR for editable CAD

A text-to-CAD model is only useful if an engineer can keep working on what it produces. That single requirement is why OrionFlow puts a feature graph, not geometry, at its centre.

OrionFlow Research6 min read

Most generative-CAD systems output the wrong thing. They emit a mesh, a point cloud, or a one-shot script — artifacts that look right but are dead on arrival in an engineer's workflow. You can't change a fillet radius on a mesh. You can't re-pitch a bolt pattern on a frozen STL. The geometry is the output, so the design intent is gone.

OrionFlow inverts that. The model never generates geometry directly. It generates a FeatureGraph — a structured, parametric description of how the part is built — and a deterministic compiler turns that into solids. The geometry is a view of the model, not the model itself.

What the FeatureGraph holds

The IR captures the things a CAD engineer actually manipulates:

  • Features in build order — sketches, pads, pockets, revolutions, holes, fillets, patterns — each with its editable parameters.
  • Sketches with their geometry, external references, and a full constraint graph (which entities each constraint binds, driving vs. reference, degrees of freedom).
  • Dependencies — the real ones: which sketch profiles which pad, what a feature stands on, which parameters drive which others.
  • Parameters — named values bound back to the features they control, so an edit is a number change, not a redraw.

One representation, many targets

Because the IR describes intent rather than a specific kernel's API, it isn't tied to any one CAD engine. The same FeatureGraph compiles to native FreeCAD PartDesign history and to build123d Python — and could compile to others. FreeCAD is one backend, not the source of truth.

Why this matters

Separating CAD semantics from CAD implementation makes the dataset and the models durable. The representation outlives any single kernel's quirks, and the same model can be retargeted as the toolchain evolves.

It reads like a language

The FeatureGraph has a lossless text form — the OrionFlow DSL — that round-trips exactly with the JSON IR. It's readable enough to reason about, and stable enough to train a language model on directly:

PARAM plate_w = 100 mm
PARAM hole_d  = 15 mm

BODY Plate
SKETCH base ON XY
  RECT 100 x 50
  CONSTRAINT fully_constrained
PAD base  Length=10mm
SKETCH seat ON Plate.Face(normal=+Z)
  CIRCLE d=hole_d
POCKET seat  Length=5mm
PATTERN seat  count=2  spacing=50mm

The same model is a graph for the geometry engine and a sentence for the language model. Neither is a translation of the other — they're two skins on one canonical object.

The payoff

Putting the IR first is what makes everything downstream possible: deterministic reconstruction, parametric edits, stable topology references, and a training corpus that teaches design intent rather than surface shape. The geometry is easy once the intent is explicit.

Next: Teaching a model to think like a CAD engine →

← All research