Before a city digs up a junction, it can now try the change on a copy of itself. Not a drawing on a screen, not a spreadsheet of guesses, but a working model fed by traffic counts, weather feeds, building heights, bus timetables and utility maps. That copy is what people mean by a digital twin. Manufacturers and aerospace engineers have used the technique for decades; cities are the newer, messier frontier.

What a Digital Twin Actually Is

Strip away the marketing and a city digital twin has three parts.

First, a model of the physical place — buildings, streets, pipes, trees, terrain. Second, a data layer that keeps that model current: sensor readings, ticketing records, service requests, satellite imagery, utility logs. Third, a feedback loop. Results from the real city go back into the model, which changes how it behaves the next time you ask it a question.

That third part is what separates a twin from a 3D flythrough. A detailed visual model of a neighbourhood looks impressive and answers nothing. A twin lets you ask: if we close this lane to cars and add a bus lane, what happens to journey times on the surrounding streets at 8am on a wet Monday? Then it gives you an answer you can argue with.

A twin is also not quite the same as a simulation. Simulations run scenarios in isolation. A twin stays connected to something real, so it drifts as the real world drifts — and someone has to notice and correct it.

What Goes Into One

Most city twins are assembled from layers that already exist somewhere in the organisation, which is both the good news and the hard part. Typical ingredients:

• Built form: 3D building models, heights, footprints, land use, planning zones.
• Movement: traffic counts, transit schedules and ridership, cycling and pedestrian data.
• Networks: water, sewer, power, gas, telecoms, street lighting — often held by different agencies.
• Environment: temperature, rainfall, air quality, flood extents, tree canopy.
• Services and demand: waste collection routes, school catchments, service requests, maintenance history.

None of this is glamorous. Much of the effort goes into matching identifiers so that the building in the planning system is the same building in the utility records.

What Cities Use Them For

The strongest uses are the ones where a decision is expensive to reverse. A few come up again and again:

• Testing road layouts, signal timings and bus priority before construction starts.
• Modelling flood scenarios: where water pools, which routes stay open, which basements are exposed.
• Siting new housing, schools or clinics, and checking the transport and utility load they create.
• Planning energy demand across a district, including where rooftop solar or heat networks make sense.
• Coordinating street works so three crews do not open the same road in the same month.
• Running emergency exercises, such as a station evacuation or a prolonged power cut.

Cities such as Singapore, Helsinki and Rotterdam have built well-known versions of these models, and the pattern is similar everywhere: start narrow, prove the value on one decision, then widen.

What They Can Predict — and What They Cannot

A good twin is genuinely useful for questions that are spatial, measurable and repeatable. It handles “what if we move this” well. It is much weaker on “what will people think” and “what will this cost in ten years”.

Where the model breaks down

Models are only as honest as their assumptions. A traffic model calibrated on yesterday’s commuting patterns will quietly mislead you about a city where three days a week in the office has become normal. A flood model run at coarse resolution will miss the dip in one particular street. And a twin built around a single department’s data will be blind to everything that department does not measure — often the informal, unrecorded life of a place: the market stalls, the school-run parking, the shortcut through the estate.

The parts nobody budgets for

Building the model is the visible cost. Keeping it alive is the one that catches people out: data feeds to maintain, staff who understand what the outputs mean, software licences, and a plan for what happens when the original supplier moves on. A twin that is accurate on the day it launches and stale eighteen months later is worse than no twin, because people still trust it.

How to Tell a Useful Twin from a Demo

Ask three questions of any pitch:

1. Which decision will this change in the next twelve months, and who makes that decision?
2. Where does each data feed come from, who owns it, and what happens if it stops?
3. How will we know when the model is wrong?

If the answers are vague, you are looking at a visualisation with a bigger price tag.

Where to Start in Your Own City

Pick one recurring, expensive question — flooding, bus reliability, the approval of a large development — and build the smallest model that answers it. Use data you already hold. Publish the assumptions alongside the results so residents and councillors can challenge them. Then, before you scale up, write down who maintains it and how often it gets updated.

A digital twin is a tool, not a strategy. It rewards cities that already know what they are trying to decide, and it flatters cities that do not. Start with the question, not the model.

Photo: ThisIsEngineering / Pexels