How Do Cities Co-Design Urban Digital Twins Without Locking Out Residents?

What Co-Designing an Urban Digital Twin Actually Means

A city digital twin is a connected model of a place used to test what might happen before physical changes are made. It may combine maps, building information, transport records, flood models, energy data, and live sensor feeds. Co-designing an urban digital twin means residents, planners, engineers, emergency teams, businesses, and other affected groups jointly define what the model represents, which questions it should answer, and who may use its results. It is not simply building a 3D city and inviting people to comment after the technical choices have been made.

Also worth reading: How Will Cities Automate Zoning Compliance Without Giving Algorithms Final Say? · How Do Cities Actually Implement Municipal Digital Twin Strategies in 2026? · How should cities govern municipal IoT sensor data without creating privacy and security liabilities?

The direct answer is that cities should begin with a bounded public decision, recruit a representative group, establish data rights, and prototype with a model specific enough to test but simple enough to challenge. They should also budget for paid participation, independent interpretation, maintenance, and staff training from the first year. As of September 2026, generative AI can accelerate interface creation, code generation, and scenario drafting, but it does not replace the need to verify outputs or negotiate public priorities. A polished simulation can still encode the assumptions of whoever commissioned it.

Co-design matters because a digital twin distributes influence. A model can make one future appear more rational or inevitable than another, especially when it ranks projects, predicts behavior, or allocates resources. The Frontiers article titled “That’s the dream, right?”: reflections on the co-design of an environmental digital twin by flood risk management professionals illustrates why professional users need a voice in model purpose and interpretation. Research involving OCEANITY also connects digital twins with coastal climate decisions, showing that technical value depends on the quality of collaboration around flooding, adaptation, and competing development needs.

Why Participatory Design Is More Than Public Consultation

Conventional consultation often presents a nearly finished option and asks whether the public supports it. Co-design gives participants influence over the problem definition, data selection, scenarios, interface, and acceptable evidence. If residents can only choose between prebuilt alternatives, the city is using technology to modernize consultation rather than share decision-making power. That distinction affects trust, especially where communities have already experienced mapping, policing, redevelopment, or data practices that did not serve them well.

People contribute knowledge that standard datasets miss, including informal transport routes, recurring flood points, accessibility barriers, care routines, and neighborhood priorities. Frontline planners add another type of expertise: they know which decisions can still be changed, which regulations apply, and where a simulation may be mistaken for an approval. Residents can identify cases that average data conceals, such as a care home whose residents need a different evacuation assumption from a nearby office tower.

Participation should be structured rather than treated as a single workshop. A useful program might include 6 to 10 co-design sessions over 3 to 6 months, monthly working meetings with a technical team, and a final period for reviewing prototypes. At least 30 to 50 participants can be workable for one pilot, but the number is not a substitute for representation; 20 carefully selected users with decision-making power may produce more operational value than a much larger open webinar.

A useful threshold is to test whether meaningful disagreement remains visible. If every model output is described as objectively correct, or if participants are told that their contributions cannot alter the project brief, the process is probably performative. The purpose is not to achieve unanimous agreement but to record contested assumptions and make clear how they affected the final recommendation.

A Practical Co-Design Process for Cities

The first step is to choose one decision that a digital twin could genuinely improve, such as siting a cooling center, comparing drainage upgrades, or testing pedestrian changes around a transit station. Avoid beginning with the entire city, because its data and governance requirements can become excuses for delay. A city should state the decision, deadline, responsible agency, baseline conditions, geographic boundary, and the consequences of producing an uncertain model. This brief should be public before recruitment begins.

The second step is to form a group that includes people affected by the outcome, not only people able to attend daytime meetings. A practical target is 5 to 7 hours of compensated participation per core community member, plus payment for accessibility, translation, childcare, transport, or personal assistance where needed. Participants should receive plain-language model descriptions during recruitment, not only after they have joined. The city can use workshops, interviews, map annotations, walk-arounds, and asynchronous review to combine social depth with schedule flexibility.

The third step is to agree on rules before building the model. These should cover data ownership, commercial reuse, retention periods, public release, model uncertainty, appeal procedures, and the conditions under which a simulated result may inform a budget or policy. The fourth step is a staged prototype: test a spreadsheet or static map first, then an interactive view, and only then connect live data or AI-generated assistance. A 6-month pilot can be informative, while a 12-month program is more realistic when procurement, data-sharing agreements, and independent evaluation are included.

A final review should compare what changed because of co-design with what remained fixed. Cities should report, for example, that 4 of 7 requested scenarios were included, 2 datasets were withheld for privacy reasons, and no scenario received approval for capital spending. Honest reporting of these limits makes the model easier to use. It also gives officials a defensible record when a stakeholder later argues that the digital twin suppressed an alternative future.

Choosing the Right Technical Approach

There is no single best platform for co-designing urban digital twins. A low-code model may be adequate for planning workshops, while a detailed physics-based simulation is needed for drainage or structural analysis. Cities should match technical complexity to the decision, the skill of intended users, and the strength of the underlying data. Buying an enterprise platform does not automatically create a trustworthy digital twin.

AI is most useful for translating natural-language questions, explaining model assumptions, drafting interfaces, and helping users compare scenarios. It is least reliable when used as an undocumented source of urban facts, an autonomous decision-maker, or a substitute for calibrated simulation. A generated response should be linked to the dataset, model version, date, and assumptions that produced it. Where the system cannot provide those details, the answer should be marked as unverified.

The table is not a contest in which one option always wins. A consultant may run the flood engine while a participatory process governs its scenarios, and a static model can be the correct first prototype. Generative concepts can widen discussion, but every building height, travel time, cost, and site constraint must be checked against authoritative records.

Data, Power, and the Limits of Fictional Accuracy

Data access is a central design question. Cities must explain whether contributors are supplying content to a public system, a commercial vendor, or a research dataset, and whether the data can later be used for enforcement or investment decisions. Some information should be aggregated or reduced in precision. For example, precise household vulnerability data may not need to be displayed at individual addresses, but the model may still need sufficient resolution to test service coverage.

A useful data-governance document should name a controller, a technical steward, an independent contact for complaints, and a removal process. It should specify an initial retention period, such as 12 or 24 months, and require review before any extension. Public registries can reduce repeated data requests, while confidentiality rules can protect people from unwanted disclosure. Git-like version control, used in software for recording changes, is also useful for model parameters: decision-makers should be able to identify whether a flood threshold changed on 14 August or a traffic assumption changed after consultation.

Digital models are simplifications. A map can make an uncertain boundary appear exact, and machine-learning predictions can reproduce historical bias even when the code is technically correct. Participants should be shown uncertainty bands, missing data, and sensitivity tests rather than a single confident result. If flood depth changes by 12 centimeters under two plausible rainfall assumptions, that difference should appear beside the scenario.

Independent review is worth the added cost when the model affects safety, housing, policing, or major expenditure. A reviewer can test whether inputs match the source, whether conclusions follow from the assumptions, and whether excluded groups are likely to receive different outcomes. As of September 2026, AI-generated interfaces should also be treated as software components that require security testing, because public-facing city systems are frequent targets for automated abuse.

Costs, Timelines, and Who Should Pay

Costs depend heavily on scope. A facilitated workshop using open tools can cost roughly $10,000 to $50,000, while a 3-month pilot with clean data, multiple stakeholders, and a simple interactive model may range from $100,000 to $500,000. A multi-year platform integrating live sensors, transport systems, flood models, and enterprise software can run into millions of dollars. These are planning ranges rather than universal market prices; local labor rates, data readiness, software licensing, and security requirements can move the total substantially.

A city should separate one-time construction from recurring expenses. Participant compensation is a program cost, not an optional marketing expense, and should be budgeted before the first workshop. Maintenance may consume 15 to 30 percent of a digital product’s initial build budget in a typical year, though the percentage can be higher for live data integrations. The organization should ask who updates datasets, responds to errors, trains staff, and retires the model when its assumptions no longer apply.

Smaller municipalities may gain more from a shared regional service, university partnership, or open-source implementation than from a bespoke contract. A public works department can start with a bounded model and open formats before committing to a proprietary platform. Vendors should be required to export data, model documentation, and test cases; otherwise a city may lose bargaining power when the contract ends.

Funding is easiest to defend when the pilot names a decision and an avoided risk. Instead of claiming that digital twins will transform every department, officials can set targets such as shortening a review cycle from 90 to 60 days, testing at least 3 alternatives, or identifying 2 data gaps before design approval. These targets should measure process quality, not pretend that a model can guarantee a better city.

Common Mistakes That Undermine Co-Design

The most common mistake is beginning with a visually impressive 3D city rather than a public problem. Real-time graphics can attract attention while hiding weak data, expensive maintenance, and little decision value. Another mistake is recruiting a small group of enthusiastic technology users as a substitute for the wider population. A workshop full of professionals, students, and civic-group leaders can still exclude renters, shift workers, disabled residents, young people, or people without stable internet access.

A second error is treating feedback as preference data without recording disagreement. If one group supports a park and another supports housing, the project should show that conflict and seek a decision rule, rather than averaging opinions into a bland output. Planners must also avoid announcing that AI is neutral because it removes human bias. AI can make inconsistent patterns faster, so oversight remains necessary.

The third error is using a digital twin to justify a predetermined project. If procurement documents already identify the preferred site, the process is unlikely to be exploratory. Officials should publish the reason for the preferred option and invite evidence capable of overturning it. This is more demanding than a public presentation, but it makes later implementation more credible.

The fourth mistake is failing to plan for the end. Data must be archived, deleted, or transferred; old scenarios must be retired; and the city must record which version supported each decision. A digital twin without a maintenance owner is a discontinued experiment with an expensive interface. The success of co-design should be judged partly by whether the city changed its process when participants identified a blind spot.

When to Act and How to Judge the Pilot

A city should act now when it has a genuine planning question, a plausible data source, an accountable owner, and enough time to involve affected people before options harden. Waiting is sensible when the main objective is publicity, the required data do not exist, or the decision cannot be changed. A pilot can still explore questions, but it should not be presented as a commitment to build.

Within 6 months, the team should be able to demonstrate a public decision brief, a documented co-design group, at least 2 competing scenarios, traceable data sources, and a method for recording uncertainty. By 12 months, it should have tested the model with intended users and explained how their input altered the analysis. A useful evaluation asks whether participants understood the model, could identify its limits, and believed their contributions had a route into the decision.

Do not use attendance counts as the only measure. A workshop with 60 people may produce less change than 12 paid residents reviewing a draft over 4 weeks. Measure the number of alternatives explored, corrections made to data, unresolved objections documented, and staff able to explain the model without a vendor. Independent evaluation should occur before a permanent platform is purchased.

The strongest approach treats the digital twin as a public instrument rather than a finished picture of reality. Co-design does not guarantee agreement, eliminate bias, or make forecasts certain. It does, however, make assumptions more visible and give affected groups a practical route to contest them. That is a more defensible standard than simply asking whether the technology works.