HVAC spatial intelligence for architects, from day one

The technical bet is that the relationship between a building's rooms and its systems is learnable from the thousands of coordinated buildings that already exist — if those buildings are first turned into a form a model can learn from. That form is a graph, and building it is most of the work so far.

A four-stage pipeline reads a coordinated building model and writes one validated graph per building. It accepts both Revit models (via export scripts run inside Revit) and IFC files (fully headless); nothing downstream knows which source a building came from. Every categorical value comes from a controlled vocabulary (17 dimensions, e.g. 123 ASHRAE room functions, 4 HVAC-strategy facets), so graphs from different buildings are directly comparable.

The fleet today

All are public research datasets. Each one can be explored in the Project viewer.

What is automatic, what is not

• Automatic (minutes): extraction, graph construction, equipment-name normalization (multilingual, cached), typical-floor replication, validation against the schema and vocabulary, regression checks across the fleet, visual review pages.
• Human (hours): a per-building config file (declare the HVAC strategy, a few keyword rules for room types, occasional manual fixes where the model missed a door), a visual inspection pass. Domain questions are logged and ruled on — never guessed by code.

Scale of the asset: ~19k lines of pipeline, extraction and visualization code; ~12k lines of schema, conventions and 300+ logged decisions.

The question that matters commercially is not "can a model fit these buildings" but "can it predict a building it has never seen". Every result below therefore uses leave-one-building-out evaluation: train on seven buildings, test on the eighth, rotate. The model only ever sees inputs that an architect's massing can provide — room geometry, use, level, adjacency — never anything derived from the HVAC it is asked to predict.

Two tasks

Headline results (unseen buildings, exact-class accuracy)

Three findings that shape the plan

• The graph is what carries the signal. Removing the room-to-room edge attributes (is the neighbour open-plan? how much wall is shared?) costs 9.6 points on duct depth; removing the graph entirely costs 5. The representation choice is validated.
• Building-level labels currently hurt. With seven training buildings, "HVAC strategy" and "climate zone" act as a building ID — the model memorizes them. Dropping them is now the default; they will be re-enabled automatically once each strategy appears in at least three buildings. This is a data-size effect, not a modeling error.
• More buildings are the binding constraint, not model capacity. Accuracy rises monotonically with the number of training buildings and shows no plateau at n=7 (chart below). Task 2 (plant rooms and shafts) is not learnable at all yet at n=8 — it is a rate table — and it is exactly the task that architecture-only models (no HVAC modelled) can feed, because plant rooms and shafts appear in an architect's room schedule.

The product wraps the same graph contract in a workflow an architect can use in five minutes. Started 2026-08-18; the first milestone is a scripted end-to-end demo on one clean building, the second a hardened version for small-firm trials.

• Ingest → graph → viewer built — a massing file becomes the same dual-graph JSON the pipeline writes (HVAC layer empty), rendered in a three.js viewer with adjacency overlays.
• Space tagging built — one structured LLM call proposes an ASHRAE use per space with confidence; the user confirms or corrects; every confirmation is logged as training signal.
• Guided configuration built — location → climate-zone proposal the user confirms; a 10-point priority allocation (space, efficiency, cost, carbon, adaptability) maps deterministically onto 2–3 recommended HVAC strategies plus a contrasting trade-off pick.
• Conversational agent + tool surface built — one agent with deterministic tools, exposed as an MCP server so the same capabilities can be driven from the web app today and a Rhino-side client later.
• Engine v1 live — an expert-prompted estimator grounded in our curated HVAC knowledge pack (distilled from engineering references; every number cites a pack item and returns an interval). Learned models replace rule estimates per task only when they beat them on unseen buildings — the ML section above is that gate.
• Reservation volumes in 3-D, score panel next.

Design rules that hold throughout: the graph JSON is the only contract between components; no number ships without provenance and an interval; user decisions are telemetry from day one, because each session on a live project is a labelled data point for the corpus.

Today's results predict one system's spatial footprint. The research programme behind Rubber Duck aims higher: treat architecture and building systems as one coupled, jointly learnable object, and let a designer steer the trade-offs between them explicitly.

• Masked prediction on the joint graph. Hide any part of the combined space + systems graph and reconstruct it from context — hide all HVAC and recover the shafts; hide the rooms around a plant room and recover what the layout must have been. One representation, many questions.
• Learning from design evolution. Where firms keep pre- and post-coordination versions of a model, temporal graph models can learn what changed and why — predicting which elements a coordination round will move, before it happens.
• Multi-priority optimization. There is no single ground truth in early design: a configuration that minimizes ceiling depth may cost efficiency or carbon. The goal is a model that scores a candidate against several objectives at once — spatial footprint, system efficiency, cost and carbon proxies, adaptability — so the architect front-loads the negotiation rather than discovering it in week 30. The app's priority allocation is the first, deterministic version of this dial; the learned version is the destination.
• Beyond HVAC, beyond buildings. The same dual-graph idea applies to structure, electrical and plumbing, and to other co-developed engineered systems where early decisions in one domain silently constrain another.