Hype versus Reality

Start by naming the marketing, because you will hear it constantly. Digital twin gets oversold as any 3D model of a building - a spinning BIM viewer relabelled, with no live data behind it. It is sold as autonomous - implying the building runs itself - when the product is really a read-only dashboard. It is sold as plug-and-play - connect it and savings appear - when the real work is months of integrating silos and cleaning data. And it is sold with a single headline number, 30% energy savings, lifted from a best-case pilot and quietly presented as a guarantee.

Smart building is oversold the same way: a building called smart because it has an app and some connected gadgets, with none of the integration that lesson 0.2 showed is where smartness actually lives. The industry even has nicknames for the practice - twin-washing and smart-washing - slapping the label on a thin product to ride the trend.

None of this means the technology is fake. Genuine twins cut real energy, catch real faults, and inform real retrofits. The problem is that the marketing collapses a hard, systems-level, multi-year effort into a screenshot - and a buyer who believes the screenshot pays for a capability the product does not have. Your first defence is simply knowing the difference between what is shown and what is delivered.

The heart of the hype problem is the performance gap - the distance between how a system behaves in a demo and how it behaves after a year of real operation. In the demo everything is fresh: sensors are calibrated, data is complete, the model was tuned last week, and an expert is driving. In operation, entropy sets in. Sensors drift or die and nobody notices. A subsystem is replaced and its data stops flowing. The people who understood the model move on. Alarms pile up until operators ignore them all - alarm fatigue - and the green dashboard quietly stops meaning anything.

This gap is not the technology failing; it is the operating model around it decaying. A twin is not a product you install once - it is a living system that needs data quality, upkeep and someone whose job is to act on it. Buildings themselves keep changing - tenants, uses, plant, seasons - so a model calibrated at handover drifts away from reality unless it is re-tuned.

The practical lesson is to discount the demo and ask about operation. What did this system deliver in year two, not week one, on a building like mine? Who kept the data clean and acted on the insight? What decayed, and how was it caught? Vendors who can answer those questions honestly are the ones worth trusting; a demo that cannot speak to sustained, measured performance is telling you only that the technology can work under ideal conditions - which was never in doubt.

Smart-building and twin projects rarely fail with a bang; they fade. A handful of failure modes recur so reliably that knowing them is half the defence.

Data silos. Subsystems that will not share data - closed protocols, no common schema - so the twin never sees the whole building and analytics starve. This is the number-one killer, and it is why lesson 0.2 stressed integration.

No purpose. A twin built because twins are fashionable, serving no named decision. It looks impressive, changes nothing, and is quietly switched off when budgets tighten. A twin with no decision to serve is an expensive screen-saver.

Unmaintained data and models. Sensors drift, points break, models go stale, and no one owns the upkeep - so the twin slowly fills with wrong data and loses trust. Once operators stop believing it, it is dead even if it still runs.

No owner. Nobody whose job is to act on the output. Insight that lands on no desk is not acted on, and value never materialises. Over-scoping compounds all of these: reaching for autonomous, whole-portfolio optimisation before proving a single read-only use case, so the project collapses under its own ambition. And under all of them sits security and privacy debt - connected buildings widen the cyber-attack surface and collect data about real people, and a project that treats those as afterthoughts is one incident away from failure. Spot any of these early and you can usually save the project - or decline it.

Cut through all of it with four blunt questions - the same instinct from lesson 0.1, sharpened into a checklist. Ask them of any smart-building or twin proposal before a rupee or dollar is spent.

1. Purpose - what decision does it serve? Make the vendor name the specific decision or outcome: which energy cost, which fault, which retrofit. If the answer is vague - visibility, insight, a single pane of glass - with no decision attached, you are being sold a screen-saver.

2. Data - is it live, trusted and complete? A twin is only as good as its feed. Ask where the data comes from, how fresh it is, how gaps and drift are caught, and whether the building is instrumented enough to answer the question being asked. Stale or sparse data yields confident, wrong answers.

3. Owner - who acts on it and maintains it? Name the human who will read the output, act on it, and keep the data and models healthy. No owner means the system rots within a year, however good it was on day one.

4. Proof - measured savings, not a slide? Ask for results from a real building in sustained operation, ideally comparable to yours, with numbers you can check. A demo and a best-case pilot are not proof; they are marketing.

Four honest yeses is genuine value worth buying. Any no is not a reason to walk away outright - it is the precise question to resolve first. Used steadily, this test protects your client's budget, keeps vendors honest, and - the real payoff - makes you the person in the room who can tell a working twin from a beautiful lie.

There is a trap on the far side of the hype, and it is just as costly: deciding the whole field is smoke and dismissing it. That is cynicism, and it loses real money. The buildings that quietly run twenty or thirty percent cheaper, that catch a failing chiller a fortnight before it dies, that plan a retrofit on measured evidence instead of a hunch - those are not fantasies, they are the payoff for buyers who resisted both the hype and the cynicism. The mature stance is discernment: assume every claim is inflated until it is tested, then test it properly and back what survives.

That balance also shapes how you build. Prefer the boring, high-value moves before the glamorous ones: get to trustworthy monitoring, clean the data model, fix the faults it finds, and only then reach for prediction and control. Scope to a single named decision and prove it before scaling to a portfolio. Treat security and privacy as first-class requirements, not afterthoughts, and defer statutory and safety sign-off to qualified professionals - a connected building is a bigger attack surface and a bigger data-protection duty than the brochure admits.

Held this way, scepticism is not negativity - it is the discipline that lets genuine value through while keeping the marketing out. It makes you the person a client trusts precisely because you neither gush nor sneer: you ask the four questions, weigh the evidence, and say buy, probe or pass. That judgement, more than any protocol or platform, is what this whole course has been quietly building toward.