work / ai builder
A design tool that isn't allowed to be wrong.
Generative design is easy to demo and hard to trust: the pretty render is the part nobody checks. This one generates cabins that have to survive a building-code rule engine, a cost model, and a set of physics simulations before it is allowed to show you anything — and it exports to the formats a contractor and a plan reviewer actually open.
5,919 lines of python · NSGA-II over 3 objectives · seattle residential code · IFC / DXF / STL / glTF
prototype · runs locally under docker-compose
the problem
Ask a model for a cabin and you get an image. An image is not a building. The gap between the two is filled with the things that actually decide whether a structure can exist: the setback from the property line, the floor-area ratio the zone allows, the height limit, where the drain lines fall, what it costs, and whether the room gets any daylight.
So the interesting question isn't "can a machine draw a cabin" — it obviously can. It's whether a machine can propose something that a plan reviewer wouldn't reject on sight. That means the generator has to be wrapped in things that can tell it no.
how it works
A parametric geometry kernel produces the candidate cabin. Everything downstream exists to argue with it.
The rule engine is the spine. It encodes Seattle residential zoning as data rather than as prose a human has to remember — per-zone minimum lot area, maximum lot coverage, height cap, floor-area ratio, and front, rear and side setbacks. A violation isn't a boolean; it carries a severity, the location, a remedy, and a reference back to the code section it came from. That last field is the one that matters: a compliance tool that tells you "no" without telling you which rule is unusable by the person who has to fix it.
Optimisation is multi-objective, because the objectives genuinely conflict. Spaciousness, cost and comfort cannot be jointly maximised — a bigger volume costs more and is harder to condition. So it runs NSGA-II (via pymoo, 50 generations, population 100) and keeps the Pareto front rather than collapsing everything into one weighted score. Collapsing would have been easier and would have quietly buried the trade-off inside a weighting nobody chose on purpose. The front hands the trade-off back to the person making the decision, which is where it belongs. Zoning constraints enter as real constraints, so an infeasible design is excluded rather than penalised into the population.
Perceived spaciousness is a small neural net, and it's honest about being a proxy. PSSNet is a PyTorch MLP — twelve geometric inputs through 64 → 32 → 16 → 1, dropout 0.2, a sigmoid scaled to 0–100. It is not measuring how a room feels; it is fitting a number to geometry so the optimiser has a differentiable-ish objective for something humans only report qualitatively. Worth having, worth naming as a proxy.
MEP routing is where "buildable" stops being a slogan. Fixtures get placed, then supply lines, drain lines and vent stacks get routed to them; electrical designs circuits, computes the load, places receptacles and emits a one-line diagram; HVAC and site utilities — including septic where there's no sewer — get their own passes. A cabin that can't be plumbed is not a design, it's a picture.
The simulations use the metrics the field already uses, rather than inventing friendlier ones: daylight factor, daylight autonomy and useful daylight illuminance for light; EUI for energy. Using the standard metric means a real practitioner can disagree with the output, which is the entire point of producing it.
Export is the honesty test. IFC4, DXF, STL, glTF and PDF — IFC because that is what a plan reviewer's software ingests, DXF because that is what the drawing set lives in, STL and glTF for geometry and the Three.js viewer. Anything that only exports a screenshot has quietly decided it is not meant to be built.
what it is not
It is a prototype, and the stamp says so. It runs locally under docker-compose; it has no users, no deployment and no adoption to claim, and this page claims none.
The code rules are encoded for Seattle and Washington. That is a real scope, not a soft one — a setback table is jurisdiction-specific, and pointing this at another city means re-encoding, not re-configuring. The cost model is assembly-based, which is right for comparing two designs against each other and wrong for quoting a build. And the compliance engine checks what it encodes: passing it is evidence, never a permit.
It was also built fast, with AI assistance, under my direction — which is the thread that ties it to everything else here. Directing that well is not "prompting until it compiles": it's holding the architecture, knowing the domain well enough to catch a plausible-looking setback table that is wrong, and deciding where the system is allowed to guess. The rule engine returning a code reference with every violation exists because I wanted the output to be checkable by someone who doesn't trust it. That is the same instinct as the rest of this site.
why it's on this site
Same move as everything else: find a place where a confident-looking output can be quietly wrong, then build the thing that makes it prove itself. A generative design tool without a code engine is a very good picture generator. The code engine is what makes it a design tool.