1. Surfacing the friction
More than half of the claimed Digital Twins are, in reality, digital models or digital shadows [1]
The term grew so loose it stopped meaning anything precise. Academics and businesses used it conveniently to their needs, creating confusion between terminologies that describe fundamentally different digital systems [1]
We hit the same wall ourselves. We built a tool for designing sustainable fuel plants and could not classify what we had built. It did not match any existing category
To identify why, we examined the different concepts defined in the literature (see Figure 1)
2. Digital Concepts Classification in the Literature
Concept 1: Data Flow Integration
Automatic data flow integration: a change in one twin's state directly leads to a change in the other twin's state.
Manual data flow integration: there is no automated connection between the physical object and the digital model. No automated data exchange is realized.
Based on this distinction, the authors classified digital systems into digital models, digital shadows, and digital twins [2]
![Figure 2: Classification of DT, DS, DM based on data flow integration [2]](https://substackcdn.com/image/fetch/$s_!kWij!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5f421cb8-ff24-43e6-9a0a-4f1b89c119f4_971x440.png "Figure 2: Classification of DT, DS, DM based on data flow integration [2]")
Concept 2: Product Lifecycle
The digital twin concept dates back to 2002, when Grieves introduced the "Mirrored Spaces Model" as a vision for Product Lifecycle Management (PLM) [3]
Yet the author never defined the boundaries of the product lifecycle in its original formulation. The looseness of the original definition contributed to the later misalignment, which the author attempted to tighten in a 2016 follow-up.
Figure 3 illustrates the product lifecycle evolution, which distinguishes two phases:
Phase 1: Pre-physical prototype phase
Phase 2: Post-physical prototype phase
To differentiate between these two phases, in 2016 Grieves and Vickers distinguished between two types of DT: the Digital Twin Prototype (DTP) and the Digital Twin Instance (DTI) [4]
Digital Twin Prototype: a set of blueprints, etc., used to construct or maintain a physical twin (PT).
Digital Twin Instance: the specific instance created after the physical twin has been manufactured and is linked to it throughout its lifecycle.
This iterative process in Phase 1 runs in a virtual environment, where a virtual prototype is cheaper than physical prototyping (see Figure 4)
![Figure 4: Real vs Virtual cost of prototyping [4]](https://substackcdn.com/image/fetch/$s_!pqWH!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F692e5c0d-a086-467a-bc0e-4d28459c17ae_1185x808.png "Figure 4: Real vs Virtual cost of prototyping [4]")
The benefits of a Digital Twin Prototype beyond cost include [4], [5]:
Faster prototyping: simulation allows the investigation of several scenarios
Waste reduction: By moving from Hardware-in-the-Loop (HIL) to Software-in-the-Loop (SIL), we reduce waste since the final product design is validated virtually beforehand
Documentation and communication: Aggregating data scattered across different software, databases, and hard copies simplifies data maintenance. This can be used for versioned documentation and faster communication of output
Concept 3: Technologies and Capabilities
The core value of these digital concepts lies in their ability to simulate, optimize, predict, and monitor. These capabilities depend on the technologies integrated into the system. The choice of technology and the reason behind it is what differentiates one digital system from another
Capabilities: MAPE-K Framework
One established framework is the MAPE-K reference model (Monitor-Analyze-Plan-Execute over shared Knowledge), proposed by Michael and Wortmann [10]
MAPE-K extends IBM's original MAPE framework by adding a Knowledge component. It provides a structured control loop for managing and optimizing digital systems.
Monitor: the system continuously collects data from sensors, actuators, and monitoring tools that capture behavior, resource utilization, and external conditions.
Analyze: Collected data is analyzed to identify patterns, anomalies, and potential issues.
Plan: Based on the analysis, the system formulates a plan for actions, including adjustments, optimizations, or corrective measures.
Execute: The system performs the actions defined in the planning stage, either automatic or semi-automatic.
Knowledge: A repository of historical data, models, policies, and best practices. Over successive iterations, the system improves its self-optimization by learning from past experience [10], [11]
Technology: Digital Factory
Brarda et al. (2026) studied 21 industrial companies and identified a structured technology sequence [12].
IoT and sensors: enable real-time data collection at the Digital Shadow level.
Real-time analytics and AI: enable prediction and optimization at the Digital Twin level.
Extended reality: (VR, AR, MR) enables human interaction and training at the Industrial Metaverse level.
In this ontology, a Digital Model with IoT sensors becomes a Digital Shadow. A Digital Shadow with actuators and AI becomes a Digital Twin. A Digital Twin with immersive interfaces becomes an Industrial Metaverse application. The technology creates the layer.
The technology integrated determines what the model can achieve, and therefore what type of digital system is being built.
Yet two systems with the same technology can have fundamentally different capabilities, which leaves room for divergence in ontologies
3. Evaluation of the Concepts
Concept 1: Data Flow Integration. The tool allows the user to manually design the plant details on the canvas, including procurement, economics, technical details, etc.
Concept 2: Product Lifecycle. The tool allows the user to prototype rapidly before the physical prototype is created
Concept 3: Technologies and Capabilities. The tool allows the user to verify the mass and energy balances of the plant, to run techno-economic assessment, lifecycle assessment, regulation-specific assessments, and financial assessment.
Every assessment creates a versioned report that is logged as an immutable record in the blockchain to maintain an audit trail
The evaluation shows that our tool uses manual data flow (defined in Concept 1) and operates entirely in the pre-physical prototype phase (defined in Concept 2).
Concept 3 is where the gap appears. The existing technology integration frameworks all assume a physical object exists, and do not consider the product lifecycle (Concept 2) as a differentiator.
MAPE-K's "Execute" stage acts on a running system. Brarda's Digital Factory progression assumes IoT sensors on real equipment and operators on a real factory floor.
For this reason, we adopt the formalized ontology of Barbie and Hasselbring [5]: compatible with the three defined concepts, it accounts for Concept 1 (data flow) and Concept 2 (lifecycle), and closes the semantic gap identified above.
We then extend this ontology to fill the gap revealed by Concept 3.
4. Formalized Ontology
In 2024, Barbie and Hasselbring formalized the concept of Digital Twin using the Object-Z notation [5]. This literature traced the history of digital concepts to demonstrate the gap in ontologies. It allowed the authors to propose the following formal definitions:
Digital Model: A snapshot of a mathematical model or computer-aided design used primarily for initial simulations.
Digital Shadow: Monitors the corresponding physical twin in (near) real-time and internally updates an instance of the digital model.
Digital Twin: Operates and monitors the corresponding physical twin in (near) real-time and internally updates an instance of the digital model.
Digital Template: Bundles all information, the digital model, and the embedded software system required to build the physical twin.
Digital Twin Prototype: Contains the physical twin's embedded software system but uses emulators instead of real sensors/actuators. Replaces the physical twin during development and in CI/CD pipelines.
![Figure 5: Relationships between physical twin, digital model, digital template, digital shadow, digital twin and digital twin prototype [5]](https://substackcdn.com/image/fetch/$s_!cQcI!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F60196d42-de2a-4f52-b367-40d4c517558d_1436x1039.png "Figure 5: Relationships between physical twin, digital model, digital template, digital shadow, digital twin and digital twin prototype [5]")
5. Digital Stack: Augmented Digital Template
Most projects fail before final investment decision (FID), before a single unit is built [14].
Digital twin technology will not solve the problem if the physical twin does not exist yet. We are therefore building the digital template required to create it.
Based on the formalized ontology (Chapter 4), a digital template bundles all information, the digital model, and the embedded software system required to build the physical twin
Building on this concept, we add a blockchain-based layer to the digital template, ensuring an immutable record of all claims. Such a record is essential in this pre-FID phase, where periodic reporting to stakeholders is a requirement.
Finally, to close the gap revealed by Concept 3, we propose the Augmented Digital Template: a digital concept that preserves the formal definition of a Digital Template [5] and adds the real-time auditability layer enabled by blockchain (see Figure 6).
The architecture is organized in four layers:
Digital Template Layer: It bundles the plant's digital model, embedded software system, and all information required to build the physical twin. This layer holds the flowsheet and process design logic. Every design iteration produces a new version of this template.
Domain-Specific Tools Layer: Specialized engines that operate on the template. Each tool addresses one dimension of project viability: mass and energy balance verification, TEA, LCA, regulation-specific compliance checks, and financial simulation. Tools read from and write to the template, so a change in one propagates to the others without manual re-entry.
Automated Reporting Layer: Every assessment produces a structured, versioned report. Reports are generated automatically when a tool completes its run, and each report carries the exact template version and input parameters that produced it. This replaces the manual report-writing cycle that slows pre-FID project development.
Tamper-Proof Track Record Layer: Every report is anchored to the Hedera blockchain as an immutable record. An on-chain auditor can verify the full project history independently, without accessing internal systems. This reduces friction for certification, due diligence, and regulatory reporting, and gives investors and partners a verifiable chain of claims rather than a folder of PDFs.
This is how design and analysis cycles shorten, re-designs accelerate, and virtual prototyping removes the need for multiple physical prototypes, significantly reducing cost. Reporting becomes automated, and traceability is guaranteed through a tamper-proof track record.
The Augmented Digital Template reinforces trust in investment-heavy projects, where multiple stakeholders share the risk and where projects most often fail before anything is built.
6. Innovation and Its Application
Application 1: Digital Continuity
The Augmented Digital Template enables a digital thread [5] across the project prototyping phase.
Every design version, equipment selection, and compliance assessment is automatically documented, versioned, and communicated.
Application 2: On-Chain Audit Trail via Blockchain
Every design version is anchored to the Hedera blockchain. An on-chain auditor can verify the full history independently, without accessing internal systems.
This reduces friction for certification, due diligence, and regulatory reporting.
Application 3: Real-Time Regulation Compliance
The template is linked to a regulatory rulebook updated in real time. When a regulation changes, the system detects it and re-evaluates the design automatically.
Example:
Consider a developer designing a sustainable fuel plant in Germany. Throughout the design phase, the plant's compliance is continuously assessed against the regulations in force, and the design is confirmed at every iteration.
Then the rules change: on 23 April 2026, Germany transposed RED III, and the Bundestag approved a new RFNBO trajectory for transport, rising from 0.1% in 2026 to 5% by 2035 and 10% by 2040, with a non-compliance penalty of EUR 14/kg [15].
In a conventional setup, this change would require manual legal analysis, recalculation, and repeated communication rounds to align stakeholders, and every week of delay pushes the project closer to stalling before FID [14].
With the Augmented Digital Template, the design is re-evaluated overnight, and each stakeholder receives an updated compliance report with no manual step.
Subscribe
Thanks for reading. If you are building tools for the energy transition, subscribe to follow this series on what it takes to build software for pre-operational projects in energy markets.
Bibliography
[1] M. Liu, S. Fang, H. Dong, and C. Xu, "Review of digital twin about concepts, technologies, and industrial applications," J. Manuf. Syst., vol. 58, pp. 346-361, 2020.
[2] W. Kritzinger, M. Karner, G. Traar, J. Henjes, and W. Sihn, "Digital twin in manufacturing: A categorical literature review and classification," IFAC-PapersOnLine, vol. 51, no. 11, pp. 1016-1022, 2018.
[3] M. Grieves, "Origins of the digital twin concept," Tech. Rep., 2016. DOI: 10.13140/RG.2.2.26367.61609.
[4] M. Grieves and J. Vickers, "Digital twin: Mitigating unpredictable, undesirable emergent behavior in complex systems," in Transdisciplinary Perspectives on Complex Systems. Springer, 2016, pp. 85-113.
[5] A. Barbie and W. Hasselbring, "From digital twins to digital twin prototypes: Concepts, formalization, and applications," IEEE Access, vol. 12, pp. 75337-75365, 2024.
[10] J. Michael and A. Wortmann, Towards Development Platforms for Digital Twins: A Model-Driven Low-Code Approach. Springer, 2021, pp. 333-341.
[11] D. Lehner, J. Pfeiffer, E.-F. Tinsel, M. M. Strljic, S. Sint, M. Vierhauser, A. Wortmann, and M. Wimmer, "Digital twin platforms: Requirements, capabilities, and future prospects," IEEE Softw., vol. 39, no. 2, pp. 53-61, Mar. 2022.
[12] P. G. Brarda, N. F. Ayala, and G. H. S. Mendes, "Roadmap to Digital Factories in Industry 4.0: Insights from multiple case studies," Int. J. Prod. Econ., vol. 292, 109829, 2026.
[14] Hydrogen Europe, "The Hydrogen Europe Quarterly 10," 2025. https://hydrogeneurope.eu/wp-content/uploads/2025/03/The-Hydrogen-Europe-Quarterly_10_DIGITAL.pdf
[15] "Why RED III implementation matters," Hydrogen Council, May 3, 2026. https://hydrogencouncil.com/en/why-red-iii-implementation-matters/