A few months ago I sat in on a vendor demo for a major institutional client. The pitch was for a “digital twin” of a downtown campus. The product looked beautiful. The walkthrough was photoreal. The interactive overlays were responsive. After about fifteen minutes I asked a question I ask often: which sensor in the building generated the temperature value displayed on the executive dashboard? The presenter paused, looked at his colleague, then said the value was hardcoded for the demo.
The asset had real sensors. The demo wasn’t reading them. What was being sold as a digital twin was a 3D render with a fictional data overlay.
That moment is the reason this essay exists. In 2026, “digital twin” has become a category large enough that the term communicates nothing on its own. The buyer who can’t distinguish between three quite different things wearing the same label is going to spend several million dollars on the wrong one. I want to fix that here.
Three things called “digital twin” in CRE marketing this year.
The first is a static 3D model of the building, often derived from the architect’s BIM. It looks like the building. It does not know what the building is doing right now. Some vendors call this a digital twin. By any rigorous definition, it isn’t one.
The second is what I’d call BIM-plus-telemetry. A 3D model with a live data feed glued onto it. The temperature shown on screen is the temperature being read by the sensor. The occupancy heatmap is real. The energy use is real. This is closer to a twin and it’s what most credible CRE vendors are selling in 2026.
The third is a cognitive twin. It does what BIM-plus-telemetry does, and then does three things that one doesn’t. It simulates the asset forward in time. It reasons across data from multiple subsystems and presents results in the right stakeholder vocabulary. It updates the physical asset in response to what it learns — closing valves, adjusting setpoints, dispatching agents.
These three things are not interchangeable. The 3D model can be built in a quarter. BIM-plus-telemetry takes a year of integration. A cognitive twin is a multi-year research-and-engineering effort that compounds across deployments. The value to the asset owner is also not interchangeable — by a factor of about ten.
The original definition.
The phrase “digital twin” came out of manufacturing. Michael Grieves and John Vickers (2017), in their definitional paper, made the requirement explicit: a digital twin is a bidirectional, live-coupled model that both reflects and influences the physical asset. The “bidirectional” part is the requirement most CRE vendors quietly skip. If the model only reads from the asset, it’s a dashboard. If the model both reads from and writes to the asset, it begins to qualify as a twin.
ISO 23247 (2021), the manufacturing-twin framework, formalized the architecture into four planes: the observable physical entity, the data collection and device control, the digital twin core, and the user. CRE has not adopted ISO 23247 as written. It would benefit from doing so.
The academic literature has since refined the category. Hartmann and Trappey curated Advanced Engineering Informatics‘ 2020 special issue on cognitive digital twins, defining the cognitive layer as the addition of perception, learning, reasoning, and decision-making to a base bidirectional twin. The cognitive twin doesn’t just mirror the asset. It infers from data the asset can’t articulate on its own.
This is not a marketing distinction. It’s an architectural one with measurable consequences for what the system can do for the owner.
What “cognitive” added.
Three things, specifically.
First, predictive intelligence. A cognitive twin maintains forward simulations of the asset under varying conditions — weather, occupancy, market — and presents the simulated trajectories alongside the current state. A facility manager can see not only that the chiller is running at 78 percent, but that under the predicted weather pattern over the next eighteen hours it should be ramped to 92 percent now to avoid an afternoon overshoot.
Second, cross-system reasoning. Most building data lives in silos: BMS, EMS, access control, occupancy sensing, PMS, the work-order system, the guest-engagement app. A cognitive twin ingests across all of them and reasons across boundaries. When an unscheduled meeting is booked in a conference room, the twin pre-conditions the room, informs catering, and re-routes elevator dispatch — without a human stitching those events together by hand.
Third, multi-stakeholder interfaces. The same underlying model presents itself differently to the operator, the owner, and the tenant. The operator sees alarms in spatial context. The owner sees NOI attribution and ESG telemetry. The tenant sees a wayfinding interface and an amenity calendar. The twin doesn’t fragment into three products. It’s one model with three faces.
The cost of cognitive is non-trivial. It requires a real-time simulation core, multi-modal reasoning over heterogeneous data, and a presentation layer that can render at game-engine fidelity for the multi-stakeholder interface. The economic case for cognitive depends on whether the asset’s operating margin and exit value are sensitive to the things cognition makes possible. For most institutional CRE, they now are.
The reference architecture.
Strip away the marketing and the architecture of a credible cognitive twin has five planes.
The spatial mesh. A geometrically accurate 3D representation of the asset, typically derived from BIM, point-cloud capture, or generative reconstruction. This is the layer most existing vendors stop at.
The telemetry ingestion layer. Streaming data from sensors, BMS, EMS, access control, PMS, work-order systems, and tenant-engagement platforms. The protocols at this layer matter — we’ll come back to them.
The simulation core. Physics-aware models that can roll the asset forward in time under varying conditions. For thermal systems, this is usually a CFD-derived surrogate model. For occupancy and engagement, it’s agent-based simulation. For energy, it’s a hybrid.
The predictive layer. Machine-learning models trained on the asset’s own telemetry, plus transfer learning from comparable assets in the portfolio. The predictive layer is what lets the twin anticipate rather than only describe.
The presentation layer. Photoreal rendering, multi-stakeholder UI, and the API surface that lets external systems (the BMS, the work-order system, the tenant app) act on what the twin recommends.
Any vendor pitch that doesn’t credibly show all five planes is selling something less than a cognitive twin. Most ask the customer to take three of the five on faith.
Why Unreal Engine matters technically.
The presentation layer is where most academic CRE-twin projects have historically run aground. Custom WebGL renderers are slow. Static Mapbox-style 2.5D maps don’t scale. The visual fidelity gap between an architect’s rendering and a real-time twin has been a permanent embarrassment.
Unreal Engine closed that gap. Three technical features matter.
Lumen is the global illumination solution that makes a real-time render look photoreal. The light bouncing off the marble lobby floor is computed at sixty frames per second; the result is indistinguishable from a pre-rendered marketing image. For an institutional owner who has historically used pre-rendered marketing imagery as the bar for visual quality, real-time Lumen is the inflection point.
Nanite is the micro-polygon geometry system that lets the engine render essentially unlimited detail without the artist having to optimize meshes. A point-cloud capture of a 1980s lobby with all its imperfect angles renders natively. The compromises that BIM-derived twins made in the 2010s — simplifying geometry to make it tractable — are no longer required.
Multi-user replication is the engine’s networking layer. It was built to let dozens of game players occupy the same virtual world. Repurposed for CRE, it lets an owner, an operator, and an LP walk the same instance of the twin simultaneously, from different cities. The model is one. The viewers are many.
None of this is a marketing claim. It’s the engine on which modern film virtual production runs. CRE inherits the work the entertainment industry has paid for.
The interoperability question.
This is the part of cognitive twins that the marketing usually glosses. A twin that can’t read from the systems the building already has, and write back to them, is not a twin. It’s a graphical separate product.
The protocols matter. BACnet, BACnet/SC for secure variants. Modbus for legacy industrial. MQTT for sensor mesh. Brick Schema and Project Haystack for tagging building data semantically so AI agents can reason across it. MCP for AI-agent tool interoperability, recently moved under Linux Foundation stewardship.
A vendor that hand-waves at “we integrate with all major systems” is hiding something. The honest answer is a published list of protocols and a documented data schema. The dishonest answer is a beautiful diagram.
Five questions to ask any vendor.
If you’re evaluating a “digital twin” product in 2026, here is the diligence checklist I’d hand a CIO.
One. Show me the sensor in the building right now whose live value is rendering on the executive dashboard. If they can’t, you have a 3D model. If they can but the value is rendered only — not used by the system to do anything — you have BIM-plus-telemetry.
Two. What happens when the twin recommends an action? Does it write back to the BMS, the work-order system, the access-control system? Or does it surface a human-readable recommendation that a human has to retype? A twin that doesn’t write back is a dashboard.
Three. What protocols does the platform speak natively, on the day of installation, without custom integration? If the answer doesn’t include BACnet/SC, MQTT, Brick or Haystack, and a credible REST API, the integration cost is going to be the dominant line item.
Four. Whose data is it? If the twin lives on a vendor cloud and the owner can’t extract the raw telemetry on demand, in standard formats, the owner has rented a UI on top of their own asset’s data. That’s a structural lock-in problem that compounds for fifteen years.
Five. What’s the research provenance? “We hired a Stanford PhD” is not provenance. A published research thread, citable lab, and named lead investigator is provenance. The cognitive twin field has a real academic literature; the credible vendors connect to it.
Most vendors will fail on at least two of these five. That’s fine — it tells you where they actually are in the maturity curve.
The research frontier.
For the readers thinking about where this goes through 2030, the frontier is in three places.
Federated twins. A twin of a portfolio that doesn’t aggregate raw telemetry but reasons across local model outputs. This matters for cross-asset learning without violating tenant or owner data covenants.
Twin-of-twins. Hierarchical twins where district-level twins coordinate building-level twins, which coordinate system-level twins. The architecture pattern that lets a master-planned community of a thousand acres act as a single coordinated asset.
Edge inference. Moving the reasoning closer to the sensor. The latency profile of a twin that reasons at the edge is fundamentally different from one that reasons in the cloud. For predictive control of fast-moving systems — elevator dispatch, event pre-conditioning — the edge is going to be the venue.
None of these are speculative. All are being deployed in adjacent industries today. CRE is roughly five years behind manufacturing and aerospace on twin maturity, which is a tractable distance to close.
The cost of getting the definition wrong.
A wrong twin is an expensive 3D model that doesn’t move the asset’s earning profile. The dollars spent on it show up as a one-time capex line, depreciate over five years, and produce no recurring revenue or measurable opex change. The vendor that sold it pockets the margin. The owner returns to the underwrite the asset already had.
The right twin is infrastructure. It outlives the vendor. It outlives the executive who approved it. It produces telemetry, recurring digital revenue lines, and an audit trail of performance that compounds across hold periods. The data lives on the asset. The asset becomes more valuable because of it.
The difference between the two is mostly a matter of asking five questions in the diligence phase.
What this means for the buyer.
If you’re an institutional sponsor evaluating “digital twin” vendors in 2026, the right disposition is skeptical curiosity. Most pitches you’ll see are 3D models with a data overlay. A few are BIM-plus-telemetry. A handful are cognitive twins. The economic case for cognitive is real, but only if the vendor can actually deliver on the architecture they’re claiming.
The good news: the test is cheap. A two-week diagnostic on a single asset, where the vendor demonstrates real bidirectional integration with the building’s existing systems, will sort the categories. The vendors that can will be proud to show the work. The ones that can’t will tell you the asset is too unique for a quick proof.
The cost of waiting for the market to mature on its own is not zero. Cognitive twins are how institutional CRE captures the trapped value in the offline layer. Owners who instrument now will have five years of compounding data on their portfolios by 2030. Owners who wait will be acquiring that data on a five-year delay, against competitors who already have it.
Sources cited
- Grieves, M., & Vickers, J. (2017). “Digital Twin: Mitigating Unpredictable, Undesirable Emergent Behavior in Complex Systems.” In F.-J. Kahlen, S. Flumerfelt, & A. Alves (Eds.), Transdisciplinary Perspectives on Complex Systems. Springer.
- International Organization for Standardization. (2021). ISO 23247: Automation systems and integration — Digital twin framework for manufacturing. Parts 1–4.
- Hartmann, D., & Trappey, A. (Eds.). (2020). Special Issue on Cognitive Digital Twins. Advanced Engineering Informatics, vol. 47.
- Smith, N. G. (and collaborators). Cognitive Digital Twin research program, Immersive Visualization Center, Qualcomm Institute, University of California, San Diego.
- Bentley Systems. iTwin Platform architecture documentation.
- Autodesk. Tandem digital twin platform documentation.
- ASHRAE. ANSI/ASHRAE Standard 135 (BACnet) and Standard 135-2020 (BACnet/SC).
- OASIS. MQTT v5.0 Specification.
- Brick Schema Consortium. Brick Ontology v1.3. brickschema.org. (Initial work: Balaji, B., et al., UC Berkeley.)
- Project Haystack. Tagging Conventions and Type System. project-haystack.org.
- Connectivity Standards Alliance. Matter v1.2+ Specification. csa-iot.org.
- Anthropic. (2024). Model Context Protocol Specification. modelcontextprotocol.io.
- Epic Games. Unreal Engine 5 documentation: Lumen, Nanite, Multi-User Replication.
Dr. Neil Smith is Research Advisor at Smart City Labs and Director of the Immersive Visualization Center at the UC San Diego Qualcomm Institute. His lab pioneered Cognitive Digital Twin research and has produced peer-reviewed work on twin architectures since 2014. To talk about applying a Cognitive Twin to your portfolio, contact the SCL team.