Author pre-print. Publication accepted for the ACM/IEEE International Conference on Model Driven Engineering Languages and Systems (MODELS’26).
Model-Driven Data Contracts for Digital Twin Services Philipp Zech
Istvan David
[email protected] Department of Computer Science, University of Innsbruck Innsbruck, Austria
[email protected] McMaster Centre for Software Certification, McMaster University Hamilton, Canada
arXiv:2607.28803v1 [cs.SE] 30 Jul 2026
Abstract Digital Twins (DT) integrate data from multiple sources. Models consume data and enable DT services such as simulations, what-if analyses, and ML-driven predictions. To ensure proper DT operation, data-driven services require data to exhibit traits such as reliability and high quality (including, e.g., accuracy, completeness, and timeliness). Yet, there is no systematic way to specify data requirements at the model level, and subsequently enact those specifications at runtime. To address this shortcoming, we propose an approach to contract-based quality management in DTs. We formally define a theory of such contracts, situate them architectually within DTs, and propose a domain-specific language to specify contracts. Our approach enables continuous data quality monitoring, thereby improving the reliability and quality of DT services.
CCS Concepts • Information systems → Data streaming; • Computing methodologies → Data assimilation; Modeling and simulation.
Keywords Data quality, Digital twins, Infonomics, Runtime contracts ACM Reference Format: Philipp Zech and Istvan David . 2026. Model-Driven Data Contracts for Digital Twin Services. In Proceedings of ACM/IEEE International Conference on Model-Driven Engineering Languages and Systems (MODELS ’26). ACM, New York, NY, USA, 7 pages. https://doi.org/XXXXXXX.XXXXXXX
1
Introduction
Digital Twins (DTs) are data-intensive systems that combine models with data from multiple sources to mirror and predict the behavior of physical systems [23, 50] through services such as simulation, what-if analysis, and AI-driven prediction [33, 41]. Such analytical and predictive services depend on reliable, high-quality data that further exhibits key properties, such as accuracy, completeness, and timeliness [33]. Models and simulations are built on assumptions about the data they consume [3, 39, 48].
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. MODELS ’26, Malaga, Spain © 2026 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-XXXX-X/2018/06 https://doi.org/XXXXXXX.XXXXXXX
Yet, due to the lack of supporting mechanisms, languages, and tools, these data quality assumptions are not expressed in an explicit, structured, and formal way that allows for verifying or enforcing data quality [29]. As a result, these assumptions cannot be checked systematically during integration or enforced at runtime. This is not only a technical omission, but also an engineering coordination problem. In DT projects, the stakeholders who understand the assumptions made by a model are often not the stakeholders who produce, transform, and deliver the data. Typically, modeling&simulation experts know the input properties under which model outputs remain valid; while sensor, IoT, edge, and data-platform engineers control the sources, sampling rates, preprocessing steps, and the delivery infrastructure. Therefore, data assumptions are scattered across models, code, and informal documentation, with no shared artifact that states which service requires which data property, who is expected to provide it, and how violations should be detected. Consequently, a DT service may continue to execute on stale, incomplete, or misaligned data, producing outputs that are no longer meaningful for decision-making and compromising the validity of the DT [21, 11], particularly when responsibility for data and models is split across roles [2]. This gap motivates explicit data contracts for DTs that declare the data properties required by models and the guarantees expected from data providers—all that at the boundaries of DT services. Such contracts must be explicitly modeled: they have to capture service-level assumptions and guarantees independently of particular sensor, middleware, or deployment technologies, while remaining precise enough to support design-time compatibility checks and runtime monitoring [26, 45]. In this work, we propose the concept of data contracts for DT services, along with an initial formal framework, model-driven support, and architectural underpinnings. A data contract, in our view, is a lightweight specification of data properties required by a service to ensure its integrity, and the intended quality and validity of the results it produces. By formalizing assumptions about data quality, data contracts render these assumptions and their evaluation amenable to automation. Most importantly, data contracts enable verifying compatibility of components during integration, detecting violations during run-time, and triggering fallback or compensation mechanisms when data quality degrades. Contributions. In this paper, we make the following contributions. • We define the conceptual and formal foundations of data contracts for DT services. • We define an initial DSL for data contracts that lets consumers specify data requirements and sources declare data guarantees. • We provide the architectural foundations of the approach by situating it in notable DT reference architectures. • We outline a research and development map.
Author pre-print. Publication accepted for MODELS’26.
MODELS ’26, October 4–9, 2026, Malaga, Spain
The benefits of our work are twofold: (i) it provides a DSL-based engineering tool that can neatly integrate into existing engineering processes [42], and (ii) it improves DT reliability through the explicit specification and automated checking of data requirements. Running example: Smart Building DT. We use a smart building DT as a running example [57]. This DT integrates multiple data sources and models to support building operation, e.g., simulation models to predict energy consumption from occupancy and weather data. Two common data challenges here (i) incomplete occupancy data, and (ii) delayed weather data. Both impact simulation accuracy and illustrate how data accuracy, consistency, and timeliness directly affect DT performance and decision quality.
2
Background and Related Work
Here, we position our work w.r.t. data quality (Sec. 2.1) and software contracts (Sec. 2.2); and review the related work (Sec. 2.3).
2.1
Data quality
Data quality provides the lens through which our work views the correctness and usefulness of DT services. Rather than treating quality as an intrinsic property of a dataset, the data quality literature defines it from the perspective of consumers and intended use. Seminal works [52, 40, 6] show that data consumers evaluate quality across multiple dimensions beyond accuracy, e.g., completeness, consistency, timeliness, and currency. This consumer-centered view is particularly important for DTs: the same observation may be sufficient for one service but invalid for another. For example, coarse occupancy counts may support space-utilization analysis, but may fail detailed energy-consumption simulation. DT services exacerbate data quality problems by integrating heterogeneous data sources, physical-system telemetry, simulations, and AI components [34]. Ouedraogo et al. [38] identify accuracy, completeness, and consistency as central concerns because deficiencies in these dimensions undermine the trustworthiness of DT outputs. Therefore, data quality is context-dependent rather than absolute: its adequacy depends on the consuming service, the supported decision, and the DT’s autonomy strategy [16]. For example, a temperature reading may suffice for occupancy-level energy modeling but not for predictive maintenance. Assessing quality thus requires relating measurable data properties to the needs of the consuming model and service Existing data quality management techniques address low-level problems through cleansing, interpolation, imputation, etc. [38, 55, 6]. However, these techniques do not determine quality properties required by DT services. Such a decision depends on the consumer service, the model behind it, and the characteristics of the service. Consequently, a data quality requirement in a DT must tie to the consuming service and be made explicit at the boundary where data is consumed. This motivates treating data quality properties as measurable, service-specific contract clauses in our approach.
2.2
Contracts in Software Engineering
Contracts in software engineering provide a mechanism for making boundary assumptions explicit. Design by Contract (DbC) [31] defines software interactions in terms of obligations and benefits: clients must satisfy preconditions, while suppliers must establish
Philipp Zech and Istvan David
postconditions and preserve invariants. Component contract work generalizes this view beyond individual operations by distinguishing syntactic, behavioral, synchronization, and quality-of-service facets of component interaction [10]. In both cases, the aim is an explicit specification of responsibilities at an interface, making violations attributable to the party that failed to meet its obligation. For heterogeneous systems, assume-guarantee contracts are especially relevant. A contract pairs assumptions about the environment with guarantees provided by the component when assumptions hold. Contract theories define satisfaction, compatibility, refinement, and composition mechanisms to enable modular reasoning in which components are integrated or substituted without having to analyze the entire system [46]. In these theories, a contract algebra defines operators for composing contracts across components [8]. This maps naturally to DTs, where the responsibility of data production and model consumption is often split among sensor, IoT, data, simulation, and platform engineers. The consumer side needs to state assumptions about incoming data, while the producer side needs to state guarantees about outgoing data. Contracts also connect the design-time and run-time phases of engineering processes. At design time, contract compatibility can be checked before deployment, for example by verifying that the guarantees of a source imply the assumptions of a consuming service. At runtime, monitors can observe traces or streams and detect violations of specified properties [28]. Contract-based runtime verification has been applied to cyber-physical to monitor whether implementations satisfy formally specified assumptions and guarantees during operation [37]. Our work transfers this idea to the data boundary of DT services. A data contract specifies assumptions over input data properties and guarantees over output properties; when assumptions hold, the DT service is expected to deliver outputs with the promised qualities. Thus, data contracts complement existing contract theories by giving data-quality properties first-class status in the contract, and they motivate a model-driven notation from which design-time checks and runtime monitors can be generated.
2.3
Related work
Closest to our work are approaches connecting contract models to executable monitors, such as timing contracts for IEC 61499 [49] and formal assume-guarantee contracts in CPS during operation [37]. While these techniques address timing and behavioral properties of components and controllers, they do not address data concerns in DT services as first-class assume-guarantee structures. Other work formalizes DT artifacts using the Asset Administration Shell, OPC UA, RDF, and SHACL for machine-checkable structural constraints [4, 44, 5]. These works show that DT artifacts can be checked against explicit constraints, but do not integrate behavioral assumptions and guarantees, nor turn such specifications into an end-to-end contract mechanism. Finally, some work embeds formal verification and runtime monitoring into DTs directly by linking design models to operational data [43], synthesizing DT models from contracts [47], checking DTs against system-level timed automata contracts [35], and supervising live executions through stream monitoring and watchdogs [9, 20]. The focus, however, remains on model correctness and temporal property satisfaction rather than data contracts for DT services.
Model-Driven Data Contracts for Digital Twin Services
3
Model-driven Data Contracts for DTs
There are several reasons that motivate a model-driven approach for data contracts in DTs. First, DTs’ use for informed decision-making typically in critical domains, requires proper formal treatment of DTs’ quality attributes, and the traceability, analysis, and formal checks of contracts to ensure quality data for inference. Second, DTs are complex systems and every aspect that can be formally addressed yields a major benefit [27]. Indeed, DT engineering exhibits some recurring patterns, e.g., how models and services exchange and consume data, that are worth capturing. Third, DTs are similar in how we engineer them, but differ in how we use them. What stays constant across the engineering and usage phases are the models and data. This aligns with the models-and-data perspective on MDE for data-centric systems [14]; thus, it makes sense to model these aspects explicitly, as data contracts connect models with the data on which their services depend. Finally, target platforms for DTs are inherently heterogeneous and—as the DT itself—evolve, thus requiring evolvability and portability of contracts [17, 32]. Given its support for abstraction and complexity management, automation through model transformations, separation of concerns, analysis, and its technology-agnostic nature, MDE is a natural enabler for our contract framework [34, 54]. Our choice is reinforced by the wide adoption of MDE in engineering DTs [56]. Our proposal is uses an application-, domain-, and platformagnostic DSL to specift data contracts for DT services. A DT service is a software component that exposes DT functionality to external applications while hiding the DT’s internal details. Contracts make the service’s assumptions and guarantees explicit without requiring knowledge of its implementation. The DSL keeps these specifications independent of the underlying technology and supports generating contract implementations for different target platforms [53]. Recent advances in LLM-based code generation render the technical implementation of contracts from models a trivial task [22].
3.1
Formal Framework for Data Contracts
To formalize data contracts in a DT concept, we first need some definitions of a DT and its services. Definition 3.1 (Digital Twin). For the purposes of this paper, a Digital Twin 𝑇 = (M𝑇 , S𝑇 ) is an abstract entity comprising a collection of models M𝑇 = {𝑚 1, . . . , 𝑚𝑖 } and a collection of services S𝑇 = {𝑠 1, . . . , 𝑠 𝑗 }. Definition 3.2 (DT Service). For digital twin 𝑇 = (M𝑇 , S𝑇 ), service 𝑠 ∈ S𝑇 exposes functionality based on a collection of models M𝑠 ⊆ M𝑇 through an interface. We define 𝑠 = (M𝑠 , Σ𝑠 ), where 𝑠 , P 𝑠 ) is the service signature, P 𝑠 is a set of input paΣ𝑠 = (P𝑖𝑛 𝑜𝑢𝑡 𝑖𝑛 𝑠 is a set of output parameters. rameters and P𝑜𝑢𝑡 The context in which a model is used is captured by the service— the same model may be exposed through different services, each with a different interface and a different data contract. Parameters define the input and output interface of a service. Let 𝑁 𝑎𝑚𝑒 be a set of parameter names and 𝑇𝑦𝑝𝑒 a set of data types. 𝑠 ∪ Definition 3.3 (Parameter). For service 𝑠, a parameter 𝑝 ∈ P𝑖𝑛 𝑠 P𝑜𝑢𝑡 is a typed interface declaration 𝑝 = (𝑛, 𝜏) ∈ 𝑁 𝑎𝑚𝑒 × 𝑇𝑦𝑝𝑒, where 𝑛 is the parameter name and 𝜏 is its type. We use the notation 𝑛 : 𝜏 as a shorthand for 𝑝 = (𝑛, 𝜏).
MODELS ’26, October 4–9, 2026, Malaga, Spain
Example Smart building DT Consider the smart building (sb) DT from the running example. We model it as 𝑇sb = (M𝑇sb , S𝑇sb ), where M𝑇sb = {𝑚𝑒 , 𝑚 𝑓 , ...} contains, among others, an energy simulation model 𝑚𝑒 and a fault detection model 𝑚 𝑓 ; and S𝑇sb = {𝑠𝑒 , 𝑠 𝑓 , ...} contains, among others, an energy simulation service 𝑠𝑒 and a predictive maintenance service 𝑠 𝑓 . Then, the energy simulation service is given by 𝑠𝑒 = ({𝑚𝑒 }, Σ𝑒 ), 𝑒 , P 𝑒 ), with where Σ𝑒 = (P𝑖𝑛 𝑜𝑢𝑡 𝑒 P𝑖𝑛 = 𝑜 : OccupancyReading, 𝑤 : WeatherData
and 𝑒 P𝑜𝑢𝑡 = 𝑝 : EnergyForecast. Here, 𝑜 denotes the input parameter for occupancy data, 𝑤 denotes the input parameter for weather data, and 𝑝 denotes the output parameter for the energy prediction.
Definition 3.4 (Service Behavior). For a DT service 𝑠, let B𝑠 denote the set of possible observable behaviors of 𝑠. A behavior 𝑏 ∈ B𝑠 represents one execution of the service, including the input data, output data, timestamps, and any metadata needed to evaluate data-quality conditions. An implementation of a service 𝑠 is represented semantically by a set I𝑠 ⊆ B𝑠 of behaviors that the implementation may exhibit. Definition 3.5 (Data-Quality Assertion). A data-quality assertion 𝑠 ∪ P 𝑠 is over a service 𝑠 is a pair 𝛼 = (P𝛼 , 𝜒𝛼 ), where P𝛼 ⊆ P𝑖𝑛 𝑜𝑢𝑡 the set of parameters targeted by the assertion, and 𝜒𝛼 : B𝑠 → {true, false} is a computable predicate over service behaviors. For a finite set 𝑋 of data-quality assertions over 𝑠, its denotation is the set of behaviors satisfying all assertions 𝛼 ∈ 𝑋 : ⟦𝑋 ⟧𝑠 = { 𝑏 ∈ B𝑠 | ∀𝛼 ∈ 𝑋 : 𝜒𝛼 (𝑏) = true }. By convention, if 𝑋 = ∅, then ⟦𝑋 ⟧𝑠 = B𝑠 . Predicate 𝜒𝛼 may be implemented by any suitable computation over the observed data and metadata, such as threshold checks, windowed completeness computations, moving averages, synchronization checks, statistical tests, or comparisons against a baseline. Definition 3.6 (Data Contract). A data contract 𝑐 for a DT service 𝑠 is a tuple 𝑐 = (𝑠, A, G), where A is a set of data quality assertions 𝑠 , and G is a set of data quality assertions over input parameters P𝑖𝑛 𝑠 . over output parameters P𝑜𝑢𝑡 We call A𝑐 = ⟦𝐴⟧𝑠 and G𝑐 = ⟦𝐺⟧𝑠 the assumption semantics and guarantee semantics of 𝑐, respectively.
Example Formal contract for the energy simulation service Consider the energy simulation service 𝑠𝑒 of the DT. Its data contract is 𝑐𝑒 = (𝑠𝑒 , A𝑒 , G𝑒 ), where A𝑒 is a set of input-side data-quality assertions and G𝑒 is a set of output-side data-quality assertions. To instantiate the data-quality assertions, we define observer functions over service behaviors. These functions extract measurable values from a behavior without changing that behavior: age𝑜 , age𝑤 : B𝑠𝑒 → R ≥0, complete𝑜 : B𝑠𝑒 × R>0 → [0, 1],
MODELS ’26, October 4–9, 2026, Malaga, Spain
and acc𝑝 : B𝑠𝑒 → [0, 1]. Functions age𝑜 and age𝑤 return the age of the most recent occupancy and weather readings. Function complete𝑜 (𝑏, Δ) returns the completeness ratio of occupancy data in behavior 𝑏 over time window Δ. Function acc𝑝 returns the accuracy of the energy forecast. We now define the assumption-type assertions (A𝑒 ). The first assertion requires occupancy data to be fresh: 𝛼𝑜,fresh = {𝑜}, 𝜒𝑜,fresh , where 𝜒𝑜,fresh (𝑏) ⇐⇒ age𝑜 (𝑏) ≤ 5 min is the computable predicate that evaluates to true iff the age of the occupancy reading is at most 5 minutes. Along the same lines, the other two assumptions are as follows: 𝛼 𝑤,fresh = {𝑤 }, 𝜒 𝑤,fresh , 𝜒 𝑤,fresh (𝑏) ⇐⇒ age𝑤 (𝑏) ≤ 15 min;
Philipp Zech and Istvan David
• A behavior 𝑏 ∈ B𝑠 satisfies 𝑋 iff 𝑏 ∈ ⟦𝑋 ⟧𝑠 . (Written as 𝑏 |=𝑠 𝑋 .) • For data contract 𝑐 = (𝑠, A, G), assumptions are met by a behavior 𝑏 iff 𝑏 |=𝑠 A, and guarantees are met by 𝑏 iff 𝑏 |=𝑠 G. Equivalently, we define the runtime predicates assumptionMet𝑐 (𝑏) ⇐⇒ 𝑏 ∈ ⟦A⟧𝑠 and guaranteeMet𝑐 (𝑏) ⇐⇒ 𝑏 ∈ ⟦G⟧𝑠 . • An implementation I𝑠 ⊆ B𝑠 satisfies contract 𝑐, written I𝑠 |= 𝑐, iff every implementation behavior that meets the assumptions also meets the guarantees: I𝑠 |= 𝑐 ⇐⇒ I𝑠 ∩ ⟦A⟧𝑠 ⊆ ⟦G⟧𝑠 . Thus, assumption satisfiability is used at design time as a sanity check to ensure an assumption set is possible, i.e., that ⟦A⟧𝑠 ≠ ∅. At runtime, we observe one concrete behavior 𝑏 and we check whether the observed behavior meets the assumptions: assumptionMet𝑐 (𝑏) ⇐⇒ 𝑏 ∈ ⟦A⟧𝑠 . Contract satisfaction is even stronger: it states that, for all behaviors an implementation may exhibit, whenever the assumptions are met, the guarantees are met as well, i.e., I𝑠 |= 𝑐 ⇐⇒ I𝑠 ∩ ⟦A⟧𝑠 ⊆ ⟦G⟧𝑠 . In addition, we define the notion of compatibility for design-time integration checks as follows.
and 𝛼𝑜,complete = {𝑜}, 𝜒𝑜,complete . 𝜒𝑜,complete (𝑏) ⇐⇒ complete𝑜 (𝑏, 15 min) ≥ 0.9. The assumption set, then, is A𝑒 = {𝛼𝑜,fresh , 𝛼𝑜,complete , 𝛼 𝑤,fresh }. Guarantee assertions are defined in a similar vein: 𝛾𝑝,acc = {𝑝}, 𝜒𝑝,acc ; 𝜒𝑝,acc (𝑏) ⇐⇒ acc𝑝 (𝑏) ≥ 0.95, and the guarantee set is G𝑒 = {𝛾𝑝,acc }.
Definition 3.8 (Compatibility). Let 𝑐 = (𝑠, A, G) be a data contract for service 𝑠, and let Dsrc ⊆ B𝑠 denote the set of behaviors guaranteed by the selected data sources, projected onto the input interface of 𝑠. The data sources are compatible with 𝑐 iff Dsrc ⊆ ⟦A⟧𝑠 . Example Checking contracts For the energy simulation contract 𝑐𝑒 = (𝑠𝑒 , A𝑒 , G𝑒 ), a design-time consistency check asks whether the assumption set is satisfiable, i.e., ⟦A𝑒 ⟧𝑠𝑒 ≠ ∅. This holds, e.g., with behavior 𝑏 ∈ B𝑠𝑒 such that
By the semantics of assertion sets, the assumption semantics is age𝑜 (𝑏) = 4 min ∧
⟦A𝑒 ⟧𝑠𝑒 = {𝑏 ∈ B𝑠𝑒 | age𝑜 (𝑏) ≤ 5 min ∧
complete𝑜 (𝑏, 15 min) = 0.95 ∧
complete𝑜 (𝑏, 15 min) ≥ 0.9 ∧
age𝑤 (𝑏) = 10 min
age𝑤 (𝑏) ≤ 15 min}, and the guarantee semantics is ⟦G𝑒 ⟧𝑠𝑒 = 𝑏 ∈ B𝑠𝑒 | acc𝑝 (𝑏) ≥ 0.95 .
This behavior satisfies all assumptions and therefore, it witnesses that the assumption set is satisfiable.
Thus, data contract 𝑐𝑒 = (𝑠𝑒 , A𝑒 , G𝑒 ) states that whenever occupancy and weather inputs meet the required freshness and completeness assumptions, the service is expected to produce an energy prediction whose accuracy is at least 0.95.
A design-time compatibility check is relative to the data source. Suppose the occupancy and weather data providers jointly guarantee behavior set Dsrc = {𝑏 ∈ B𝑠𝑒 | age𝑜 (𝑏) ≤ 3 min ∧ complete𝑜 (𝑏, 15 min) ≥ 0.95 ∧
Our formalization defines a precise vocabulary for data requirements and guarantees by separating the specification of data properties (the what), from their implementation and monitoring (the how). This allows both for (i) reasoning about contract compatibility at design time, and (ii) systematically enacting those contracts as runtime monitors that detect violations during operation. To realize design-time and run-time checks, we need the following notion of satisfiability and satisfaction. Definition 3.7 (Satisfiability, Satisfaction, Met Assumptions). Let 𝑠 be a DT service, 𝑋 a set of data-quality assertions over 𝑠, and ⟦𝑋 ⟧𝑠 ⊆ B𝑠 the set of behaviors satisfying all assertions in 𝑋 . • Assertion set 𝑋 is satisfiable over 𝑠 iff there exists at least one behavior satisfying all assertions in 𝑋 : ⟦𝑋 ⟧𝑠 ≠ ∅.
age𝑤 (𝑏) ≤ 10 min}, Since Dsrc ⊆ ⟦A𝑒 ⟧𝑠𝑒 , the selected data sources are compatible with the energy simulation contract.
Tab. 1 summarizes how these formal concepts map onto various checks at various lifecycle phases of a DT service.
3.2
A DSL for Data Contracts
The formal definitions in Sec. 3.1 map directly onto a DSL (cf. Fig. 1). A contract is expressed as a named Service with typed I/O parameters. Each parameter can be targeted by one or more Clauses, which are grouped into assumes and guarantees aggregations.
Model-Driven Data Contracts for Digital Twin Services
MODELS ’26, October 4–9, 2026, Malaga, Spain
Table 1: Contract validation and verification activities (DT = design-time, RT = run-time) Concept
Phase Formal condition
Question answered
Assertion-set satisfiability DT ⟦𝑋 ⟧𝑠 ≠ ∅ Assumption-set satisfiability DT ⟦A⟧𝑠 ≠ ∅ Source compatibility DT Dsrc ⊆ ⟦A⟧𝑠 Assumptions met RT assumptionMet𝑐 (𝑏 ) ⇐⇒ 𝑏 ∈ ⟦A⟧𝑠 Guarantees met RT guaranteeMet𝑐 (𝑏 ) ⇐⇒ 𝑏 ∈ ⟦G⟧𝑠 Contract satisfaction DT/RT I𝑠 |= 𝑐 ⇐⇒ I𝑠 ∩ ⟦A⟧𝑠 ⊆ ⟦G⟧𝑠
Is the assertion set 𝑋 internally possible? Are the contract assumptions internally possible? Do the selected data sources guarantee data that satisfies the service assumptions? Does the currently observed behavior satisfy the input-side assumptions? Does the currently observed behavior satisfy the output-side guarantees? Does the implementation guarantee the promised output quality whenever its assumptions are met?
A Clause binds a Property (e.g., Freshness, Completeness, Accuracy) to a relational Operator and a typed Value, optionally scoped to a Duration window. Our platform-agnostic DSL keeps the specification decoupled from any particular DT infrastructure and enables generation of actual contract implementations [53].
1
input
1
output
1..*
Service + name: String 1
assumes
1..* Parameter 1
+ type: Type
1
Operator
LE GE EQ
1 <<enumeration>>
Property FRESHNESS COMPLETENESS AVAILABILITY ACCURACY CONSISTENCY GRANULARITY SAMPLING_RATE MAX_SKEW
guarantees
+ inputs: Map<String,Type>
1
+ outputs: Map<String,Type> 1
has <<enumeration>>
* Clause
targets
+ name: String
1
1
*
has
1
1
has
has 0..1
1
Duration
Value
+ amount: Number
+ literal: String
+ unit: String
+ unit: String
Figure 1: Metamodel of data contracts for DT services.
3.2.1 Example: Contract expressed in the DSL (energy simulation service). Lst. 1 shows the contract for the energy simulation service (corresponding to Example 1), expressed in the DSL. Listing 1: Contract in DSL (energy simulation service) 1 2 3 4
service EnergySimulation { inputs : occupancy : OccupancyReading weather : WeatherData outputs : prediction : EnergyForecast
5
assumes { occupancy : FRESHNESS <= 5 min COMPLETENESS >= 0.9 over 15 min weather : FRESHNESS <= 15 min } guarantees { prediction : ACCURACY >= 0.95 }
6 7 8 9 10 11 12 13 14
}
At design time, our contracts can be used for model-checking to verify that the guarantees of data sources satisfy the assumptions of services and thus, identify incompatibilities before deployment. At runtime, monitors generated from these contracts enforce them over live data streams and raise a violation if a constraint is breached. This turns what would otherwise be silent degradation into an explicit and traceable event that the DT can act on.
3.3
Architectural underpinnings
Data contracts span the boundary between data producers and data consumers. ISO/IEC 30173 defines a DT as a digital representation of a real-world entity that is connected to that entity and provides services based on its data. This framing makes the data boundary explicit. The connection between the physical entity and its digital representation is precisely where data quality properties must be specified and enforced. We situate this boundary in two reference architectures widely used in DT and Industry 4.0 contexts. In ISO 23247, the reference architecture defines a Device Communication Entity (DCE) and a Digital Twin Entity (DTE). DT services reside in the DTE, consuming data forwarded by the DCE and exposing results to the User Entity (UE). A data contract is attached to a DT service: assumptions specify the data quality properties the service requires on its inputs, and guarantees specify the properties the service promises on its outputs to the UE and other services. Contract checking at design time verifies compatibility at both interfaces, and runtime monitors enforce them during operation. In RAMI 4.0, DT services reside in the Functional layer. A data contract is, again, attached to the service: assumptions specify what quality properties the service requires from data flowing from the Communication and Information layers; guarantees specify what the service promises to components above. Violations detected at runtime manifest in the Functional layer and trigger compensations.
4
Discussion
The smart building DT from Sec. 1 illustrates how data contracts apply across the full life cycle of a DT. Consider first the deployment stage. An energy optimization model requires occupancy, HVAC state, and weather data at defined rates and granularity. These assumptions are typically implicit, buried in model code or documentation. A contract makes them explicit at the service interface. Before deployment, a compatibility check at the DT boundary verifies that available data sources satisfy those assumptions and catches misconfigurations before it causes wrong outputs. The same logic applies during system integration when the DT integrates subsystems from different vendors with inconsistent formats and update semantics. Each service declares what it requires and guarantees, and compatibility is checked at the communication layers (cf. Sec. 3.3). Mismatches surface during composition rather than at runtime, where they are far more costly to fix. Once operational, contracts shift from design-time artifacts to runtime monitors. A fault detection model that receives stale or incomplete telemetry is a typical case. A monitor generated from a contract checks each incoming stream against the required data properties. A violation raises an explicit, traceable event rather than letting the model fail silently. That traceability also enables
MODELS ’26, October 4–9, 2026, Malaga, Spain
controlled failover. When a data feed fails, the contract identifies exactly which properties are violated and provides a formal basis for comparing alternative sources. The DT can switch to a substitute or fail gracefully, rather than continuing with corrupted outputs. Contracts also remain useful as the DT evolves. For example, when a building subsystem is upgraded and its data interface changes, all downstream dependencies are explicit in the contracts of affected services. Compatibility can be re-checked before the updated subsystem goes into operation, making upgrade impact traceable and reducing regression risk, a property that becomes increasingly important as DTs grow in scope [30]. These scenarios share a common theme: the absence of explicit data contracts forces engineers to rely on implicit assumptions, manual checks, or hard-coded logic. Alas, contracts do not eliminate underlying complexity. Sensors still fail, interfaces still change, and data continues to degrade. However, contracts still help by establishing the conditions for correct operation in a visible, checkable, and actionable way. This shift from implicit to explicit and from reactive to proactive is what our proposal fundamentally offers.
4.1
Benefits
Explicit data dependencies. Contracts make the assumptions between data producers and model consumers machine-readable. This is a prerequisite for any systematic quality management and replaces implicit, undocumented expectations [19]. Design-time compatibility checking. Before deployment, contracts can be used for model checking to verify that data source guarantees satisfy service assumptions. Incompatibilities are caught early, when they are cheapest to fix [45]. Runtime violation detection. Monitors generated directly from contracts enforce quality thresholds over live data streams. Violations trigger defined responses rather than silent degradation, improving DT reliability and trustworthiness [7, 51]. Code generation. The DSL decouples contract specification from implementation. Contract monitors can be generated for specific target platforms [12], keeping specifications reusable across different DTs and removing manual instrumentation effort [54]. Model-driven integration and discovery. Federated DTs often span heterogeneous technical and organizational boundaries [18]. Contracts merit their integration by automated matching of producers to consumers, discovery of back-up producers upon failure [1], and generation of producers stubs for continued operation [58].
4.2
Challenges
DSL coverage and expressiveness. The current DSL covers a core set of data quality properties which are capture as a fixed enumeration. This design choice prioritizes simplicity and strong typing for common use cases but inherently limits extensibility, e.g., adding a new, domain-specific property (e.g., SensorCalibrationStatus) requries touching the grammar. A key challenge for future work thus is to evolve our DSL into a more open model, e.g., by replacing the enumeration with a registry-based approach, where new properties can be defined and registered along with their validation logic (e.g., lambda functions). In addition, extending the DSL to composite and temporal constraints also requires further design work and empirical validation with practitioners. Getting the language right
Philipp Zech and Istvan David
is central. DSLs are only effective when they are expressive enough to capture real needs yet simple enough to be adopted [53]. Discovery of congruent data sources. Matching data sources to service assumptions at scale requires discovery mechanisms that go beyond static configuration. Model-driven techniques for automated source-to-consumer matching employing semantic descriptions and ontologies [15] are a natural direction, and the technologyagnostic nature of the DSL makes such integration feasible. Coordination and compensation mechanisms. When a violation is detected, the DT must respond accordingly. Specifying and generating coordination logic, e.g., using state machines or model transformations, to trigger fallback modes, switch sources, or degrade gracefully is a key open challenge. This is precisely where MDE has the most to offer by making coordination logic a first-class, generatable artifact rather than handwritten glue code [36]. Scalability and runtime overhead. Continuous monitoring of data quality constraints over voluminous streams introduces overhead. Efficient monitor synthesis and selective enforcement strategies [13, 25] need to be evaluated at scale in realistic DT settings. Tooling and integration. The approach requires tooling for contract authoring, compatibility checking, monitor generation, and violation handling. Building and validating this model-driven toolchain in realistic DT settings is the most immediate next step. Model-based tool integration provides a feasible path forward [24]. Observability for contract enforcement Our approach hinges on the observability of a DT. To enforce properties like FRESHNESS or SAMPLING_RATE, runtime monitors require access to, e.g., timestamps and source identifiers, along the raw data. This implies a foundational requirement for any contract-ready DT platform. We recommend that emerging DT standards define a minimal set of observability capabilities to ensure contract-readiness of DTs.
5
Future Plans
Our current goal is to implement a working prototype covering contract authoring, compatibility checking, and runtime monitor generation from DSL specifications. Following this, we plan to (i) validate the toolchain in realistic DT settings through case studies with practitioners; (ii) modify and extend the DSL to enable on-thefly integration of additional domain-specific properties, composite constraints, and temporal dependencies; (iii) develop automated source-to-consumer matching to discover compatible data sources at integration and switch between them at runtime; (iv) generate coordination and compensation logic directly from contract violations using state machines or model transformations, making graceful degradation a designable, generatable behavior; (v) evaluate the approach quantitatively, assessing the impact of contract enforcement on DT reliability and decision quality. These steps form a concrete path toward data quality as a first-class, model-driven engineering concern in DTs; and (vi) define a formal algebra for data contracts to enable compositional reasoning to derive end-to-end data quality guarantees from individual contracts at the service level.
Acknowledgments This research has been funded by the Austrian Research Promotion Agency (FFG), 927874; and the Natural Sciences and Engineering Research Council of Canada (NSERC), DGECR-2024-00293.
Model-Driven Data Contracts for Digital Twin Services
References [1]
[2] [3] [4]
[5] [6]
[7] [8] [9]
[10] [11] [12]
[13]
[14] [15]
[16] [17]
[18]
[19]
[20]
[21]
[22] [23] [24]
[25]
[26]
[27] [28]
Feyi Adesanya, Kanan Castro Silva, Valdemar V. Graciano Neto, and Istvan David. 2026. Systems of twinned systems: a systematic literature review. (2026). eprint: 2505.19916. Ashwin Agrawal et al. 2023. Digital Twin: Where Do Humans Fit In? Automation in Construction, 148, 104749. Daniel JW Arthur and Graham W Winch. 2025. Simulation Project Quality and Validation Profiling. Journal of Simulation, 19, 6, 694–710. Sebastian R. Bader and Maria Maleshkova. 2019. The Semantic Asset Administration Shell. In Semantic Systems. The Power of AI and Knowledge Graphs. Springer, 159–174. Yashoda Saisree Bareedu et al. 2024. Deriving semantic validation rules from industrial standards: An OPC UA study. Semantic Web, 15, 2, 517–554. Carlo Batini, Cinzia Cappiello, Chiara Francalanci, and Andrea Maurino. 2009. Methodologies for data quality assessment and improvement. ACM Comput Surv, 41, 3, Article 16, (July 2009). Nelly Bencomo et al. 2014. Modelsrun.time: Foundations, Applications, and Roadmaps. LNCS. Vol. 8378. Springer. Albert Benveniste et al. 2018. Contracts for System Design. Foundations and trends in electronic design automation, 12, 2-3, 124–400. Joakim Schack Betzer, Jalil Boudjadar, Mirgita Frasheri, and Prasad Talasila. 2024. Digital Twin Enabled Runtime Verification for Autonomous Mobile Robots under Uncertainty. In Intl. Symp. on Distributed Simulation and Real Time Applications, 10–17. A. Beugnard, J.-M. Jezequel, N. Plouzeau, and D. Watkins. 1999. Making components contract aware. Computer, 32, 7, 38–45. 2016. Digital Twin—The Simulation Aspect. Mechatronic Futures: Challenges and Solutions for Mechatronic Systems and their Designers. Springer, 59–74. Lola Burgueño, Davide Di Ruscio, Houari Sahraoui, and Manuel Wimmer. 2025. Automation in Model-Driven Engineering: A Look Back, and Ahead. ACM Trans Softw Eng Method, 34, 5, 1–25. Sara Casolari and Michele Colajanni. 2010. On the Selection of Models for Runtime Prediction of System Resources. In Run-time Models for Self-managing Systems and Applications. Springer, 25–44. Benoit Combemale et al. 2021. A hitchhiker’s guide to model-driven engineering for data-centric systems. IEEE Software, 38, 4, 71–84. Benoit Combemale et al. 2025. On the Challenges of Integrating Digital Twins. In 2025 ACM/IEEE 28th Intl. Conf. on Model Driven Engineering Languages and Systems Companion. IEEE, 243–249. Istvan David and Dominik Bork. 2024. Infonomics of Autonomous Digital Twins. In Advanced Information Systems Engineering. Springer, 563–578. Istvan David and Dominik Bork. 2023. Towards a taxonomy of digital twin evolution for technical sustainability. In ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion, MODELS-C. IEEE, 934–938. Istvan David, Guodong Shao, Claudio Gomes, Dawn Tilbury, and Bassam Zarkout. 2024. Interoperability of digital twins: challenges, success factors, and future research directions. In Leveraging Applications of Formal Methods, Verification and Validation. Application Areas. Springer, 27–46. Antonios Giatzis et al. 2024. Software Engineering Practices in Smart Contract Development: A Systematic Mapping Study. In Intl. Conf. on Product-Focused Software Process Improvement. Springer, 360–367. Raghavendran Gunasekaran and Boudewijn Haverkort. 2025. Verification of digital twins using classical and statistical model checking. Electron Proc Theor Comput Sci, 418, 16–23. Sunil Gupta, Ravi S. Iyer, and Sanjeev Kumar. 2025. Digital Twin Challenges. In Digital Twins: Advancements in Theory, Implementation, and Applications. Springer, 19–42. Juyong Jiang et al. 2026. A Survey on Large Language Models for code Generation. ACM Trans Softw Eng Method, 35, 2, 1–72. David Jones et al. 2020. Characterising the Digital Twin: A systematic literature review. CIRP J Manuf Sci Technol, 29, 36–52. Elisabeth Kapsammer, Thomas Reiter, and Wieland Schwinger. 2006. Modelbased Tool Integration—State of the Art and Future Perspectives. In Proc. of the 3rd Intl. Conf. on Cybernetics and Inf. Technologies, Systems and Applications. Dimitrios S. Kolovos, Richard F. Paige, and Fiona A. C. Polack. 2009. The Grand Challenge of Scalability for Model Driven Engineering. In Models in Software Engineering. Springer, 48–53. Adrian Kuhn and Gail C. Murphy. 2012. Lessons learned from evaluating MDE abstractions in an industry field study. In Intl Workshop on Experiences and Empirical Studies in Software Modelling Article 3. ACM, 5 pages. Daniel Lehner et al. 2025. Model-Driven Engineering for Digital Twins: A Systematic Mapping Study. Soft Sys Mod, 1–39. Martin Leucker and Christian Schallhart. 2009. A brief account of runtime verification. The Journal of Logic and Algebraic Programming, 78, 5, 293–303.
MODELS ’26, October 4–9, 2026, Malaga, Spain
[29]
[30] [31] [32]
[33] [34]
[35] [36]
[37]
[38] [39]
[40] [41]
[42] [43]
[44]
[45] [46]
[47]
[48] [49]
[50] [51]
[52] [53] [54] [55]
[56] [57] [58]
Aurora Macías, Elena Navarro, Carlos E. Cuesta, and Uwe Zdun. 2025. Requirements Engineering for Digital Twins: a Cross-Domain Systematic Literature Review. In Quality of Information and Communications Technology. Springer. Tiziana Margaria and Bernhard Steffen. 2009. Continuous Model-driven Engineering. Computer, 42, 10, 106–109. B. Meyer. 1992. Applying ’design by contract’. Computer, 25, 10, 40–51. Judith Michael, Istvan David, and Dominik Bork. 2024. Digital twin evolution for sustainable smart ecosystems. In ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion, MODELS-C. ACM, 1061–1065. Mariasimona Miglietta et al. 2025. The Role of Data in Digital Twins: Value Creation and Interoperability. In Intl. Conf. on Ext. Reality. Springer, 235–254. Stefan Mihai et al. 2022. Digital Twins: A Survey on Enabling Technologies, Challenges, Trends and Future Prospects. IEEE Communications Surveys & Tutorials, 24, 4, 2255–2291. Muhammad Naeem and Cristina Seceleanu. 2026. Contract-Based Verification of Digital Twins, 338–357. Juan Carlos Nieves et al. 2011. Coordination, Organisation and Model-Driven Approaches for Dynamic, Flexible, Robust Software and Services Engineering. In Service engineering: European research results. Springer, 85–115. Pierluigi Nuzzo, Alberto L. Sangiovanni-Vincentelli, Davide Bresolin, Luca Geretti, and Tiziano Villa. 2015. A Platform-Based Design Methodology With Contracts and Related Tools for the Design of Cyber-Physical Systems. Proc. of the IEEE, 103, 11, 2104–2132. Ezekiel B. Ouedraogo et al. 2025. Digital Twin Data Management: A Comprehensive Review. IEEE Trans. on Big Data, 11, 5, 2224–2243. A Paladugu, A Fernandes, and M IJtsma. 2024. The Use of Computational Modeling and Simulation to Design and Evaluate a Distributed Work System. In Proc Hum Factors Ergon Soc Annu Meet number 1. Vol. 68. SAGE, 243–249. Leo L. Pipino, Yang W. Lee, and Richard Y. Wang. 2002. Data quality assessment. Commun ACM, 45, 4, (Apr. 2002), 211–218. M Mazhar Rathore, Syed Attique Shah, Dhirendra Shukla, Elmahdi Bentafat, and Spiridon Bakiras. 2021. The Role of AI, Machine Learning, and Big Data in Digital Twinning: A Systematic Literature Review, Challenges, and Opportunities. IEEE Access, 9, 32030–32052. Lisa Rennels and Sarah E Chasins. 2023. How domain experts use an embedded DSL. Proc ACM Program Lang, 7, OOPSLA2, 1499–1530. Siva D. Chandrasekaran Saratha, Christoph Grimm, and Frank Wawrzik. 2021. A Digital Twin with Runtime-Verification for Industrial DevelopmentOperation Integration. In IEEE Intl Conf on Eng, Tech and Inno, 1–9. Rainer Schiekofer, Stephan Grimm, Maja Milicic Brandt, and Michael Weyrich. 2019. A Formal Mapping Between OPC UA and the Semantic Web. In 2019 IEEE 17th Intl. Conf. on Industrial Informatics (INDIN). Vol. 1, 33–40. Douglas C Schmidt et al. 2006. Model-driven Engineering. Computer, 39, 2, 25. Miel Sharf, Bart Besselink, Adam Molin, Qiming Zhao, and Karl Henrik Johansson. 2021. Assume/guarantee contracts for dynamical systems: Theory and computational tools. IFAC-PapersOnLine, 54, 5, 25–30. Stefano Spellini, Roberta Chirico, Marco Panato, Michele Lora, and Franco Fummi. 2020. Production Recipe Validation through Formalization and Digital Twin Generation. In 2020 Design, Automation & Test in Europe Conference & Exhibition (DATE), 1698–1703. Fei Tao, Bin Xiao, Qinglin Qi, Jiangfeng Cheng, and Ping Ji. 2022. Digital Twin Modeling. J Manuf Syst, 64, 372–389. Duc Do Tran, Kim Grüttner, Frank Oppenheimer, and Wolfgang Nebel. 2020. Timing Contracts and Monitors for Safety Relevant Controller Design in IEC 61499. In 2020 25th IEEE Intl. Conf. on Emerging Technologies and Factory Automation (ETFA). Vol. 1, 156–163. Hendrik Van Der Valk, Hendrik Haße, Frederik Möller, and Boris Otto. 2022. Archetypes of Digital Twins. Business & Inf Sys Eng, 64, 3, 375–391. Michael Vierhauser, Hussein Marah, Antonio Garmendia, Jane Cleland-Huang, and Manuel Wimmer. 2021. Towards a Model-Integrated Runtime Monitoring Infrastructure for Cyber-Physical Systems. In 2021 IEEE/ACM 43rd Intl. Conf. on software engineering: new ideas and emerging results (ICSE-NIER). IEEE, 96–100. Richard Y. Wang and Diane M. Strong. 1996. Beyond Accuracy: What Data Quality Means to Data Consumers. J Manag Inf Syst, 12, 4, 5–33. Andrzej Wąsowski and Thorsten Berger. 2023. Domain-Specific Languages. Springer. Jon Whittle, John Hutchinson, and Mark Rouncefield. 2013. The State of Practice in Model-driven Engineering. IEEE software, 31, 3, 79–85. Samira Zahmatkesh and Philipp Zech. 2026. Spatio-Temporal Missing Data Imputation: A Systematic Literature Review with a Focus on Statistical and Machine Learning-Based Approaches. ACM Comput Surv, 58, 10, 41 pages. Philipp Zech et al. 2026. Model-based digital twin engineering: insights, challenges, and future directions. Soft Sys Mod, 1–43. Philipp Zech et al. 2025. Model-driven Digital Twins for AECO. In ACM/IEEE Intl. Conf. on Model-Driven Engineering Lang and Sys Comp. IEEE, 224–235. Hengcheng Zhu et al. 2023. Stubcoder: automated generation and repair of stub code for mock objects. ACM Trans Softw Eng Method, 33, 1, 1–31.