The Twin & the Building

A twin and its building are bound by a loop with two directions, and understanding a twin means understanding both. The up arrow carries state: streams from sensors, meters and the BMS - temperatures, flows, energy, occupancy, equipment status - keeping the virtual model a faithful mirror of what is happening now. This is the arrow every twin must have; without it the model is a static drawing.

The down arrow carries insight and, sometimes, command. At its gentlest it is information to a human: an alert, a diagnosis, a ranked list of what to fix. Tighter, it becomes a recommendation an operator approves. Tightest, it is a command written straight back into the BMS - a new setpoint, a reset, a schedule change - closing the loop without a human in the middle.

The up arrow is largely a data-engineering problem: get trustworthy readings, tagged and current, into the model. The down arrow is where the stakes climb, because acting on a building can waste energy, break comfort, or trip safety systems if the twin is wrong. So the essential question about any twin is not does it have a model but how far does its down arrow reach, and has it earned that reach. The rest of this lesson is a map of the answers.

Twins are easiest to understand by what they are for, and three purposes cover most of the field. A monitoring twin mirrors the live building and reports: it aggregates data, visualises state, benchmarks performance and raises alerts and fault diagnoses. Its down arrow reaches only to a human dashboard - it is essentially read-only, and it is where the great majority of real building twins live today, delivering value through fault detection and diagnostics (FDD) and energy insight.

A simulation twin adds a predictive model you can ask what-if. Calibrated against real data, it lets you rehearse a decision offline before touching the building: what happens to comfort and energy if we raise the chilled-water temperature, shift the pre-cool start, or reconfigure a zone? The building is unaffected while you experiment; the value is safe, cheap rehearsal of changes and scenarios.

A control twin closes the loop. It does not just watch or rehearse - it decides and acts, writing commands back to the plant, continuously optimising against a goal such as least energy at guaranteed comfort. Model predictive control (MPC) is the classic engine: it uses a model plus forecasts of weather and occupancy to choose the best actions over a horizon, applies the first step, then re-plans as new data arrives. Control twins are the most powerful and the most demanding - they only make sense on a building whose data and models can genuinely be trusted.

The three purposes line up on a single spectrum of loop tightness - how directly the twin's output reaches the building - and it is worth naming the rungs. At the loosest, a twin is read-only: it observes and reports, and every action is taken by a human who may ignore it. Next, advisory: the twin recommends specific actions and a human approves or rejects each one - the human is the safety valve. Then supervisory or closed-loop with oversight: the twin writes setpoints and schedules directly, but within guardrails, with operators watching and able to override. At the tightest, closed-loop autonomy: the twin optimises continuously with only occasional human review.

Tightening the loop multiplies both value and risk. A read-only twin can only ever be as good as the humans who act on it, but it cannot itself break the building. A closed-loop twin can capture savings no human would chase minute by minute - yet a wrong model or a bad sensor now moves real plant, with real consequences for comfort, energy and even safety. That is why serious deployments almost always start read-only, prove the twin agrees with reality, then tighten the loop one guarded step at a time, keeping humans in the loop until trust is earned. Crucially, safety-critical functions - fire, life-safety, structural - are never handed to an experimental twin; those stay with certified, independent systems, and statutory sign-off belongs to qualified professionals.

The single most useful habit from lesson 0.1 was to ask of any twin: what decision does it serve. Here that habit becomes a design rule - the purpose sets the loop. You do not choose monitoring, simulation or control, or read-only versus closed-loop, as a matter of ambition or fashion; you derive it from the job to be done and what the building can support.

Work it backwards. Name the decision - cut cooling energy, cut nuisance faults, plan a retrofit, hold tighter comfort. Ask what the twin must do to serve it: just surface the problem (monitoring), test options first (simulation), or act continuously (control)? Ask how tight the loop must be, and - honestly - whether the data and models are trustworthy enough to support that tightness. A twin built to cut energy through continuous optimisation but fed sparse, drifting data will make confident, wrong moves; the same building is far better served, for now, by a read-only twin that finds the ten biggest faults.

This is also why a building often carries several twins, or one twin used several ways: a monitoring layer for daily operations, a simulation model for planning changes, and control loops only on the subsystems that have earned them. Purpose first, then the tightness the building can actually support - that ordering keeps twins honest and is the through-line into the rest of this course.

Watch a single decision travel the spectrum and the abstractions turn concrete. Take an office that spends too much on cooling, and the goal: cut cooling energy without losing comfort.

Stage one is a monitoring twin. It ingests BMS points and meter data, tags them with a schema, and runs fault detection. Within weeks it surfaces the unglamorous truth: two air handlers are heating and cooling at the same time (simultaneous heating and cooling), a damper is stuck open, and the plant runs full-tilt two hours before anyone arrives. The down arrow reaches a facilities manager, who fixes the faults by hand. This alone often captures the biggest, cheapest savings - and it is entirely read-only.

Stage two adds a simulation twin. Before changing the operating strategy, the team calibrates a model against the now-clean data and asks what-if: what happens to comfort and energy if we raise the chilled-water setpoint by a degree, or start pre-cooling later and lean on the building's thermal mass? They rehearse a dozen scenarios offline, with the real building untouched, and pick the safe winners.

Stage three, once the data and model have earned trust, tightens to a control twin on that one subsystem: an MPC loop that pre-cools against the weather forecast at the cheapest hours and resets setpoints continuously, inside guardrails, with the operator watching and able to override. Same building, same goal - but three distinct twins, each earned by the one before. That progression, watch then rehearse then act, is the safe path the whole industry follows.

Notice what made each stage possible: the monitoring twin cleaned the data that the simulation twin needed to calibrate, and the simulation twin proved the strategy that the control twin then automates. Skip a stage - reach straight for MPC on a building riddled with faults and mislabelled points - and the loop closes on garbage. The order is not bureaucracy; it is how trust is manufactured, one arrow at a time.