What’s new about the engine.

Most design tools draw what you tell them. Buildable is built as a design factory: it generates a design from a kit and its context, checks it, and hands you a package that says exactly where every file came from. This page explains the three ideas behind that, and what is true of them today.

Context: what applies where you build

Before a line is drawn, a design already has a setting: a jurisdiction with its permit thresholds, a style you have in mind, a supplier whose catalog you intend to buy from. Buildable carries that setting as context packages.

A context package is versioned, attributed reference data attached to a revision. Each one names its publisher, the sources it rests on and the date those sources were read. A regulation package records what an authority publishes, with the conditions attached. A style package records a preference. A materials package records what a supplier actually sells. When you commit a revision, it pins the package versions it used. Change a package later and existing revisions keep the version they were built with, so a result from last month can still be reproduced next year.

What a context package never does is decide for you. It is orientation for you and your reviewer, and every package shows its own weakest link: “sourced, applicability unverified” means exactly that. Today the packages are published by Buildable. Companies and people publishing their own attributed styles, catalogs and guidance is on the roadmap.

Kits: a product system, written down

Generic CAD starts from a blank sheet. Buildable starts from a kit: a real construction system described as parameters, limits and rules. A 600 mm timber module. A plywood cassette grid that only allows certain sizes. A single-span portal frame with a stated haunch.

Above each kit sits a family, which answers the question “what am I designing”: a house envelope, a deck, a portal frame, a folded enclosure. The family owns its inputs, its geometry kernel, the checks and exports it may use, its review scope and the published sources it rests on. The kit answers “which product realises it”. The timber-frame concept and the WikiHouse Skylark 150 are the two kits of the house family; a manufacturer’s panel system would be a third.

Each kit publishes an execution contract: its kernel, the checks that must run, the files it can export and the context it loads by default. Contracts are versioned and immutable. A revision binds to the contract version it was built with, and a retry or a new generation from that revision uses the same one. To adopt a newer contract, you make a new revision. Nothing about how your design was made can quietly change underneath it.

Because the engine designs inside the kit’s limits, what it proposes stays within what that system can build. That is the difference between a picture of a house and an enquiry a manufacturer can price.

The engine: deterministic where it counts

A language model is good at reading a brief and proposing. It is the wrong tool for producing geometry, because two runs of the same prompt can give two different answers, and nobody can sign off on that.

So Buildable separates the two. A brief becomes a typed proposal: dimensions, a kit, options, each checked against the family’s schema. Only deterministic, versioned geometry code turns that proposal into members, openings and quantities. Same inputs, same result, every time, on a bounded run with a stated budget. When validation fails you get a list of issues, not a success artifact with a problem hidden inside it.

Checks that say what they are

Every check the engine runs declares two things: what class it belongs to, and whether it is deterministic. The class decides what the check is even allowed to say.

• A bounds or integrity check evaluates the model directly and may pass or fail.
• A prescriptive check evaluates a published rule with its conditions, read from a pinned context package. Outside the rule’s stated scope it says out of envelope, which is not a failure and not a pass.
• An engineering check runs only inside a validated envelope and refuses outside it rather than extrapolating.
• An applicability finding, which decides which rules may govern a project at all, is never a pass. Its strongest output is a candidate for a person to confirm, attributed to a source with a date.

Green is reserved for a deterministic check that passed inside its envelope. Not assessed, out of envelope and refused are shown as what they are. Every result carries its provenance: the kit version, the context package versions it read, the implementation that evaluated it and a hash of its inputs, so someone other than us can reproduce it.

Two more rules matter. Passing every check is not approval; expert opinion, manufacturing release and an authority decision remain separate steps. And a workflow only counts as qualified for a family and a jurisdiction once a fixture set with independently verified results exists and a named professional there has accepted the check definitions. Until then it runs advisory, and says so wherever it appears. Today, every check runs advisory.

The package: one revision, every file

A download from Buildable is a revision package. The DXF layouts, the IFC4 model and the CSV quantities are generated from the same revision, so a wall in the drawing is the same wall in the model and the same wall in the schedule. The CAD files are read back and compared to their source revision before they download. Each file carries a hash.

That hash is what the rest of the platform hangs on. A colleague’s comment is anchored to the revision they commented on. An expert’s quote names what is in scope and what is not. A sign-off names the exact revision, what was checked, what was not assessed and the conditions it depends on, and it does not carry over when the design changes. Change a dimension and Buildable names which checks, drawings, quantities and exports it invalidates, and which it leaves alone.

What this changes for you

• Fewer surprises. A result can be reproduced, not just remembered.
• No orphan files. Every file in a package names the revision, kit and context it came from.
• An honest review. A reviewer knows exactly what they are looking at, and what has not been looked at.
• Nothing weakens quietly. A changed design withdraws a sign-off rather than inheriting it.

Where this is today

The house family is the pilot, with the timber-frame concept and Skylark 150 kits. Steel portal frames, sheet-metal enclosures and framed openings are illustrative: they run through the same engine and contract, and describe nothing anyone may build from yet. Decks, outbuildings, exhibition stands, garden structures and joinery are planned families that evaluate a brief against a published envelope and produce no geometry. The files are concept files, with no joints, cut angles, connections or structural approval. Every check runs advisory. Scoped quotes, revision-bound sign-offs and the view of what a change affects are built and tested, and arrive in the next release.

We publish that status in the product, on the catalog and on the roadmap, and this page will change as the engine does.