Skip to content
← BloomPrint

The geometry-first design engine

Rebuilding a design system so the drawing and the shopping list cannot disagree.

Type
System · Python
Period
August – September 2026
Status
Phases 0-8.1 complete and tested.

The original pipeline asked an AI for plants and then went looking for somewhere to put them. Quantities were requested up front, the plant list was written from those requests, and the drawing was produced separately — so the list could say twelve, the drawing could show nine, and both were correct. I inverted the whole thing.

9phases, 0 through 8.1
0AI calls in the design path
5human-approved reference plantings

The challenge

A planting plan is four artifacts that have to agree: a drawing, a plant list, a price, and a set of installation measurements. In the original architecture each was produced from a different place. There was no bug to fix — the numbers were each correctly derived from their own source. There were simply several sources.

A customer cannot use a plan whose diagram and shopping list differ. Neither can a nursery employee standing in a greenhouse pulling stock.

What I built

A rebuilt engine that runs in one direction only:

understand the site → generate design spaces → structural framework → drift framework → design skeleton → select species → solve geometry → optimize → validate → persist.

The skeleton is built from site geometry alone, before any plant is chosen — an unplanted plan of where mass, structure, drift and edge belong. Species are then assigned to that skeleton without being allowed to redesign it. Individual plants are placed as real points at real spacing inside real polygons. Only then is anything counted.

My approach

Two rules carry the whole architecture, and both are enforced structurally rather than by convention.

Every design decision has a deterministic reason stored as structured data. The narrative a customer reads is `render(explanation_data)`, never `generate(explanation)`. The prose cannot drift from the design because it is not written from the design, it is written from the design's record.

Quantity is an output, not an input. Points are fitted inside the geometry at the correct spacing, and the count that results is the quantity. The plant list counts persisted placements. The price multiplies that count. The installation instructions measure to those same points. They cannot disagree, because there is no second number anywhere in the path.

How AI is used

The architecture names a boundary and refuses to blur it. A creative layer may use AI and produces proposals — a `DesignIntent` — which carry no authority at all. An engineering layer is deterministic, owns the truth, and may reject or modify any proposal when constraints require it, recording that it did.

Nothing in the integration module calls a model. An LLM may interpret what the customer wrote before the design starts, and narrate the result after it finishes. By the time any narrative runs, every quantity and coordinate is already a persisted fact.

Key decisions

Build the skeleton unplanted
Deciding structure before species is what stops the plant palette dictating the composition. It is also what makes a thin catalog produce a plainer planting rather than a broken one.
Wire it in behind a flag
The new engine writes two keys — site geometry and plant list — and every existing customer surface already reads those. One seam, one flag, no rewrite of the front end.
Refusal is a valid output
When the catalog cannot support the site, the readiness gate refuses, and the refusal is the result. No geometry is invented to cover it.
Goldens are references, not assertions
Five human-approved plantings are stored with their full record — intake, pattern spec, inventory provenance, assignments, quantities, coordinates. Nothing in the test suite asserts against them. Turning a golden into a numerical gate is how you get a rule that is right on every case and declines every plan.

The result

Phases 0 through 8.1 are complete, tested and pushed. The engine runs behind a flag in the live application, produces plans whose four artifacts are derived from one record, and stores a structured reason for every decision it made — including the moves the optimizer tried and refused, and the improvements it declined.