I. Beyond the 3D Model: The Need for a Truth Layer

When most people hear Digital Twin, they imagine a sleek 3D model of a city—buildings rendered in high detail, animated with real-time data. But that's only the surface.

A true Digital Twin is not a visualization—it is a structured, living representation of reality. As NIST describes in its Internal Report IR 8356, a Digital Twin must integrate data, models, and simulation to mirror real-world systems in a reliable and actionable way. Similarly, the UK's National Digital Twin Programme (NDTP)—whose foundational Gemini Principles were developed by the Centre for Digital Built Britain at the University of Cambridge—emphasizes that national-scale twins depend on trustworthy, interoperable data, not just visuals.

This leads to a fundamental challenge: how do you design a system that is simultaneously high-performance (fast, queryable, scalable) and scientifically meaningful (rich in relationships, context, and semantics)? Trying to solve both in a single layer often leads to compromise.

The solution lies in explicitly separating two concerns:

• The Datastore (Truth Layer): A strictly structured, high-fidelity API that captures what is physically and operationally true. It speaks the language of numbers, coordinates, and physical properties—optimized for performance, strict data validation, and complex spatial queries.
• The Ontological Engine (Knowledge Layer): A flexible, on-demand system that interprets this raw data into higher-level meaning using semantic models. Sitting atop the datastore, it translates records into semantic metamodels, allowing a researcher to ask not just about the efficiency of a single component, but how that component fits into the broader energy ecosystem of a district.

This separation aligns with Semantic Web principles from the World Wide Web Consortium (W3C), where raw data is kept distinct from the logic that gives it meaning. In practice:

The API provides the facts. The ontology provides the meaning.

II. Structuring Reality: The Domain-First Approach

To maintain scientific integrity, the system must reflect reality as closely as possible—not just in data, but in structure. This is where a domain-first approach becomes critical.

Instead of designing around tables or endpoints, you design around real-world energy systems: photovoltaic panels, heat pumps, boilers, meters, and buildings. Each is a domain entity with its own properties and behavior. A solar panel has a tilt angle, orientation, and efficiency curve. A boiler depends on a fuel source, combustion efficiency, and thermal output.

By using a joined inheritance strategy, the database understands that while every component is an "Energy System," different technologies have unique parameters. A building can "know" all its systems, while each system retains its unique technical characteristics. This avoids flattening reality into generic structures that lose meaning.

But energy systems don't exist in isolation—they exist in space.

This is where geospatial intelligence becomes essential. By integrating tools like PostGIS—which follows the Open Geospatial Consortium's Simple Features for SQL specification—the datastore treats location as a first-class citizen. This moves beyond simple addresses into true spatial relationships. Instead of asking:

"What systems are in this building?"

You can ask:

"What is the total solar generation potential of this specific city block?" "Which buildings within 200 meters of this transformer are likely to overload it under peak EV demand?"

This shift—from static records to spatially-aware queries—is what transforms a database into research-grade infrastructure.

III. The Scientific Guardrails: Mappers and DTOs

Once reality is correctly structured, the next challenge is protecting it.

In many systems, the internal database structure is exposed directly to users or external services. This creates a dangerous situation where the "truth" can be unintentionally distorted. In a research context, small inconsistencies at the data layer can propagate into massive errors in simulation results.

To prevent this, we introduce two key patterns:

DTOs (Data Transfer Objects), a concept formally documented by Martin Fowler in Patterns of Enterprise Application Architecture, act as a controlled interface between the outside world and your internal model. Raw database tables are never exposed directly; instead, DTOs ensure that only validated, structured data enters the system, and that researchers always interact with a clean, stable representation—even if the underlying database structure is optimized or changed.

Mappers act as scientific translators. When data comes in—whether from a sensor, a user, or another system—it is automatically converted into a strictly-typed internal model in a consistent and validated way. This eliminates manual inconsistencies, unit mismatches, and structural errors that are common in manual data processing.

Finally, there's the question of evolution. Cities change; systems evolve; schemas must keep up without breaking. This is where database migration tools like FlywayDB come in. By version-controlling the database schema, every change is tracked and every environment is reproducible. Any researcher can recreate the exact same "Ground Truth" environment, ensuring that simulations are consistent and results can be verified. In effect, your database becomes a living, versioned scientific artifact.

IV. Navigation & Discovery: HATEOAS and Specialized Controllers

A powerful system is useless if it's hard to navigate.

Traditional APIs require users to know exactly which endpoints to call. This creates friction—especially for researchers more focused on questions than infrastructure, and for the Ontological Engine that must "browse" the data autonomously.

This is where HATEOAS (Hypermedia as the Engine of Application State) comes in, a constraint of REST architecture coined by Roy Fielding in his 2000 doctoral dissertation. With HATEOAS, the API becomes self-discoverable and self-documenting. A user can retrieve a building, follow links to its energy systems, and navigate to related meters or grid nodes—without needing hardcoded paths. The API effectively guides both human researchers and automated engines through the data.

Equally important is the use of specialized controllers rather than a single generic endpoint for all equipment. Dedicated gateways are created for each system type—PV panels, boilers, EV chargers, and so on—because each system has unique physics and constraints.

A solar panel's tilt angle and a boiler's combustion efficiency are not interchangeable concepts. If you force everything into a generic structure, you dilute meaning and degrade validation. Specialized controllers preserve this integrity, ensuring that data entry is precise, models remain faithful to reality, and downstream analysis is reliable.

V. Feeding the Ontological Engine

With a strong foundation in place, the system is ready to do what it was designed for: powering intelligent, semantic Digital Twins.

The API acts as the primary data pipeline into the Knowledge Layer—the Ontological Engine. This engine uses structured data from the API to build on-demand metamodels: not static representations, but dynamic interpretations tailored to specific questions.

• A city planner might generate a model focused on zoning and energy demand.
• A utility operator might focus on transformer loading and EV charging behavior.
• A researcher might explore carbon emissions under different policy scenarios.

This approach aligns with domain standards like the Brick Schema (brickschema.org), maintained by the Brick Consortium, which provides a unified ontology-based metadata standard for representing building assets, subsystems, and the relationships between them. Brick's foundation on W3C's RDF and OWL standards ensures consistent, machine-readable representations that can interoperate across tools and organizations.

By separating concerns between the API and the ontology, you achieve both performance and scalability at the data layer, and flexibility and expressiveness at the knowledge layer.

VI. From Montréal to the World: A Scalable Foundation

What makes this approach powerful is not just its precision—but its scalability.

Once you establish a consistent structure for representing urban energy systems, you can begin to compare cities across climates, policy regimes, and grid configurations:

• How does EV adoption impact grid stability in Montréal versus New York?
• What zoning strategies lead to better energy efficiency outcomes?
• Which districts are most resilient under climate stress scenarios?

Because the underlying data is structured, validated, and interoperable, these comparisons become not just possible—but meaningful.

Conclusion: Architecture as Scientific Infrastructure

At its core, this is not just a software problem—it is a scientific one.

Urban energy systems are complex, interconnected, and constantly evolving. If the underlying data is inconsistent, incomplete, or poorly structured, no amount of modelling can fix it. This is why architecture matters.

By treating your datastore as a "Truth Layer"—strictly typed, spatially aware, version-controlled, and protected by DTOs and Mappers—you ensure that every simulation, every forecast, and every policy decision is grounded in reliable data. And by connecting that Truth Layer to a semantic Ontological Engine, you create the infrastructure needed to do what the field ultimately demands:

Not just to model cities—but to understand them, compare them, and design better ones.

References

• NIST IR 8356 — Security and Trust Considerations for Digital Twin Technology — nvlpubs.nist.gov
• National Digital Twin Programme (NDTP) — ndtp.co.uk
• Gemini Principles — Centre for Digital Built Britain / University of Cambridge — cdbb.cam.ac.uk
• Martin Fowler — Patterns of Enterprise Application Architecture — martinfowler.com
• Roy Fielding — Architectural Styles and the Design of Network-based Software Architectures (2000 Dissertation) — ics.uci.edu
• Brick Schema — brickschema.org
• Open Geospatial Consortium — ogc.org
• W3C Semantic Web / RDF — w3.org