What is a digital twin: a map, a model, or a mirror?

I have been hearing about the idea of a digital twin for a long time, but I am sorry to say I haven’t yet come across a finished city twin. The only digital twin I have built is part of the software for one of my own projects. It let me develop a relatively large software project with frontier AI models, from requirements to code. The AI made the two-way updates for me — from requirements and design to code, and from code back to requirements and design; so far we have managed to keep the two in sync.

In software, both sides are digital; when I change one, updating the other is relatively easy. In a city, the other side is made of stone, pipe, and people.

Since the first essay in this series, I have been thinking with the same loop: notice, decide, respond. I ended the previous essay with the digital twin: a living copy of the city, a claim to perfect the “notice” step. Now I want to look closely at that claim, keeping in mind this difference between software and a city. A note: the digital twin is not the smart city itself; it is a window I have chosen to understand it. Is building a digital copy of a city the same thing as understanding the city?

One word, three things

When people say “digital twin,” they mean three separate things: a 3D map of the city, a live stream of sensor data, and a simulation that asks, “what if?” All three are valuable, but they are not the same thing.

Even the map is not innocent. Helsinki’s 2019 report passes on an interesting observation: a 3D model that looked finished made some residents think the plan was finished too; the solution was to show the planned buildings in faint colors.¹ The researchers who built the twin of the town of Herrenberg, in Germany, put it plainly: an urban digital twin is not a one-to-one copy of reality; it is a container into which models, data, and simulations are placed.²

According to Michael Grieves, the idea was born in 2003, in a product-lifecycle course at the University of Michigan; he writes that he owes the name “digital twin” to John Vickers of NASA.³ In short, the twin was first thought of for factories and spacecraft. It later carried over to the city.

Model, shadow, twin

Engineering has a classification that separates this tangle.⁴ If the data is updated by hand, it is a digital model. If data flows automatically from the real thing to the copy but does not come back, it is a digital shadow. If there is a two-way link, it is a digital twin.

The Gemini Principles, published by the UK in 2018, press on the same point: what distinguishes a twin from other digital models is its connection to the real thing. It gives two examples: in one the feedback is automatic, through real-time control; in the other it is slow, through the capital-investment process, passing through people’s hands.⁵

My definition

I like these three names because they give the reader a clear language. But in a city, a “two-way link” is most often not a machine changing the city directly.

To my mind, a twin is built to close the loop. It fuses weather stations, accident information, and traffic patterns, simulates a possible event, and sends a timely warning to police in the field and drivers on the road. The feedback comes not from a machine but from informed people. But if the result of the warning is not measured again, the loop has not closed. The warning on the screen is only a promise until someone acts. I think of the care-home junction in the second essay: the screen saw a bottleneck and produced a proposal; had it been a twin, it would also have had to measure what that proposal did to the pedestrians.

I am not alone in this definition. The 2024 report of the U.S. National Academies defines a digital twin as a structure that is continuously updated with data from its real twin, has a predictive capability, and informs value-creating decisions; it says those decisions may be automatic, or made with a human in the loop.⁶

Michael Batty writes that twins are tightly coupled to reality in physical systems, but in social systems this link is far looser, and information transfer is often not even automatic; in city planning, the “human in the loop” is indispensable.⁷ The Gemini Principles, too, note plainly that a twin of the built environment is not a realistic representation of a human.⁵ So the mirror shows the city, not the people in it.

It is people, too, who choose what a twin will look at. A warning is only as good as the future we told it to look for. If we build a water twin only to catch bursts in the main pipe, for example, slow leaks never show up on the screen.

Does it work?

The advocates’ strongest point is right: a twin’s value is trying a change before you make it real. There are examples of this. The researchers who built Herrenberg’s virtual-reality twin report that the tool could bring into the planning process children, teenagers, and residents from migrant backgrounds who are not normally reached — but this is based on a small survey and the participants’ own impressions.² Helsinki’s model opens a solar-energy calculation for nearly a million roof and facade surfaces in the city to everyone.⁸ Dubai lists rainfall simulation among the uses of the twin it launched in July 2026.⁹ In Texas, a research team developed a flood twin that it validated by comparing it against past floods.¹⁰

But to be honest, as far as I could find, no independent study measures how much time or money a city twin saves in real use. The success figures we have are either the companies’ or cities’ own statements, or come from research prototypes.

Time and money matter; but to my mind the real measure is another: did the twin change people’s lives for the better? A safer junction, a neighborhood that prepares earlier for a flood, a young person able to take part in planning for the first time. The UK’s Gemini Principles puts this as its first principle too: a twin must deliver genuine public benefit.⁵ Measuring this is far harder than measuring time and money.

Even so, I think it can work; but on one condition. What will keep the twin in sync with the city is well-defined, implemented, and audited processes. Auditing every change made by every actor in the city, and reflecting it in the twin, is very expensive; so the twin’s scope must be chosen with care. To try to build a twin of everything in the city is a job that will never end. I will come back to the question of what really worked at the end of the series.

İstanbul: a single question

To my mind, the most honest twin is one built around a single question. İstanbul’s disaster-focused digital twin is exactly this: a pilot project designed to simulate what will happen before, during, and after an earthquake. It began in 2024 with a grant from the U.S. Trade and Development Agency.¹¹ In 2025, it won the Council of Europe Development Bank’s award for social cohesion.¹²

The award matters, but by my definition the question is different: does the warning reach the field, and is its result measured? As far as I could find, the results of this twin have not yet been published. But an earthquake changes that test a little: with a rare, destructive event you cannot wait to close the loop on the real catastrophe. So what we need to measure is not what follows the quake, but whether the twin genuinely changed how the city prepares before one comes.

So: a map, a model, or a mirror?

As I finish this essay, two disconnections stay with me.

The first is between the twin and the city. Many actors change the city all the time, sometimes without telling anyone. We can draw in the digital model where a line will run; but if, in the field, it runs somewhere else and no one enters that into the model, the twin keeps showing a city that does not exist. Keeping the twin current is a job in itself. In my software twin, this was relatively easy, because both sides are digital; in a city, processes have to do the same work.

The second is between the twin and the human. Suppose the twin is correct. If the answer it produces isn’t automatic, it gets caught by a person; and people’s priorities and understanding may not match what the twin proposes. What actually happens and what the twin expected drift apart.

These two disconnections are not accidental. In the second essay I argued that a city is the third kind of problem: organized complexity — many interrelated factors, neither a simple machine nor a crowd that averages out. A twin is, in the end, an attempt to read the city from a single panel; and as I said there, to think we can read the whole city from one panel is to mistake the kind of problem it is. So I hold the twin’s promises lightly: a good twin can make the city easier to see and to think about, but it cannot resolve organized complexity, nor fit it onto a control panel.

Only the last step of my test can catch both of these disconnections: measuring the result again. Measuring shows not only whether people acted, but also where the twin was wrong. Sometimes the right one is not the twin but the person in the field. So the human is both the twin’s ceiling and its safeguard: the place where it cannot resolve organized complexity on its own, and the place where it is put right when it errs, are the same — the human in the loop.

To my mind, most of what cities call a “twin” today is a well-made map, or a mirror that shows us the city. For them to be twins, a loop is needed to close these two disconnections; and that is the work of people more than machines.

But one thing is certain: whatever kind it is, the twin’s “notice” step feeds on data. Cameras, sensors, phones, records. That is the next essay’s question: What feeds the twin, and whose data is it?