Complexity, Feasibility, and Validation in Digital Twin and Spatial Simulation Projects

This resource is based on the presentation Assessing Feasibility and Validation in Complex Digital Twin and Spatial Simulation Projects by Beatrix Howe (NUMENA), developed for the ARTEMIS Summer School 2026 in Hof, Germany. It expands on the concepts presented there and uses examples from the ARTEMIS project to illustrate practical approaches to managing complexity, assessing feasibility, and defining validation in digital heritage projects. 

Introduction

Complexity is an inherent part of digital twin and spatial simulation projects. While these projects are often driven by clear research questions and innovative ideas, they rarely encounter difficulties because of the ideas themselves. Instead, challenges arise when the complexity that develops during implementation is underestimated. As projects progress, new stakeholders become involved, assumptions change, project scope evolves, and technical dependencies increase, making it more difficult to maintain the original project objectives.

This resource explores how complexity emerges in digital twin and spatial simulation projects and why recognising it early is essential for assessing feasibility and defining meaningful validation. Rather than viewing complexity as something that can be eliminated, it presents it as a characteristic that must be identified, understood, and managed throughout the project lifecycle.

Drawing on two case studies from the ARTEMIS project, the Pistoia Pulpit and Mértola Castle pilots, this resource examines where complexity can hide, how it affects project development, and how an idea-first approach to validation helps maintain focus on the original purpose of a project.

Learning Objectives

After completing this resource, learners will be able to:

• explain why complexity is one of the primary challenges in digital twin and spatial simulation projects;
• identify common sources of complexity, including stakeholder networks, data flows, simulation layers, and validation criteria;
• distinguish between technical completion and meaningful project validation;
• analyse how complexity affects project feasibility, budgeting, and scope;
• apply an idea-first approach to planning and validating digital heritage projects;
• reflect on how these principles can be incorporated into their own research or professional practice.

Target Audience

This resource is intended for researchers, heritage professionals, software developers, digital humanists, museum practitioners, archaeologists, and postgraduate students working with digital twins, spatial simulation, or other complex digital heritage infrastructures. It is particularly relevant for participants involved in interdisciplinary projects that combine cultural heritage research with digital technologies.

Although examples are drawn from the cultural heritage domain, many of the concepts discussed are equally applicable to complex collaborative projects in other research and development contexts.

Intended Impact

After completing this resource, learners should be able to recognise complexity before it becomes a project risk. Rather than viewing complexity as an obstacle to eliminate, they will learn to identify where it exists, understand how it affects project development, and develop strategies for managing it throughout the project lifecycle.

The resource also encourages learners to place human-centred validation at the core of project planning. Instead of focusing exclusively on technical deliverables, participants will learn to define success in terms of the original research question and the needs of the intended users.

Requirements

No advanced technical knowledge is required.

Learners should have a basic understanding of digital heritage projects or an interest in digital twins, spatial simulation, or interdisciplinary research. Familiarity with concepts such as digital documentation, cultural heritage data, or virtual environments may be helpful but is not essential.

Suggested Learning Path

For learners who are new to complexity management in digital heritage projects, it is recommended to first watch the video resource Strategic Validation in Complex Spatial Simulation Projects by Beatrix Howe (NUMENA). The video introduces the challenges of managing complexity, feasibility, and validation in spatial simulation projects, while the present text resource expands on these concepts through practical strategies and case studies from the ARTEMIS project.

Complexity in Digital Twin and Spatial Simulation Projects

Digital twin and spatial simulation projects are inherently complex because they bring together different forms of knowledge, technologies, and expertise. They require collaboration across disciplines and institutions while integrating diverse datasets, interpretative models, and research objectives.

Complexity is not necessarily a problem; it is often the result of addressing ambitious research questions. The challenge lies in recognising and managing it early. Projects rarely fail because of weak ideas, but because the complexity of implementation is underestimated until it begins to affect schedules, budgets, and decision-making.

Three recurring risks characterise many complex digital heritage projects.

The first is losing sight of the original idea. As implementation progresses, technical challenges, data management, and infrastructure can gradually replace the original research question as the project’s primary focus. When assumptions change, teams may adapt their plans without considering whether these changes still support the project’s initial objective.

The second risk is scope creep. As new requirements, datasets, or simulation components emerge, the project may gradually expand beyond its original scope. Without careful prioritisation, this can make planning more difficult and divert resources away from the core objectives.

The third risk concerns budget and resources. Every additional stakeholder, dataset, or technical dependency requires time and expertise. If these activities are not considered during project planning, their costs often become visible only during implementation, leading to delays and resource constraints.

These risks are closely connected. Expanding scope increases resource demands, while growing complexity can shift attention away from the original purpose of the project. Rather than trying to eliminate complexity, successful projects continually relate technical decisions back to the original idea, using it as a guide throughout planning, implementation, and validation.

Where Does Complexity Hide?

Complexity is not always immediately visible. In many digital twin and spatial simulation projects, it develops gradually as different technologies, datasets, and stakeholders become interconnected. Rather than existing in one clearly identifiable location, complexity often emerges across several dimensions of a project simultaneously. Recognising these dimensions is an important first step towards managing them effectively.

Four areas are particularly likely to become sources of complexity:

• the chain of people and data,
• the layers of simulation,
• expanding research directions, and
• unclear validation criteria.

The following ARTEMIS case studies illustrate how these different forms of complexity emerge in practice.

Projects in Practice: ARTEMIS

The ARTEMIS project provides two useful examples of how complexity manifests itself in digital heritage projects. Although both pilots involve digital twins and spatial simulation, the nature of their complexity differs considerably.

The Pistoia Pulpit pilot demonstrates how complexity develops through the chain of people and data involved in a project. In contrast, the Mértola Castle pilot shows how complexity accumulates through multiple interconnected layers of simulation. Together, they illustrate that successful project development depends not only on technology but also on communication, planning, and clearly defined objectives.

Pilot 15 – Pistoia Pulpit

The Pistioa Pulpit in the Pieve di Sant’Andrea in Pistoia, completed by Giovanni Pisano in 1301, is considered one of the major works of Italian sculpture around 1300. It is closely related to the famous pulpits created by his father, Nicola Pisano, in the Pisa Baptistery in 1260 and in Siena Cathedral in 1268, the latter of which Giovanni helped to produce.

These works are often described as “proto-Renaissance” because they revive elements of ancient Roman sculpture, especially from Roman sarcophagi, while still remaining rooted in the Gothic style. Compared with Nicola Pisano’s more classical approach, Giovanni developed a more dynamic and expressive style, influenced by northern Gothic art.

Personas

The Pistoia pilot focuses on developing a platform that visualises and compares different types of data relating to Giovanni Pisano’s medieval pulpit. Although the concept appears relatively straightforward, its implementation requires contributions from many different people. These include those responsible for commissioning, installing, and maintaining sensors, specialists analysing the collected data, software developers building the platform, project coordinators, and ultimately the users who interact with the final application. Each participant contributes specialised knowledge while working on only one part of the overall system.

The Data Flow

For the platform to function successfully, information must flow through the entire project: from physical sensors at the heritage site to the digital interface presented to the end user. Every stage depends on the successful completion of the previous one. If information is lost or assumptions remain undocumented at any point in this chain, problems may only become apparent much later during implementation, when correcting them becomes significantly more difficult.

Broken Chain

In practice, the chain of information is rarely as seamless as project plans suggest. Different groups often work independently and may have only limited knowledge of activities taking place elsewhere in the project. As a result, assumptions are not always communicated or verified. The absence of information frequently becomes visible only when developers need to integrate sensor data into the platform and discover that essential details were never documented or shared. At that stage, resolving missing information can delay development and increase project complexity considerably.

No Answers

In complex projects, questions of this kind often emerge when responsibilities and data flows have not been clearly documented or communicated:

• Is the data live or historical?
• What does the data actually look like?
• Which types of sensors are installed?
• How many sensors are there?
• Where are they located?
• Who processes the data?
• Who is responsible for providing the data?

None of these questions is technically complex. However, if there is no clearly defined person or organisation able to answer them, they become significant obstacles to implementation. The challenge is therefore not simply collecting data but establishing a transparent chain of responsibility that allows information to move reliably throughout the project.

No Real Chain

The questions above reveal a more fundamental issue: in some projects, the chain of people and data does not actually exist as a coherent workflow. Rather than forming a connected sequence of responsibilities, information is distributed across individuals, institutions, and systems that may have little direct contact with one another. As a result, assumptions are made independently, communication gaps emerge, and critical knowledge remains isolated within individual teams.

This fragmentation makes it difficult to trace how data moves through the project or who is responsible for each stage of the process. Instead of a continuous chain, the project consists of disconnected links that only become visible when implementation begins. Mapping actors, responsibilities, and data flows early in the project can therefore help transform a fragmented network into a coordinated workflow, reducing uncertainty and improving both feasibility and collaboration.

Pilot 27 – Mértola Castle

The Castle of Mértola (Castelo de Mértola) is a medieval fortress located on a hill above the town of Mértola in southern Portugal. Its strategic position near important river and land routes made the site significant from antiquity onward, with Phoenician, Roman, Visigothic, and Islamic influences shaping its history. During the Islamic period, Mértola (then known as Martula) became an important fortified settlement. The castle and its walls were strengthened in the 12th century. In 1238, the town was conquered by King Sancho II during the Christian Reconquest and later became a seat of the Military Order of Santiago. The imposing keep tower dates from this period. Although the castle lost its military importance over time, it remains one of the key landmarks of Mértola. Today, it is open to the public and forms part of a museum complex that presents the town’s rich Roman, Islamic, and Christian heritage.

Layers of Simulation

Unlike the Pistoia pilot, where complexity arises primarily through the chain of people and data, the complexity of the Mértola Castle pilot lies within the simulation itself. Creating an immersive environment requires much more than producing a three-dimensional model of the site. Instead, the simulation is built from multiple interconnected layers, each representing a different aspect of the historical environment.

Every layer introduces new assumptions and interpretations. Some are based on measurable evidence, while others rely on archaeological knowledge, historical sources, or informed hypotheses. Importantly, these layers do not exist independently. Each one builds upon those beneath it, meaning that decisions made at an early stage influence all subsequent stages of the simulation. As more layers are added, uncertainty accumulates and the relationships between different components become increasingly complex.

The following examples illustrate how these layers contribute to the overall simulation and why managing their interdependencies is essential for creating a meaningful and reliable research environment. As additional layers are introduced, uncertainty accumulates alongside complexity. The objective is therefore not necessarily to eliminate uncertainty, but to understand, document, and communicate the assumptions on which the simulation is based.

Terrain

The simulation begins with the terrain. Although modelling the landscape may initially appear straightforward, even small differences in elevation can influence archaeological interpretations. Accurate terrain modelling therefore forms the basis for all subsequent simulation layers.

Water

The surrounding rivers have shaped the landscape over centuries. Reconstructing historical environmental conditions therefore requires consideration of long-term geographical change rather than simply modelling the present-day landscape.

Vegetation

Vegetation introduces another level of interpretation. Researchers must consider which plants existed during a particular historical period, how densely the landscape was covered, and even which season is being represented. These decisions influence visibility, movement, and potentially the outcome of military engagements.

Castle

The reconstruction of the castle itself requires further interpretation. Architectural evidence must be combined with historical knowledge to determine how the structure may have appeared during the selected period and how its design influenced the events being simulated.

Battle

The simulation must also reconstruct the battle itself, including the participants, strategies, and sequence of events. Each of these decisions builds upon historical evidence while inevitably involving interpretation.

Arsenal

Weapons, armour, and military equipment constitute another simulation layer. These elements influence how participants interact with the environment and therefore contribute directly to archaeological interpretation.

Time

Historical reconstruction also requires consideration of different points in time. The original appearance of the castle, the selected historical period, and its present condition all represent different realities. Of these, only the present-day site can be observed directly; every earlier reconstruction relies on interpretation supported by available evidence.

Knowledge Base and AI Hyperlink Knowledge System

Underlying the simulation is a knowledge base that connects archaeological evidence, historical documentation, and digital models. Building upon this foundation, an AI-supported hyperlink system assists users in discovering relationships between different elements of the simulation and relevant documentary sources. These technologies make large bodies of information more accessible, but they also introduce additional layers of dependency and interpretation.

Each additional simulation layer increases the complexity of the project because it depends upon the assumptions made in every preceding layer. As a result, the central question is no longer simply whether the simulation is technically accurate, but rather what accuracy actually means within the context of the research question being investigated.

Image layers

Terrain (1 of 10)

Validation

As the previous case studies demonstrate, complexity can emerge in many different forms. This raises an important question: How do we know when a complex project is successful? In digital twin and spatial simulation projects, validation extends beyond technical functionality. A system may meet its technical specifications while still failing to fulfil the purpose for which it was developed. Validation therefore needs to address both the performance of the system and its usefulness in the context of the intended research or application.

Technical Completion

Technical completion describes whether a project fulfils its defined technical requirements. For digital twins and spatial simulations, this involves reliable execution, correct data processing, and outputs that conform to the specified criteria. These aspects can be assessed through systematic testing, debugging, and comparison with expected results.

This assessment establishes whether the system operates correctly and provides a foundation for further evaluation. However, successful technical implementation does not by itself demonstrate that the simulation is useful or that it adequately addresses the underlying research objective. Technical completion should therefore be understood as a prerequisite for broader project success rather than as its sole criterion.

Human Validation

Human validation considers whether the project achieves its original objective from the perspective of its intended users. Rather than asking whether the technology works, it asks whether the project creates understanding and enables new forms of research.

Useful questions include:

• Does the project increase understanding?
• Can users investigate or test their hypotheses?
• Who is the person able to say: “Yes, this is done”?

These questions shift the focus from technical performance towards research impact and user experience. Ultimately, the success of a project depends not only on what it can do, but also on what it enables its users to achieve.

An Idea-First Approach to Validation

When projects become increasingly complex, validation can easily become centred on technical details rather than the original research objective. An effective way to avoid this is to begin with the idea that motivated the project in the first place.

Validation questions should therefore be derived from the original goal rather than from the complexity that develops during implementation. Defining these questions early provides a clear point of reference throughout the project and helps ensure that technical decisions continue to support the intended outcome.

A useful starting point is a simple question:

What would tell you that this project has succeeded?

If this question cannot be answered clearly, it becomes difficult to determine whether the project has achieved its objective, regardless of its technical sophistication.

The two ARTEMIS pilots demonstrate how this principle can be applied in practice.

Pistoia Pulpit

For the Pistoia pilot, validation begins with the end user rather than the available technology. Instead of asking which data can be visualised, the project first considers what users need to do within the platform. From this perspective, the required interface, data formats, and workflows can be defined by working backwards from the intended user experience.

In this way, validation becomes directly connected to the original purpose of the project rather than to the complexity of the technical implementation.

Mértola Castle

The same principle applies to the Mértola Castle pilot. Although the simulation consists of many interconnected layers, the original objective remains clear: to enable archaeologists to explore historical battle scenarios and test archaeological hypotheses within an immersive environment.

Validation therefore focuses on whether the simulation supports this activity. If users are able to investigate their research questions in meaningful ways, the project has fulfilled its intended purpose. The technical complexity of the simulation is valuable because it enables this experience.

This approach also underlines the importance of user testing throughout project development. Involving users who were not directly responsible for developing the system helps reveal assumptions that project teams may no longer notice themselves and ensures that the project remains focused on its original objective.

Strategies

The examples presented throughout this resource illustrate that complexity cannot be removed from digital twin and spatial simulation projects. However, it can be anticipated and managed through careful planning and continuous reflection. The following strategies summarise the key principles introduced in this resource:

• Find where your complexity lives. Identify the parts of the project where uncertainty, dependencies, or communication challenges are most likely to emerge.
• Map actors and data flows before you build. Understanding responsibilities and information pathways early helps prevent gaps during implementation.
• Keep returning to the original idea. The initial research question should guide decisions throughout the project lifecycle.
• Think like the end user. Validation should focus on whether the project enables meaningful research and understanding.
• Define validation early. Establish success criteria before project complexity begins to shape them.
• Budget for complexity itself. Activities such as stakeholder coordination, data management, validation, and documentation require time and resources and should be recognised as essential parts of project planning.

Conclusions

Complexity is an inherent characteristic of digital twin and spatial simulation projects. It arises through the interaction of people, data, technologies, and interpretative decisions, and often becomes visible only during implementation. Rather than attempting to eliminate complexity, successful projects recognise where it exists and develop strategies to manage it throughout the project lifecycle.

The ARTEMIS case studies demonstrate that complexity can take different forms. The Pistoia Pulpit pilot highlights the importance of clearly defined actors, responsibilities, and data flows, while the Mértola Castle pilot illustrates how uncertainty accumulates across multiple layers of simulation. Although the challenges differ, both projects show that technical development alone is not sufficient. Maintaining a clear connection to the original research question is essential for making informed decisions and ensuring that increasing complexity continues to support, rather than obscure, the project’s objectives.

Validation therefore extends beyond technical completion. A project should not only function as intended but also enable meaningful research and provide value to its intended users. Defining validation criteria early, working backwards from the needs of the end user, and regularly revisiting the original idea help ensure that development remains focused on the project’s purpose.

Ultimately, managing complexity is not about reducing ambition. It is about making complexity visible, understanding its implications, and treating it as an integral part of project planning, implementation, and evaluation. This approach enables digital twin and spatial simulation projects to remain both technically robust and scientifically meaningful.

Reflection Activity

Think of a digital heritage, digital twin, spatial simulation, or other collaborative research project that you have worked on, or would like to develop.

Reflect on the following questions:

• Where do you think the main sources of complexity would emerge?
• Which people, organisations, or systems would need to exchange information?
• What assumptions might need to be documented and communicated?
• How would you know that the project had been successful from the perspective of its intended users?