WTWilly Tai
Estate Twin · Part 1

Teaching the twin to operate

A live demo of the operating loop I have delivered at estate scale: rules detect, a model proposes, a named person decides, and a ledger remembers.

Willy Tai · Smart Cities · AI · Sustainability · August 2026

There is a working digital twin on this site now. It is a small one: a twelve-storey block with a rooftop plant and a chiller yard, forty-one instrumented points, well under a megabyte over the wire, and light enough to run on a phone. You can orbit it, click any sensor, and break it. I built it because the twins I have delivered professionally belong to their owners and cannot be shown, and because a sentence like "I delivered a command centre with a digital twin interface" carries less weight than a thing you can press.

What this is, honestly. Every reading in the demo is synthetic and labelled as such. The fault scenario is scripted by me, chosen to be legible rather than discovered. What a production twin has to prove and a browser page cannot: integration across many suppliers' systems, data quality at the sensing layer, security, and years of sustained operation. What the page can show is the operating concept, which is the part I have delivered at scale and the part most twins get wrong.

The picture is the least interesting part. The block is deliberately schematic, a podium and a tower drawn in a hundred-odd lines of geometry, because the value of a monitoring twin lives in its points and its workflow. Each floor carries three instruments, the roof and the yard carry five machines, and every one of them is clickable.

Ask the panel for AHU-R1 and beneath its telemetry you will find a short list of plain sentences. AHU-R1 supplies air to L10. AHU-R1 supplies air to L11. CH-01 cools AHU-R1. These are the twin's relationships, declared in the data. In the code they are one line each:

ahus: [
  { id: "AHU-R1", serves: [10, 11, 12] },
  { id: "AHU-R2", serves: [4, 5, 6, 7, 8, 9] },
]

Everything that follows depends on those declarations.

The fault

Press the fault button and a bearing begins to fail on AHU-R1. What happens next is a chain, and the order matters. A rule catches it first: fan vibration reads 9.8 mm/s against a 7.1 limit, and the threshold trips. No model is involved. Then the consequence travels. Zone temperatures start drifting on levels ten, eleven and twelve, and on no other floors, because the twin knows which floors that machine serves. The duct riser lights up. The chiller picks up load trying to compensate and its own gauge climbs into amber. Each step lands in the event ledger with an actor tag, rule, system, AI or human, hash-chained so the sequence can be audited afterwards.

Only then does the model get involved. It proposes a diagnosis, supply fan bearing degradation, and it states its confidence, 0.87. It also shows its basis: the links it traversed to get there, which are the same serves declarations shown above, next to the observation that the drift appeared on exactly those floors. A model that must show the path it walked has far less room to invent one.

The model gets no say over priority or cost. Priority and the four-hour SLA come from a deterministic matrix, and the S$1,850 estimate comes from a rate card. The model contributes one field, the diagnosis, with its confidence attached. That division of labour is the same trust boundary I have written about elsewhere on this site, applied to a building.

The human

The work order then stops. It waits for a person, on the record, and the demo makes you be that person. Approve it and the repair is dispatched, the telemetry normalises, the ledger closes the loop. Reject it and the fault stays open and visible. Nothing self-executes, which in my experience is the property that lets an estate owner say yes to automation in the first place.

Two smaller details earn their place. The twin loads with one work order already open: a CO2 sensor on level two, stuck low since early morning, part on order. I put it there because the honest majority of real FM alerts are the instruments themselves, and a twin that only ever shows healthy machinery is advertising. And in the corner of the viewport there is a line that reads 39 of 41 assets fully linked, with two loose ends named. Those loose ends are real. The second chiller has no declared load path, the pump has no declared system membership, and the twin admits it. A monitoring system that cannot admit ignorance will fake confidence instead, and that is how small faults become large invoices.

The demo is at willytai.com/apps/estate-twin, and the case study behind it sets out what it demonstrates and what it honestly cannot. The next part of this series pushes the argument further: if the workflow is the value, how much of the picture do you actually need? I deleted most of mine to find out.

Estate Twin, Part 1 · Open the twin · The case study · Next: State, kind, rough location