An Integrated Model for Temporal Provenance, Causal Versioning, and Conflict Resolution in Distributed Digital Product Passports

Abstract

Digital Product Passports (DPPs) must preserve reliable component histories across repair, removal, and reuse, even when lifecycle updates are concurrent or reported retrospectively. This paper proposes an integrated model combining permanent identifiers, temporal containment relationships, causal versioning, and explicit acceptance decisions to ensure consistent lifecycle records. The model was implemented using Hyperledger Fabric, Java chaincode, and a Spring Boot REST API. Evaluation included blockchain-only and end-to-end tests covering concurrent lifecycle operations, transaction performance, historical reconstruction, and idempotency checks. The results confirmed correct lifecycle transitions and reconstruction of accepted product states. At 200 concurrent clients, sustained UPDATE and direct GET throughput reached 348.61 and 1210.98 requests/s, respectively. Across three contention experiments, 265 of 300 INSTALL requests were accepted, with no inconsistent component placements detected. On an expanded ledger, historical reconstruction averaged 1562.3 ms with one client and 4135.0 ms with ten clients, revealing a scalability limitation. All experiments were conducted on a single-machine Hyperledger Fabric prototype. Improved historical indexing and evaluation in physically distributed environments remain for future work.

1. Introduction

1.1. Background and Motivation

The transition to a circular economy relies on extending products’ life through maintenance, repair, refurbishment, and reuse instead of replacing products at the end of their initial service period [1,2]. To make these practices possible, reliable information about product composition, condition, and lifecycle history is needed. This is particularly important when products and components move between different organizations. The European Ecodesign for Sustainable Products Regulation (ESPR), established through Regulation (EU) 2024/1781, introduces a regulatory framework for Digital Product Passports (DPPs). This framework reinforces the importance of accessible and interoperable product information [3].

DPPs function as a mechanism for collecting and sharing product-related information throughout the lifecycle, supporting traceability, environmental impact evaluations, and strategic choices for the circular economy [4,5]. Their practical implementation involves an extensive network of manufacturers, suppliers, service providers, refurbishers, recyclers, and other stakeholders with various data needs and responsibilities [6]. Therefore, DPP frameworks have to support not only the storage and retrieval of product data but also its ongoing evolution as products undergo material changes and organizational transitions.

Maintenance, repairs, and reuse constantly alter a product’s physical state during and after operation, creating significant challenges. Recent studies indicate the limited support for dynamic information updates involving independent service providers [7], while lifecycle-focused DPP systems show that manufacturers’ and recyclers’ information sharing is very important [8]. For complex industrial goods, tracking only current configurations of products is not enough to reconstruct previous component placements or trace the provenance of reused parts. Since parts often move between assemblies after servicing, documenting these replacements needs persistent component identification and clear chronological relationships between assets.

These challenges become more complex when lifecycle information is generated independently by multiple organizations. Participants often document activities using deficient or obsolete product status information. This can result in overlapping, late, or conflicting entries. The order of submissions to a unified database may not match the actual operational logic. As established in distributed systems research, causal ordering differs from the chronological ordering of messages or transactions [9]. Therefore, validating simultaneous lifecycle modifications needs to evaluate both their causal dependencies and their impact on the product’s physical state.

Blockchain-based architectures provide mechanisms for maintaining shared, tamper-proof records across organizational boundaries. Permissioned solutions such as Hyperledger Fabric provide identity-based participation, transaction validation, and an ordered ledger history [10]. Nevertheless, simple sequencing fails to confirm if separate lifecycle assertions represent a physically consistent product state. Additionally, conflicts over shared assets can trigger failed transactions under optimistic concurrency models [11]. Fabric performance is also influenced by platform configuration, making it important to evaluate the overhead introduced by additional consistency mechanisms [12]. Under these circumstances, DPP implementations need specialized functions to separate valid modifications from conflicting assertions while maintaining the provenance of records.

These considerations motivate an integrated approach to distributed DPP lifecycle management that combines persistent component identity, temporal provenance, causal versioning, semantic conflict resolution, and consistency-aware transaction processing. This approach needs to separate recorded lifecycle assertions from their accepted operational effects while maintaining a full, verifiable record. The following subsection examines the existing research foundations and technological approaches relevant to these requirements.

1.2. Related Work

DPP research has evolved from theoretical and legal outlines toward functional frameworks for managing data across product lifespans. Lopes and Barata [13] analyzed this field, pinpointing data governance, technological infrastructure, and interoperability as important challenges. Investigating 225 sustainable manufacturing papers, Psarommatis and May [14] noted inconsistent modeling, insufficient real-world testing, and the necessity for interoperable architectures. Our previous systematic review [15] identified interoperability, scalability, and lifecycle management challenges in blockchain-based DPPs. Unlike that review, the present study develops and experimentally evaluates an integrated model for temporal provenance, causal versioning, and lifecycle consistency.

Several contributions have explored various blockchain architectures for handling DPPs. In our earlier work, Hulea et al. [16] introduced a multi-blockchain system using Hyperledger Fabric and decentralized identifiers to manage product data and ensure permanent identification. This research also detailed an extensive DPP schema containing products, manufacturers, suppliers, materials, and their relationships. Miron and Hulea [17] further analyzed Hyperledger Fabric’s utility for DPP management, focusing on performance metrics and transaction processing. Additionally, Hulea et al. [18] employed an Eclipse Dataspace Connector to model policy-governed data sharing between independent organizations. While these studies collectively resolved issues regarding secure storage, identification, and cross-organizational transfer, they lacked a unified method for tracking temporal component relationships while reconciling independently generated lifecycle assertions.

Alternative blockchain and industrial data sharing frameworks have been proposed. Abreu et al. [19] created a textile-focused blockchain DPP prototype and established design guidelines for supply chain information movement. To facilitate cooperation between recyclers and manufacturers, Kim et al. [20] integrated federated learning with blockchain-managed DPPs. Meanwhile, Gleich et al. [21] introduced a DPP structure utilizing Gaia-X services and the Asset Administration Shell for inter-organizational exchange and standardized interfaces. These methods illustrate various techniques for managing product information, architectural fusion, and industrial use cases. None of them enforce the temporal and causal consistency constraints.

Tracking evolving product configurations is crucial for maintenance, refurbishment, and reuse. Wan and Jiang [7] noted DPP data flow gaps during usage, suggesting external service providers help manage lifecycle records. Abdel-Aty et al. [22] evaluated the use of DPP information in a remanufacturing scenario, demonstrating operational benefits while also identifying limitations in broader sustainability outcomes. These studies prove that post-manufacturing data accessibility is very important. However, recording repairs or part replacements fail to guarantee that fragmented records reflect one consistent physical state, especially if the components are transferred between different products.

Versioning represents another important aspect of long-lived DPP infrastructures. Burkhalter and Grösser [23] introduced a schema-governed federation model that isolates persistent DPP identity from immutable revisions while handling dependencies between autonomous schemas and passport references. This method solves issues regarding long-term readability, changing schemas, and cross-platform referential integrity. These requirements align with individual lifecycle coherence. While schema versioning ensures updated passport formats stay readable, lifecycle versioning defines how operations performed on physical products and components relate to one another. This is particularly important when various parties contribute data based on differing information.

Data provenance studies provide foundations for depicting historical records. Herschel et al. [24] classified provenance approaches by purpose, representation, and system requirements, highlighting their diversity across application domains. While the W3C PROV-DM specification [25] defines a general representation of entities, activities, agents, and their relationships, GS1 EPCIS 2.0 [26] standardizes mechanisms for exchanging visibility events concerning identified objects. Furthermore, W3C DID [27] assists with persistent identification. These standards provide methods for identifying assets, documenting operations, and exchanging provenance information; however, they lack specific rules for installation-slot occupancy, component placement, or reconciling contradictory lifecycle claims. Similarly, SQL:2011 [28] provides mechanisms for managing time-dependent information. Although useful for historical reconstruction, these mechanisms cannot alone determine causal relationships between updates from different organizations.

The management of concurrent updates has been studied extensively in distributed systems. Lamport [9] differentiated logical causality from physical time, creating a basis for ordering events based on their dependencies. Shapiro et al. [29] defined Conflict-Free Replicated Data Types to ensure convergence guarantees for replicated information under defined operation semantics. Earlier replicated systems, such as Bayou [30], also introduced application-aware conflict detection and resolution mechanisms for independently generated updates. These approaches prove that concurrent changes can be sometimes resolved without requiring immediate, unified ordering. However, physical component lifecycle operations impose limitations that automatic merging cannot always solve. While two compatible inspection records might function together, overlapping installations of one component needs explicit consistency verification and formal resolution.

Managing blockchain transactions adds unique coordination and performance challenges. Hyperledger Fabric uses endorsement policies, validation mechanisms, and ordered commitment [10], but its transaction ordering system fails to establish physical compatibility or causal dependencies between independent lifecycle claims. Chacko et al. [11] explored Fabric transaction failures, while Thakkar et al. [12] analyzed configuration parameters and performance bottlenecks. Additionally, Guggenberger et al. [31] found that stricter endorsement policies and larger networks reduced Fabric throughput, while LevelDB outperformed CouchDB. Gorenflo et al. [32] showed that architectural optimizations can significantly boost transaction volume. While these works establish a foundation for assessing blockchain frameworks, commit latency and throughput metrics fail to describe DPP application’s responsiveness or lifecycle integrity.

Existing research covers various aspects of decentralized DPP management, such as persistent identification, data interoperability, provenance, versioning, and blockchain performance. However, these topics are typically explored via isolated frameworks or unique use cases. Limited assessment exists regarding the collective integration of component-level temporal provenance, causal relationships between independently generated events, and semantic consistency constraints. Therefore, this study proposes a unified lifecycle methodology in which recorded assertions are distinguished from accepted operational effects, historical component relationships remain reconstructable, and transaction-processing strategies can be evaluated without overlooking consistency requirements. Section 1.3 outlines the specific research gaps and contributions addressed in this study.

Table 1 compares selected DPP approaches, the EPCIS standard, and distributed consistency mechanisms against the requirements addressed in this study.

Table 1. Comparison of related approaches concerning component lifecycle consistency.

Approach	Temporal Validity	Causal Versioning	Physical Constraints	Conflict Resolution	Cross-Product Tracing
Wan and Jiang [7]	◪	—	—	—	—
Hulea et al. [16]	—	—	—	—	—
Abreu et al. [19]	◪	—	—	—	—
Gleich et al. [21]	◪	—	—	—	—
Burkhalter and Grösser [23]	—	—	—	—	◪
GS1 EPCIS [26]	◪	—	—	—	✓
Bayou [30]	—	—	—	✓	—
Proposed model	✓	✓	✓	✓	✓

✓: explicitly supported; ◪: related functionality without the specified consistency guarantees; —: not demonstrated in the cited approach. Temporal validity refers to effective-time consistency of component relationships, rather than event timestamps alone. Physical constraints refer to component placement and lifecycle eligibility, while cross-product tracing concerns preserving component identity across different host products.

The comparison distinguishes lifecycle data recording, schema evolution, and general conflict resolution from explicit consistency enforcement for physical components. The proposed model combines effective-time containment, causal dependencies, lifecycle invariants, and acceptance decisions to maintain consistent component histories across product lifecycles.

1.3. Research Gaps and Contributions

The reviewed literature provides foundations for DPP architectures, lifecycle traceability, distributed data management, and blockchain transaction processing. However, integrating these mechanisms within collaborative environments where independent organizations edit shared product records remains difficult. Existing DPP implementations generally prioritize identity, interoperability, storage, or isolated lifecycle operations. The reviews [14,15] identify unresolved DPP lifecycle management challenges, while Burkhalter and Grösser [23] address schema-level versioning rather than causal consistency of physical lifecycle events. Additionally, while distributed computing provides methods for detecting concurrent updates [9,29], using these for physical component relationships needs additional semantic constraints that cannot always be satisfied through automatic merging.

Three related research gaps were identified. First, a temporal model is needed to maintain persistent component identities across different products, ensuring historical placements, and preventing physical misconfigurations. Second, instead of relying exclusively on blockchain transaction ordering, independently generated lifecycle events require assessment based on their causal relationships and their effects on the accepted product state. Third, the interaction between lifecycle consistency mechanisms and transaction processing lacks thorough analysis, especially during concurrent workloads, conflicting updates, or repeated submissions.

This study addresses these challenges by proposing a unified framework for consistent lifecycle management in distributed DPP systems. Its principal contributions are:

• Integrated time and causality framework—a single model merges persistent component IDs, immutable lifecycle events, time-based containment, and causal versioning. It separates recorded assertions from their accepted operational effects, supporting historical reconstruction and component reuse across various product passports.
• Consistency-aware conflict detection and resolution—a semantic validation mechanism that combines causal relationships with lifecycle invariants; it is used to distinguish compatible updates from contradictory operations. Explicit acceptance decisions, conflict records, and concurrency-control mechanisms preserve the consistency of accepted product states without discarding conflicting assertions.
• Consistency-aware blockchain architecture and implementation—a Hyperledger Fabric-based architecture is proposed to implement the unified lifecycle model. It employs Java chaincode, a Spring Boot API, and explicit concurrency-control mechanisms. The system integrates atomic operations, idempotent transactions, resource-specific guard keys, and historical state access to ensure consistency while preserving auditable lifecycle records.
• Experimental evaluation—a Java-based prototype enables functional testing and performance evaluation of the integrated model under different concurrency levels, conflict rates, and historical query workloads. Testing focuses on consistency enforcement, conflict handling, latencies, throughput, and scalability.

The contribution lies not in introducing these mechanisms individually, but in their coordinated application to component-level lifecycle consistency, where temporal validity, causal dependencies, and physical constraints must be evaluated together.

2. Materials and Methods

2.1. Problem Definition and System Assumptions

Decentralized DPP systems need to integrate lifecycle data from different organizations while maintaining consistent representation of products and their components. Managing this data is especially difficult during asset maintenance, part replacement, refurbishment, or reuse across different products. The proposed framework addresses these challenges by decoupling the recording of lifecycle assertions from their acceptance as legitimate changes to a product’s operational state.

2.1.1. Distributed DPP Lifecycle Management

The considered ecosystem involves manufacturers, service providers, repairers, refurbishers, recyclers, and authorized participants that independently contribute information to product lifecycles. Each participant records only specific operations, resulting in fragmented perspectives regarding a product’s state and composition.

This framework focuses on uniquely identified physical assets, such as complete products, components, and assemblies. Assets may be nested within larger products while containing their own sub-parts. The identity is preserved across maintenance, removal, repair, and reuse if identity policies consider it to remain the same physical object. Material-level mixing, splitting, or mass-balance tracking are excluded, as these need distinct traceability mechanisms. Consequently, the model does not directly support recycling scenarios in which identifiable components are broken down and mixed into bulk materials, as these processes require material-level traceability and mass-balance mechanisms beyond the proposed asset-based representation.

For example, an industrial motor starts in machine P1. After removal, it undergoes inspection and repair before installation in machine P2. Various organizations generate independent lifecycle events regarding the motor’s state, location, and reuse status. This data must maintain the motor’s unique identity and its historical links to both machines.

This environment faces multiple consistency challenges. Two entities might report clashing installations for one part, or late maintenance records could conflict with previously approved lifecycle transitions. On the other hand, simultaneous updates like separate component inspections might be valid and require acceptance. Additionally, the sequence of ledger submissions often deviates from claimed physical timing or causal dependencies [9].

Thus, the central problem is more than recording events or ordering transactions. A distributed DPP must evaluate if separate assertions can form a unified operational state while retaining data to rebuild past configurations or justify revisions.

2.1.2. System Assumptions and Trust Model

The framework operates within a consortium-governed, permissioned environment where all participants undergo identification and authentication. Participants have specific roles determining which lifecycle operation they can submit or approve. Asset registration, status changes, inspection criteria, and conflict resolution are all dictated by defined policies.

Each registered physical asset receives a permanent identifier. The ID is linked to the physical object via organizational registration protocols. While the ledger maintains unique IDs, it cannot independently detect if multiple identifiers represent the same physical object. Thus, verifying physical identity falls to consortium oversight.

Ensuring consistency requires that shared asset operations occur within a unified transaction-ordering and validation domain. The data needed to assess structural and temporal constraints must be available during transaction validation. In the proposed Hyperledger Fabric implementation, deterministic chaincode and transaction checks facilitate cross-organizational updates [10,11].

This is vital when components move between different organizations’ products. Maintenance of placement history must follow uniform consistency standards, irrespective of which participant records the event. The model cannot ensure exclusive placement across disconnected blockchains, separate channels, or other external systems. This framework also assumes that lifecycle assertions include specific issuers, operation IDs, causal metadata, and enough data to determine the affected resources. Because independent participants lack synchronized clocks, effective timestamps represent claimed occurrence times instead of absolute ordering. Causal relationships are represented separately from timestamps, as described in Section 2.2.4.

Attribution and integrity rely on cryptographic signatures and evidence references; however, these do not verify physical reality. Authenticated users might submit erroneous, late, or deceptive assertions. Consequently, the system ensures digital history consistency based on specific assumptions, not the objective accuracy of physical events.

Finally, only authenticated and structurally admissible assertions are eligible for persistent lifecycle recording. Submissions failing initial validation or permission checks are dismissed before reaching the ledger. However, once recorded, assertions persist regardless of whether their intended lifecycle outcomes are later accepted, rejected, or superseded.

2.1.3. Consistency Requirements and Research Questions

Based on the identified problem and system assumptions, the proposed framework must satisfy several requirements.

First, physical identities need to be persistent throughout lifecycle transitions to ensure components remain traceable between different products. Second, time-based representation of product composition is necessary to rebuild past configurations without losing previous data. Third, independent events require assessment based on causal dependencies and semantic effects to separate compatible updates from conflicting assertions.

In addition, the accepted operational state must adhere to relevant identity, structural, and lifecycle constraints. Conflict resolutions or rectifying history must preserve existing records, while re-submitted transactions must avoid creating redundant or inconsistent business effects. These requirements are formalized through the lifecycle model and invariants presented in Section 2.2.

The study addresses the following research questions:

• How can component identity, temporal containment relationships, and causal event dependencies be integrated to preserve auditable lifecycle histories across different products?
• How can independent lifecycle events be validated and reconciled while maintaining structural and temporal consistency under concurrent and delayed updates?
• What are the performance and scalability implications of enforcing integrated temporal and causal consistency under varying concurrency levels, conflict rates, and ledger sizes?

These three questions guide the design of the unified model in Section 2.2, the conflict-detection and resolution mechanisms in Section 2.3, and the implementation and experiments described in Section 2.4 and Section 2.5. The experimental results are presented in Section 3.

2.2. Unified Temporal and Causal Lifecycle Model

This section introduces a unified lifecycle model for distributed DPPs, combining persistent component identity, temporal provenance, causal versioning, and state consistency constraints. This model is designed for settings where multiple organizations autonomously produce lifecycle data regarding products and their components. Such information may arrive out of order, describe concurrent operations, or contain incompatible claims about the physical state of an asset.

The proposed approach separates immutable lifecycle records from the operational state derived from those entries. Each submitted event is maintained as an attributed assertion, while explicit acceptance decisions determine whether and how that event affects the product’s state. Chronological links outline the reported timing of physical changes, while causal versions reflect the information available to stakeholders when those modifications were recorded. Consistency constraints regulate which combinations of events are permitted to contribute to an accepted product state.

By maintaining this separation, a foundation is established for maintaining component provenance across repair and reuse cycles without allowing concurrent or delayed updates to silently introduce contradictory lifecycle states.

2.2.1. Persistent Component Identity and Lifecycle Data Model

Existing DPP data models offer useful bases for structuring data throughout product lifespans. Kebede et al. [33] developed a modular DPP ontology demonstrating the feasibility of reusable information models, while Koppelaar et al. [34] identified 14 information management processes supporting critical raw material reuse and recycling. The proposed model builds on these concepts by detailing persistent physical assets, time-based containment relationships, and lifecycle acceptance decisions.

The model considers specific physical assets that can be tracked through different product lifecycles. Such an asset might be a complete product, a swappable component, or an assembly containing other assets. Every asset is linked to a permanent and distinct identifier (id), which remains unchanged during any lifecycle operations that maintain the asset’s identity.

Furthermore, an asset might feature an external identifier, such as a Decentralized Identifier (DID), to facilitate tracking between different organizational platforms. Modifications to the product’s owner, custody, condition, or internal structure do not inherently generate a new physical identity. Similarly, activities such as maintenance, inspection, and repair retain the original identifier if the relevant identity policy considers the physical asset to remain the same.

Figure 1 illustrates the principal entities and associations of the proposed unified lifecycle model, including their corresponding multiplicities.

Figure 1. Unified UML data model of the proposed temporal and causal DPP lifecycle model. Association multiplicities describe persistent record relationships, while temporal composition constraints are enforced through the defined lifecycle invariants.

The model introduces the following principal record types:

• Actor—represents an organization or authorized participant responsible for submitting lifecycle events and performing operations according to assigned roles and permissions.
• Asset—identifies a physical object and stores its persistent identity and associated metadata.
• DigitalProductPassport—provides a persistent reference to the lifecycle information associated with a product.
• LifecycleEvent—represents an immutable, attributed assertion concerning a lifecycle operation.
• LifecycleEventData—encapsulates the operation-specific parameters and references associated with a lifecycle event.
• AcceptanceDecision—records whether a lifecycle event contributes to the accepted operational state.
• ContainmentInterval—represents a time-bounded physical relationship between a component and its host.
• Inspection—associates evidence with the condition or eligibility of an asset.
• Conflict—identifies lifecycle assertions whose combined effects cannot be accepted without reconciliation.
• Resolution—records an authorized decision concerning an identified conflict.

The DigitalProductPassport entity serves as a simplified core representation of a product passport, providing the logical context for its lifecycle information. This entity maintains an identity separate from both its underlying assets and specific revisions of its recorded data. The proposed framework prioritizes component-level provenance, causal relationships, and longitudinal coherence over an exhaustive depiction of DPP information. A more comprehensive schema, incorporating entities for products, manufacturers, suppliers, materials, and their respective mappings, was detailed in our prior research [16]. Accordingly, a component may retain the same ID after removal from one product and subsequent installation in another, while its lifecycle history remains accessible independently of either host product.

Product composition is represented through explicit containment relations between assets. Each relation identifies a host, a component, and a physical installation slot. This structure supports hierarchical assemblies in which an asset may simultaneously act as a component of a larger product and as a host for smaller components.

Containment is distinguished from ownership, custody, and authorization. An organization in possession of a specific asset does not inherently have permission to modify its lifecycle information, nor does a transfer of ownership automatically imply a modification in its physical placement.

Lifecycle events and acceptance decisions are maintained as independent datasets. This separation enables the framework to retain competing assertions, even in instances where only a single assertion contributes to the accepted physical configuration.

The resulting data model supports both product-oriented queries, such as identifying the components integrated within a specific machine, and component-centric queries, such as tracing the sequence of products in which a particular motor has been used.

2.2.2. Lifecycle Events and Acceptance Decisions

Changes to a product or component are represented by immutable lifecycle events, not by direct replacements of previously recorded information. Each event describes an operation submitted by an identified actor and includes the information needed for temporal interpretation, causal analysis, and subsequent validation.

e = ⟨id, D, A, actor, opId, type, data, P, V, t_eff, t_issue, evidence, σ⟩,

(1)

where id identifies the lifecycle event; D represents the DPPs affected by the event; A represents the affected assets and structural resources; actor represents the submitting organization or authorized participant; opId is an operation identifier whose uniqueness is enforced across all actors within the chaincode state, supporting idempotent submissions; type specifies the lifecycle operation; data contains operation-specific attributes; P identifies the causally preceding events known to the issuer; V represents the causal version vector; t_eff specifies the claimed effective time of the physical operation; t_issue records when the assertion was generated; evidence holds references to supporting documentation; and σ represents the event’s digital signature.

The collection of affected DPPs may contain several records. For example, transferring a component between two machines involves the persistent identity of the transferred component and the composition histories of both machines. Consequently, the framework does not assume that lifecycle events or consistency constraints are limited to an individual passport.

Standard lifecycle operations encompass registration, evaluation, servicing, extraction, setup, substitution, restoration, and decommissioning. A singular replacement operation can describe both the extraction of a current component and the installation of its successor, enabling the corresponding structural effects to be evaluated together.

Once recorded, the event payload remains immutable. Nevertheless, its existence within the distributed ledger fails to guarantee that the asserted physical operation has been integrated into the official product status.

The representation of lifecycle operations as attributed events is consistent with provenance concepts [25] and event-based product visibility standards such as GS1 EPCIS [26]. Nevertheless, the proposed AcceptanceDecision entity creates an additional distinction between recording an assertion and permitting its effects to modify the accepted lifecycle state. In the implemented prototype, lifecycle acceptance is determined automatically by the Java chaincode through causal, temporal, and structural validation, without requiring manual approval. Each processed event and its AcceptanceDecision are recorded atomically within the same Fabric transaction. The decision is linked to the original event through its eventId and contains the acceptance outcome, policy reference, and justification. Only ACCEPTED events modify the operational state and contribute to historical reconstruction, while rejected assertions remain available for auditing. Fabric commit validation determines whether the transaction is committed, independently of its semantic acceptance outcome.

For operational interpretation, the model distinguishes four effective event statuses:

• ACCEPTED—the event contributes to the accepted lifecycle state.
• PENDING—the event is recorded but awaits additional validation or conflict resolution.
• REJECTED—the event is not permitted to modify the accepted state.
• SUPERSEDED—a previously accepted event or decision has been replaced through an authorized correction or resolution.

These statuses describe the conceptual lifecycle model. The current prototype records ACCEPTED or REJECTED decisions for processed events, while PENDING is used for unresolved conflict records. Missing causal dependencies cause submission errors rather than persisted PENDING events. Conflict resolution is explicitly initiated through the API and does not automatically promote rejected events to accepted status. Automated pending-event re-evaluation and status promotion remain in future work.

The accepted product state is reconstructed through the aggregation of lifecycle events and their respective acceptance decisions. Superseded or conflicting assertions are preserved for audit purposes, allowing the system to differentiate between the complete recorded history and the currently recognized interpretation of that history.

2.2.3. Temporal Provenance and Containment Relations

The proposed model therefore represents physical containment using explicit validity intervals. Each accepted containment relation associates a component with a host and installation slot over a half-open interval:

c = ⟨componentId, hostId, slotId, validFrom, validTo⟩.

(2)

The interval [validFrom, validTo) specifies the period during which the component is considered installed in the corresponding host. An unspecified validTo indicates an open-ended placement.

The use of half-open intervals facilitates the migration of a component between distinct hosts at the same effective moment, thereby preventing the occurrence of artificial overlaps. A component remains detached during periods in which no accepted containment interval applies.

Relationships regarding temporal containment are established based on accepted lifecycle operations. While their representations can be instantiated to optimize query performance, any modifications to the accepted interpretation must remain traceable to the corresponding immutable assertions and decisions.

The model distinguishes three temporal dimensions:

• effective time—represents when a participant claims that a physical operation occurred. This value describes the asserted real-world chronology but cannot independently prove that the operation took place.
• causal order—expresses the dependencies between lifecycle events based on the information available to the issuing participants. It is independent of physical timestamps and is examined in Section 2.2.4.
• ledger order—identifies the sequence in which assertions and decisions become part of the shared ledger history. A monotonically ordered ledger position, denoted by ℓ, provides a reference for reconstructing previously recognized information.

These dimensions support historical queries that differentiate between the effective state of a product and the information available at a particular stage of the recorded history.

Provenance studies validate separating recorded information and its historical interpretation. Moreau et al. [35] developed a general model for representing provenance relationships, and Buneman et al. [36] separated the sources of data from the reasons for its presence in query results. Additional research explored capturing provenance within distributed scientific workflows [37] and the interpretation of database derivation histories [38].

Let H(ℓ) denote the immutable lifecycle history recorded up to ledger position ℓ, including lifecycle assertions, acceptance decisions, and conflict resolutions. The accepted product state at effective time τ, considering only the information available up to position ℓ, is defined as:

S(τ, ℓ) = Reconstruct(H(ℓ), τ),

(3)

where Reconstruct represents the state reconstruction function that evaluates recorded lifecycle events and their applicable acceptance decisions at the specified effective time, according to the consistency constraints of the proposed model.

The distinction between effective time and the ledger position used to reconstruct historical states is also related to established temporal database concepts, including the temporal features of SQL:2011 [28].

This representation supports two complementary forms of historical analysis. The trajectory of a product across its lifespan can be reconstructed by maintaining a constant value for ℓ while varying τ. Alternatively, keeping τ constant while varying ℓ reveals how the accepted interpretation of a particular historical moment changed as additional evidence and corrections became available.

Consider a motor initially installed in machine P1. Following removal and inspection, the motor is repaired and installed in machine P2. Throughout these events, the entity’s identity is preserved, whereas its specific placements in P1 and P2 are described by two separate containment intervals.

If a delayed assertion later challenges the recorded removal time, the system is required to preserve the original history while examining the effects of the proposed correction on subsequent intervals and lifecycle operations. It is imperative that the corrected interpretation does not result in overlapping placements or invalidate dependent transitions without explicit reconciliation.

Consequently, the model distinguishes the immutable sequence of recorded claims from the temporal configuration reconstructed from accepted decisions. This separation ensures that the provenance remains auditable, even as historical interpretations undergo modifications. The procedures governing delayed assertions and historical corrections are detailed in Section 2.3.3.

2.2.4. Causal Versioning and Event Dependencies

Temporal data by itself does not provide an adequate basis for determining relationships between lifecycle events generated independently by different organizations. Two events might share comparable effective timestamps despite lacking a causal link, whereas an event recorded later may have been generated without knowledge of an earlier committed update.

The proposed model uses vector-clock-based causal versioning to distinguish sequentially dependent lifecycle events from concurrent updates. Derived from Lamport’s happened-before relation [9], vector clocks represent causal dependencies and enable the identification of concurrent events [39]. Unlike blockchain transaction ordering, these relationships reflect the recorded dependencies between events generated by different organizations.

Each lifecycle event is associated with a vector clock V containing logical counters corresponding to the various actors that generate events. The vector records the causal knowledge represented by the event at the time of its generation.

Given two events e_i and e_j, their associated vectors V_i and V_j define a causal precedence relationship when:

V_i[k] ≤ V_j[k], ∀k,

(4)

and

V_i[k] < V_j[k], for at least one k.

(5)

Under these conditions, e_i causally precedes e_j, denoted by e_i ≺ e_j.

If neither vector dominates the other, the events are considered concurrent:

e_i ‖ e_j ⇔ ¬(e_i ≺ e_j) ∧ ¬(e_j ≺ e_i), i ≠ j.

(6)

Causal concurrency indicates that neither event was generated with awareness of the other. It does not inherently imply that the corresponding physical operations were executed simultaneously.

The inclusion of explicit parent-event references provides an additional representation of causal dependencies. In conjunction with vector clocks, they allow the model to identify the prior lifecycle information on which a participant based an assertion. The identifiers of the participants used by the version vectors must follow a consistent namespace, and version metadata must be validated against the declared causal parents. In the implemented prototype, each event identifies its causal predecessors through parentEventIds. The chaincode computes the vector clock by merging the clocks of accepted parent events with the submitting actor’s previous recorded clock, then incrementing that actor’s counter. Any client-supplied vector clock must match the computed value. Cross-organizational dependencies are therefore represented through explicit event references rather than inferred from timestamps or Fabric transaction ordering.

Causal relationships are not confined to events associated with the same DPP. A component might transition between different products, while multiple organizations independently submit information regarding its status or location. Accordingly, causal dependencies and references to affected resources must remain meaningful across the passports sharing that component’s history.

Importantly, causal concurrency does not automatically imply inconsistency.

To illustrate, the inspection of a specific motor and the maintenance of a separate component might be represented by concurrent events whose effects are compatible. Both assertions are eligible for inclusion in the accepted state, assuming that the applicable authorization and lifecycle constraints are satisfied.

On the other hand, two organizations may independently assert that the same motor was installed in different machines during overlapping periods. While these events may belong to different DPPs, they concern an identical tangible asset and depict contradictory placements.

To define these scenarios, let R(e) represent the set of physical or logical resources affected by event e, including any resources required by the applicable consistency rules. Furthermore, let Compatible(e_i, e_j) signify whether the combined effects of two events can satisfy those rules, and Overlap(R(e_i), R(e_j)) indicates a non-empty intersection between the affected resource sets.

Let C(e_i, e_j) denote a Boolean function indicating whether two lifecycle events are in causal semantic conflict. The function is defined as:

C(e_i, e_j) = (e_i ‖ e_j) ∧ Overlap(R(e_i), R(e_j)) ∧ ¬Compatible(e_i, e_j).

(7)

This definition separates the identification of concurrent updates from the assessment of their lifecycle consequences.

Figure 2 illustrates a case in which two causally concurrent lifecycle events describe incompatible placements of the same physical component. Although the events originate from independent organizations, their overlapping containment intervals would allocate the component to two separate hosts simultaneously, violating the requirement of exclusive component placement.

Figure 2. Causal concurrency and temporal containment conflict: (a) Independent lifecycle event branches; (b) Incompatible component placements over overlapping effective-time intervals.

Events impacting overlapping resources are not necessarily incompatible. For example, independent inspection reports may coexist, while alternative replacements of the same component in the same slot may require an explicit resolution.

Furthermore, violations of lifecycle constraints extend beyond causally concurrent events. Delayed assertions, invalid transitions, and rectifications can similarly clash with an already accepted temporal history. Such situations are assessed against the same structural and lifecycle requirements, even when the causal concurrency condition does not apply.

The procedures for conflict classification, resolution, and reconciliation are presented in Section 2.3.

2.2.5. Lifecycle Invariants and State Consistency

A distributed DPP can encompass multiple assertions describing different perspectives on a product’s lifecycle. Although all properly recorded assertions remain available as evidence, the accepted operational state is derived only from consistent subsets of records.

To maintain this distinction, the proposed model defines seven core invariants governing identity, physical composition, lifecycle eligibility, historical accountability, and operation consistency. These invariants are summarized in Table 2 and further discussed below.

Table 2. Core invariants of the unified lifecycle model.

Rule	Invariant	Constraint
I1	Digital identifier uniqueness	Each asset has a unique ledger identifier, and duplicate registration of an existing identifier is prohibited.
I2	Exclusive direct host	At any effective time, a component has at most one accepted direct host.
I3	Exclusive slot occupancy	A single-capacity host slot cannot contain multiple accepted components at the same effective time.
I4	Acyclic composition	The accepted containment hierarchy cannot contain direct or indirect cycles at any effective time.
I5	Eligible transition	Lifecycle operations must satisfy the applicable condition, inspection, authorization, and transition requirements.
I6	Historical accountability	Corrections and conflict resolutions must preserve the original assertions and earlier acceptance decisions.
I7	Retry consistency	The same operation identifier cannot produce different accepted business effects.

Invariant I1 ensures digital identifier uniqueness within the ledger by preventing duplicate registration of existing asset IDs. Physical identity verification is a separate responsibility of consortium-governed registration procedures. The ledger cannot independently determine whether two different identifiers refer to the same physical object.

Invariants I2 and I3 regulate physical placement. For any valid historical reading and at any given moment, a component is restricted to a single host association; conversely, each single-capacity installation slot may contain at most one component. These constraints apply across DPP boundaries whenever the same registered asset participates in multiple product lifecycles.

Invariant I4 requires the structural hierarchy to remain acyclic. Consequently, a valid composition forms a directed acyclic graph, preventing an asset from becoming its own descendant through a chain of accepted containment relations.

Invariant I5 manages the eligibility of lifecycle transitions. For instance, installing a component may require a valid inspection and an operational condition authorizing the reuse. A retired asset cannot return to active service via a standard transition unless the applicable policy explicitly allows a formal correction of its previous status.

Invariant I6 guarantees that changes in the analysis of historical events do not erase their provenance. A conflict resolution records an explicit verdict of existing acceptance or rejection decisions without changing the accepted product state. The original assertions, decisions, and subsequent resolution records remain available.

Finally, invariant I7 establishes idempotent behavior for repeated submissions. Any request reusing an existing operation identifier must match the previously recorded serialized event; otherwise, it is rejected. This rule is especially relevant when transaction submissions are retried following network disruptions or delayed confirmations.

Together, these invariants define the admissible operational states of the system.

The most important consistency requirement is that every reconstructed accepted state S(τ, ℓ) must adhere to the relevant identity, structural, and lifecycle constraints (I1–I5), concurrently ensuring that historical accountability and retry consistency are maintained through invariants I6 and I7. These requirements apply to both recently accepted transitions and historical states rebuilt after authorized corrections.

This does not imply that all submitted lifecycle assertions are valid. Contradictory claims may be recorded with REJECTED decisions, while associated conflict records can remain PENDING until explicitly resolved.

Preserving these constraints in the presence of concurrent updates requires transaction-level coordination over shared physical assets. Within the proposed implementation, guards for components, slots, and topologies provide the versioned state essential for identifying competing modifications. These mechanisms complement causal conflict detection rather than replacing it; specifically, vector clocks identify independent histories, semantic rules establish compatibility, and transactional validation safeguards the accepted state against incompatible concurrent commits.

The enforcement protocols and concurrency-control methods are described in Section 2.3, whereas their implementation within Hyperledger Fabric is detailed in Section 2.4.

The consistency guarantees depend on the system assumptions and trust model established in Section 2.1. They apply to the accepted digital history within the governed ledger domain and do not verify the objective truth or completeness of physical-world events.

2.3. Conflict Detection and Resolution

2.3.1. Semantic Conflict Classification

The proposed approach separates causal relationships from semantic compatibility. While causal metadata identifies if events are ordered or concurrent, semantic checks assess effects on physical assets, containment intervals, lifecycle stats, and Section 2.2.5 constraints. Equation (7) identifies incompatibility between causally concurrent events targeting the same assets. Different violations, such as delayed assertions or invalid lifecycle transitions, are assessed separately.

Four main categories of conflicts are considered:

• Structural conflicts occur if operations violate the accepted physical composition, such as assigning one component to two hosts simultaneously, placing multiple components in single-capacity slots, or introducing containment hierarchy cycles. These relate to invariants I2–I4.
• Temporal conflicts happen when lifecycle assertions contradict the accepted history’s timing. For instance, delayed installation records might overlap subsequently accepted placements or require adjusting subsequent containment periods. These may require manual fixes rather than automatic overwrites.
• Lifecycle transition conflicts involve operations violating asset states, inspection requirements, or authorization policies. Examples include installing quarantined components or reactivating retired assets without authorized corrections. These situations are mainly governed by invariant I5.
• Causal dependency conflicts arise from events referring to missing predecessors or events providing causal metadata that cannot be reconciled with the recorded event history. Missing dependencies halt immediate evaluation, while invalid or inconsistent dependencies trigger rejection. For causally concurrent events, compatibility depends on structural, temporal, and lifecycle rules, not just on concurrency.

These categories describe complementary validations and are not necessarily mutually exclusive. A single conflicting installation can involve causal concurrency, overlapping effective-time intervals, and structural violations simultaneously. Therefore, classification identifies both event relationships and the constraints affected by the proposed operations.

Authorization, identity registration, and operation-id reuse are treated as additional checks rather than independent physical conflict categories. I1 and consortium registration policy govern identity uniqueness, whereas I7 prevents different event payloads from being accepted under the same operation identifier. According to I6, historical accountability ensures that all recorded assertions and decisions stay traceable, even if subsequent resolutions alter their operational effect.

Conflict classification does not always cause immediate rejection. Compatible assertions might be accepted, while deterministically invalid ones are dismissed. Unresolved conflicts may remain PENDING until an explicit resolution is submitted; rejected lifecycle assertions do not automatically become accepted. All accepted updates must maintain the applicable lifecycle invariants, and recorded assertions must remain auditable. This classification provides the following unified processing algorithm.

2.3.2. Unified Event Processing Algorithm

The proposed algorithm combines causal validation, time-based provenance, semantic conflict detection, and lifecycle consistency enforcement into one event-handling flow. It evaluates if a new lifecycle assertion can update the current DPP state while adhering to the constraints established in Section 2.2.

Processing begins at the application gateway, where basic authentication and structural validation are performed. Requests with incomplete data, malformed IDs, or insufficient permissions are rejected immediately, before lifecycle recording. For valid requests, the transaction layer executes the validation process using a consistent ledger view. Crucially, security and integrity audits also occur within the secure transaction-validation boundary instead of only at the gateway level.

The first ledger-level operation addresses retry consistency. Each event contains an operationId used as a ledger-wide idempotency key. For repeated submissions, the chaincode deserializes the JSON payload and compares its serialized representation with the previously recorded event, restoring the stored vector clock when omitted from the retry. Serialization uses ISO-8601 timestamps, excludes null and empty fields, and orders map entries by key. Collection order is preserved rather than normalized. Identical representations return the previous decision, while mismatches are rejected. This mechanism does not implement cryptographic hashing or full semantic canonicalization.

When encountering a new operation, the algorithm verifies the event’s causal predecessor and version metadata. Causal predecessors must exist and have accepted decisions. Missing predecessors or invalid causal metadata cause submission errors without recording the proposed event. Such requests are not automatically queued for later processing. If the dependency information is valid, Equation (7) is used to detect events that are causally concurrent with the submitted assertion and assess potential overlaps in their semantic effects or affected resources.

The algorithm checks temporal data against the accepted containment history and the applicable lifecycle-transition protocols. It identifies the specific slots, hosts, and assets affected by the proposed operation, fetching their historical intervals and current state. To ensure an earlier assertion does not quietly nullify a later accepted configuration, both the proposed effective time and any subsequent confirmed transitions are validated.

When an assertion relies on obsolete product information, the chaincode verifies its causal dependencies and evaluates the proposed operation against the accepted state and applicable lifecycle constraints. Incompatible operations cannot modify the accepted configuration, while invalid dependencies prevent transaction processing. Incorrect historical timestamps can be addressed through explicit correction events, provided that the resulting history remains consistent.

Standard lifecycle changes are accepted immediately only when meeting consistency requirements and the applicable effective-time watermarks. Retroactive changes are processed through explicit CORRECT events, which are validated against the accepted history and produce ACCEPTED or REJECTED decisions. Section 2.3.3 details the correction procedure used to manage these specific reassessments.

Then, the algorithm assesses proposed operational effects relative to invariants I1–I5. Structural checks confirm unique component placement, slot occupancy, and non-circular containment. Lifecycle reviews verify the component’s eligibility, relevant inspection evidence, and valid state transitions. Compatible concurrent operations are approved if their merged effects maintain these rules. Otherwise, incompatible assertions are categorized according to Section 2.3.1 and assigned a decision reflecting their semantic status.

Lifecycle events receive ACCEPTED or REJECTED decisions, while unresolved conflicts are stored separately with PENDING status. Missing causal dependencies produce processing errors without persisting the event. Only accepted effects contribute to the reconstructed state defined in Equation (3).

While Figure 3 shows the processing workflow, Algorithm 1 presents its main validation steps.

Algorithm 1. Unified lifecycle event processing

Input: Lifecycle event e, ledger state H, governance policy P Output: ACCEPTED, REJECTED, or processing error 1: Phase 1: Gateway admission 2: Validate authentication, authorization, and request format 3: if request is inadmissible then return processing error 4: Phase 2: Chaincode validation and state updates 5: k ← e.opId 6: if OperationIndex[k] exists then 7:     previous ← LoadStoredEvent(OperationIndex[k]) 8:     if e.V is absent then e.V ← previous.V 9:     if Serialize(previous) = Serialize(e) then return previous decision 10:     else return operation-identifier reuse error 11: end if 12: Validate causal predecessors and version metadata 13: if predecessors are missing or causal metadata is invalid then 14:     return processing error 15: end if 16: A ← IdentifyAffectedResources(e) 17: Read accepted history, state, and guard keys for A 18: C ← DetectCausalAndSemanticConflicts(e, H) 19: if C contains incompatible events then 20:     Stage conflict record with status PENDING 21:     decision ← REJECTED(SEMANTIC_CONFLICT) 22: else 23:     if e.type = CORRECT then 24:         Validate correction against accepted history 25:     else 26:         S’ ← ApplyTentatively(e, accepted state) 27:         Validate S’ over affected effective-time intervals 28:     end if 29:     if I1–I5 hold then 30:         decision ← ACCEPTED 31:     else 32:         decision ← REJECTED(INVALID_LIFECYCLE_EFFECT) 33:     end if 34: end if 35: Atomically record assertion, decision, operation ID, and conflict 36: if decision = ACCEPTED then 37:     Update accepted state and relevant guard keys 38: end if 39: Phase 3: Client/Gateway commit handling 40: if endorsement fails then return endorsement error 41: Submit endorsed transaction through Fabric Gateway 42: Wait for Fabric commit confirmation 43: if commit status = VALID then 44:     return committed lifecycle decision 45: else 46:     return commit error 47: end if

Figure 3. Unified lifecycle event processing workflow showing gateway admission, chaincode validation, and commit confirmation.

The algorithm separates gateway admission, chaincode execution during endorsement, and client-side transaction submission. Chaincode evaluates lifecycle constraints and produces the proposed state changes, while Fabric Gateway handles submission and commit confirmation. Failed transactions do not automatically trigger resubmission; any subsequent attempt requires a new client request.

Successful ledger transactions atomically record operation-identifier data, lifecycle assertions, and acceptance decisions. While accepted operations update concurrency guard keys and the relevant materialized state, rejected assertions and pending conflict records leave the physical configuration unchanged. Invariant I6 is maintained by preserving all prior assertions and decisions, even those later superseded by authorized corrections.

A successful endorsement does not guarantee that an accepted effect has been committed. During the Hyperledger Fabric validation, concurrent transactions may read the same states and compete [10,11]. Transaction validation failures nullify all proposed writes, requiring re-evaluation of the operation against the updated states before resubmitting. These infrastructure-level errors differ from committed semantic decisions. Thus, definitive lifecycle outcomes received by the clients require successful transaction commitment.

2.3.3. Conflict Resolution and Historical Corrections

Lifecycle event processing manages identified conflicts without deleting or overwriting original assertions. Every unresolved conflict is documented in a record referencing the affected events, their causal relationships, violated constraints, and current resolution status. This distinction protects submitted data while blocking incompatible operations from altering the accepted DPP state.

Conflict resolution involves predefined deterministic policies or an authorized decision. Deterministic resolution is appropriate when the consortium has established clear guidelines, such as rejecting an installation that violates a mandatory eligibility requirement. Conversely, clashing assertions about physical operations may need additional evidence or mediation by an authorized participant. Ledger commitment order alone is not used to determine which competing physical claim is correct.

A resolution specifies the involved assertions, the applicable policy or responsible actor, and the final decisions. Compatible events may remain effective at the same time, whereas contradictory ones cannot result in an accepted state that violates the lifecycle invariants. The resolution is recorded as a new immutable entry, saving both the original assertions and the justification of the decision. This approach adheres to the principle of maintaining traceable provenance [24,25]. In the current prototype, conflict resolution confirms existing acceptance decisions and closes the conflict record without modifying the accepted product state.

Historical corrections require additional validation because their effects may extend beyond the event being corrected. Consequently, assertions dated before the current accepted transition watermark are not automatically integrated into the operational state. Instead, the correction process maps impacted containment intervals, lifecycle transitions, and linked records. The proposed modification is evaluated against the reconstructed history, including subsequent accepted operations.

Authorization requires the correction to meet invariants I1–I5 across all affected effective-time intervals. If later operations are compromised by the modification, these dependencies require resolution before the corrected state becomes effective. To satisfy invariant I6, earlier assertions and decisions are preserved while new resolution records track superseded effects.

Separating effective time from ledger position allows historical queries to reconstruct both the state previously recognized by the consortium and the state established after a correction. Thus, the Equation (3) reconstruction function can return different accepted interpretations for one effective time when evaluated at different ledger positions, without modifying the underlying immutable history.

To prevent partially applied corrections, the transition to a new revised accepted state must be atomic from the perspective of lifecycle queries. Consequently, multi-record corrections may require coordinated validation and activation rather than independent updates. The corresponding transaction-level concurrency mechanisms are detailed in the next section.

2.3.4. Concurrency Control and Guard Mechanisms

Maintaining lifecycle invariants during simultaneous asset modifications requires transaction-level coordination. Traditional concurrency controls identify competing modifications [40], and Hyperledger Fabric implements optimistic validation via read-write sets [10,11]. During endorsement, chaincode generates a read set containing the versions of accessed state keys. Fabric confirms these versions remain valid before commitment; otherwise, transactions based on outdated versions are rejected without altering the state.

The proposed design introduces explicit guard keys for physical components and host slots. These guards are versioned ledger keys rather than explicit locks. By creating shared read-write dependencies, they allow Fabric’s MVCC validation to invalidate competing transactions that attempt incompatible modifications. Placement operations read and update these guards, forcing conflicting transactions to access common versioned state. Component guards ensure exclusive placement (I2), while slot guards prevent multiple components from occupying the same single-capacity position (I3). If two conflicting transactions are endorsed, the first successful commit updates the guard version, triggering a validation failure for the competitor.

To maintain acyclic containment (I4), a shared topology guard is updated during structural changes. This prevents independent modifications from creating undetected cycles. Although this conservative approach ensures consistency, the shared guard might restrict scalability by increasing contention during high-concurrency workloads.

Component replacement is performed through separate REMOVE and INSTALL operations. Each operation validates the applicable lifecycle and consistency constraints within its own Fabric transaction. Individual transactions are atomic, but replacement as a whole is not atomic across both operations.

Consistency checks do not rely solely on rich queries, which lack Hyperledger Fabric’s phantom-read protection. Instead, explicit guard keys create version dependencies to block competing state modifications. Multi-asset historical corrections also demand coordinated validation; those spanning multiple transactions require controlled activation protocols to avoid intermediate state inconsistency.

Transactions failing multiversion concurrency control (MVCC) validation do not commit [41]. Applications must fetch current data and re-evaluate lifecycle rules before resubmitting. Using operation IDs enforced across actors and serialized event comparisons (I7), the system avoids duplicate effects while distinguishing transient infrastructure conflicts from committed semantic rejection decisions.

Consistency guarantees depend on all state-changing operations following the same guard protocol. Under these conditions, the combination of lifecycle invariants, atomic state transitions, and Fabric validation prevents concurrent transactions from committing incompatible component placements. Section 2.5 describes the contention and idempotent retransmission experiments.

2.4. System Architecture and Implementation

The proposed architecture implements the unified temporal and causal lifecycle model within a permissioned Hyperledger Fabric environment. It decouples participant interaction, lifecycle validation, data storage, and record retrieval, yet preserves a unified consistency boundary for physical asset activities. This structure aligns with earlier DPP models [42] that segregate data collection, management, and use across lifecycle stakeholders. Figure 4 depicts the architectural components and their interactions.

Figure 4. Overall architecture of the proposed distributed DPP lifecycle management system, illustrating participant interaction, application services, chaincode-based consistency enforcement, blockchain storage, and historical query support.

The Application Layer, developed with Java and Spring Boot, exposes RESTful interfaces for authorized entities to register assets, submit events, seek conflict resolution, and access DPP data. Using the Fabric Gateway API to communicate with the blockchain [43], this layer manages authentication and initial request validation. While a previous study [44] highlights the necessity of trust and controlled information exchange among supply-chain actors, final lifecycle determinations remain outside this layer’s authority.

The Lifecycle and Conflict Management Layer utilizes Java chaincode deployed on the Hyperledger Fabric network [10] to run the Algorithm 1 validation protocol. This includes verifying causal dependency, temporal consistency logic, and semantic conflicts while upholding lifecycle invariants. Accepted operations update the product state, while rejected assertions and unresolved conflict records do not alter the accepted physical configuration. Atomic transactions and concurrency guards stop concurrent, incompatible updates.

The Ledger and State Storage Layer stores lifecycle assertions, acceptance decisions, conflict resolutions, persistent asset records, and containment relationships. The blockchain ledger records a chronological sequence of committed transactions, whereas the world-state database allows rapid querying of active records for validation. The separation between immutable history and accepted operational state enables historical reconstruction without overwriting earlier assertions. Hyperledger Fabric enables state record retrieval via deterministic keys, maintaining transaction history separately from world-state changes [45]. CouchDB can be configured as the world-state database. While CouchDB supports JSON-based indexing and querying, critical consistency operations should rely on explicit state-key access and concurrency guards instead of relying solely on rich queries [46].

2.5. Experimental Setup and Methodology

The experimental evaluation is designed to assess the functional correctness, transaction performance, and scalability of the proposed temporal and causal lifecycle model. The test environment is composed of a Hyperledger Fabric 2.5 network, featuring two organizations with single peers, one EtcdRaft ordering service, and CouchDB as the world-state DB. The smart contract (chaincode) is written in Java. The Spring Boot API interacts with the chaincode via Fabric Gateway. Fabric’s peer event services provide transaction validation notifications [47], while Baliga et al. [48] experimentally characterized Fabric throughput and latency, and Sukhwani et al. [49] modeled performance bottlenecks in endorsement, ordering, and validation. For reproducibility, all hardware, software, endorsement policy, ordering parameters, and network configurations remain consistent across all experiments.

The experimental platform ran on an Intel Core i7-8565U CPU (4 cores, 8 threads; Intel Corporation, Santa Clara, CA, USA), with 16 GB RAM and a 512 GB SSD, under Ubuntu 24.04.4 (Canonical Group Limited, London, UK). The software stack included Hyperledger Fabric 2.5.16 (LF Decentralized Trust, Linux Foundation, Wilmington, DE, USA), Apache CouchDB 3.4.2 and Apache JMeter 5.6.2 (Apache Software Foundation, Wilmington, DE, USA), OpenJDK 21.0.12.1 (Ubuntu distribution; Canonical Group Limited, London, UK), and Spring Boot 3.5.16 (Spring project, Broadcom Inc., Palo Alto, CA, USA). The blockchain network, application server, and workload generator ran on the same machine.

The experimental evaluation focuses on the implemented unified model, which combines temporal provenance, causal versioning, semantic conflict management, and structural consistency constraints. While enforcing invariants I1–I7, the system is evaluated under different workloads using identical blockchain architectures and application interfaces. Performance analysis and the lifecycle consistency checks are performed, as accepting an invalid lifecycle operation is not equivalent to successful validation.

Functional tests involve an industrial motor’s removal, inspection, repair, and reuse across different hosts. Additional cases include concurrent updates, conflicting installations, cyclic containment, and invalid transitions or dependencies. The expected accepted state and historical provenance are verified after transaction commitment. Functional API testing was conducted via Swagger UI, using REST endpoints documented according to the OpenAPI specification [50].

Apache JMeter [51] was used to generate separate workloads for CREATE, UPDATE, GET, INSTALL, and historical reconstruction operations. For CREATE, UPDATE, and GET, 60-s run evaluations involved 1, 10, 50, 100, 200, and 300 concurrent clients. INSTALL operations were tested using synchronized bursts of 10, 50, 100, 200, and 300 requests. Further experiments analyzed competing installations targeting the same slots or components. Conflict-rate tests used bursts of 100 synchronized INSTALL requests with 5, 10, and 20 competing same-slot pairs, targeting 5%, 10%, and 20% conflict rates. These workloads distinguish uncontended transaction processing from resource contention and follow established blockchain benchmarking approaches [52].

Performance metrics include end-to-end response latency, mean and 95th-percentile response times, throughput, Fabric validation errors, and semantic acceptance outcomes. The study categorizes outcomes into successful transactions, semantic rejections, MVCC validation conflicts, and endorsement failures. To ensure measurement accuracy, automated retries were deactivated. Additionally, an idempotency experiment examined sequential and concurrent retransmissions, specifically testing operation ID reuse with modified payloads. A consistent experimental environment was maintained throughout all tests to minimize configuration-related variability [53]. Finally, throughput measurements distinguish sustained workloads from synchronized transaction bursts, adhering to established blockchain testing protocols [54].

Historical query performance was evaluated through direct asset retrieval and temporal state reconstruction. These tests used DPPs featuring 3, 10, 25, and 50 accepted INSTALL events, executing queries at various effective times. Every reconstruction query employed asOfPosition = 0 to reflect the latest accepted ledger state. Further tests analyzed reconstruction using one and ten concurrent clients following the setup of 50 DPPs, each containing ten installation events. Selected tests reused existing fixtures to limit changes in the underlying data. Because reconstruction tracks the full event history, cumulative ledger growth was considered when interpreting the results. Setup details and metrics were archived in JTL, CSV, and JSON formats for later review.

A complementary baseline experiment isolates the performance impact of causal versioning and causal-frontier analysis while preserving the remaining validation mechanisms. Both configurations are evaluated under identical INSTALL workloads with repeated measurements.

3. Results

3.1. Functional Validation

Three stages of functional validation were conducted. Initially, direct chaincode tests confirmed CRUD operations, lifecycle transitions, temporal consistency constraints, and conflict detection and resolution. Next, an automated end-to-end suite tested the complete REST API–Fabric Gateway–chaincode interaction, producing expected results across all 56 test cases. Lastly, manual checks via Swagger UI verified API requests, responses, and reconstructed product states.

The tests covered an industrial motor lifecycle involving installation, removal, inspection, repair, and subsequent reuse in another product. Additional tests addressed historical corrections, structural conflicts, and their resolutions. The results confirmed that component identity and provenance were preserved across lifecycle transitions. Invalid operations were rejected, and temporal consistency constraints were enforced.

The 56 end-to-end test cases covered asset registration, lifecycle operations, conflict handling, and historical reconstruction. Persistent component identification and transfer between different products addressed I1 and I2, while rejected installations into occupied slots verified I3. Inspection, repair, and reuse scenarios evaluated lifecycle eligibility (I5), whereas conflict resolution and historical corrections examined the preservation of recorded assertions and decisions (I6). Acyclic containment (I4) and retry consistency (I7) were addressed through separate chaincode test scenarios and idempotency experiments, respectively. The evaluation provides scenario-based coverage rather than exhaustive verification of all possible lifecycle states and concurrent operations.

3.2. Concurrency Testing

Concurrency tests were performed to assess structural constraint enforcement and simultaneous lifecycle operations. Two clients submitted simultaneous INSTALL events. Two scenarios were considered: competing installations in the same host slot and independent installations in different slots. The tests were executed after recording a historical correction to activate temporal consistency validation.

For same-slot attempts, one installation succeeded while the other encountered an MVCC_READ_CONFLICT and was rejected. State reconstruction verified that the structural consistency was preserved, showing only one component in the slot.

In the second scenario, the initial implementation produced a PHANTOM_READ_CONFLICT. Although a retry succeeded, historical validation created false contention. Following chaincode optimizations to avoid global history scans for independent installations, both transactions succeeded without retries. State reconstruction confirmed two active containment intervals in distinct slots. An MVCC_READ_CONFLICT occurs when a transaction attempts to commit using a state-key version that has been modified by another committed transaction. A PHANTOM_READ_CONFLICT occurs when concurrent updates change the results of a range query evaluated during endorsement; in this case, global history scans introduced unnecessary dependencies between otherwise independent installations.

3.3. Performance and Scalability Evaluation

This section reports the measured behavior of the implemented unified DPP prototype under sustained transaction workloads, synchronized installation bursts, temporal queries, and controlled contention. Measurements reflect REST API performance, including Fabric commit confirmation for state-changing operations and evaluation for reads, while omitting initial workload preparation. Sustained tests and single-burst experiments are presented separately because their completion rates describe different workload conditions.

3.3.1. Transaction Processing Performance

Performance assessments for CREATE, UPDATE, and direct GET operations were measured over 60-s, involving 1 to 300 concurrent clients. Table 3 details the observed throughput and 95th-percentile (p95) latency. While CREATE and UPDATE are commit-confirmed writes, GET operations used evaluation without committing a new transaction.

Table 3. Sustained CREATE, UPDATE, and GET performance across concurrent client counts.

Clients	CREATE (req/s)	UPDATE (req/s)	GET (req/s)	CREATE Mean/p95 (ms)	UPDATE Mean/p95 (ms)	GET Mean/p95 (ms)
1	1.64	1.74	239.39	597.8/663	563.2/584	3.8/5
10	16.35	16.32	1105.68	564.6/603	564.4/603	8.1/12
50	189.24	215.29	1191.10	241.8/495	211.8/341	38.1/54
100	277.36	275.74	1184.33	329.1/543	330.9/454	77.0/104
200	302.77	348.61	1210.98	601.7/1016	521.8/846	150.9/210
300	324.74	296.18	1210.65	840.0/1680	920.0/1269	226.6/324

Figure 5 separates write and read throughput due to their divergent scales.

Figure 5. Observed throughput for sustained workloads; (a) CREATE and UPDATE; (b) direct GET queries.

Figure 6 illustrates the variation in p95 response latency with increasing client concurrency, distinguishing commit-confirmed write operations from direct GET queries.

Figure 6. Independent vertical scales p95 response latency as a function of concurrent clients for: (a) commit-confirmed writes; (b) direct GET queries.

Table 4 summarizes the response latency and request completion rates for INSTALL operations under synchronized bursts of 10 to 300 concurrent requests.

Table 4. Measured INSTALL performance under synchronized request bursts.

Concurrent Requests	Mean Latency (ms)	p95 Latency (ms)	Burst Completion Rate (resp./s)
10	532.0	727	7.78
50	667.3	901	39.97
100	761.2	969	57.31
200	1895.6	2093	71.25
300	3445.4	3927	65.67

Figure 7 illustrates the response latency and request completion rate for INSTALL operations under increasing levels of concurrent requests.

Figure 7. Synchronized bursts of 10–300 requests; (a) INSTALL response latency; (b) observed request completion rate.

3.3.2. Historical Reconstruction Performance

Temporal reconstruction underwent testing for DPP histories containing 3, 10, 25, and 50 accepted INSTALL events. Each query reconstructed the accepted component configuration for a chosen effective time using asOfPosition = 0. In the current implementation, asOfPosition = 0 selects the latest committed ledger state, while the effective-time parameter determines the historical product configuration to reconstruct. Nonzero asOfPosition values are not supported by the chaincode. Reconstruction at earlier ledger positions would require an additional off-chain projection of committed transactions. Within the initial three-event setup, queries prior to the first installation, at an intermediate effective time, and following the last installation returned correct reconstructed states. These functional verifications remain separate from the performance comparison regarding history depths.

Average reconstruction latency for reused fixtures spanned 203.1 to 221.9 ms (see Table 5 and Figure 8). Increases in DPP-local history depth failed to produce monotonic growth in mean figures. Across 3-, 10-, 25-, and 50-event evaluations, successful matching queries totaled 277, 268, 288, and 263 respectively. These results reflect specific ledger and fixture conditions during testing.

Table 5. Temporal reconstruction results for existing DPP fixtures under a single-client 60-s workload.

Events per DPP	Successful Queries	Mean Latency (ms)	p95 Latency (ms)	Throughput (req/s)
3	277	211.3	336	4.62
10	268	218.2	370	4.47
25	288	203.1	231	4.80
50	263	221.9	402	4.38

Figure 8. Mean and p95 latency of temporal reconstruction for four DPP-local history depths using existing fixtures (one client).

In a separate concurrency experiment involving 50 DPPs and ten INSTALL events each, ten clients performed reconstruction queries (see Table 6 and Figure 9).

Table 6. Effective-time correctness checks and reconstruction diagnostics under expanded ledger conditions.

Condition	Clients	Successful Queries	Mean (ms)	p95 (ms)	Rate (req/s)
3 events: before	1	312	187.6	234	5.20
3 events: middle	1	315	185.6	222	5.26
3 events: end	1	307	190.5	279	5.11
Expanded ledger: 1 client	1	38	1562.3	1827	0.63
Expanded ledger: 10 clients	10	139	4135.0	4932	2.18

Figure 9. Ten-event single-client run and two subsequent runs on the expanded ledger; (a) temporal reconstruction mean latency; (b) and query completion rate.

Results showed a 4135.0 ms mean latency (p95: 4932 ms; 139 matching responses). Conversely, a single-client diagnostic on this identical ledger averaged 1562.3 ms (p95: 1827 ms; 38 matching responses). Both differed substantially from the earlier single-client ten-event fixture test, which averaged 218.2 ms. While the expanded-ledger tests contrast concurrency levels, the single-client tests differ in global ledger population. Because conditions were tested sequentially, these comparisons do not establish the isolated causal effects of concurrency and ledger size.

3.3.3. Performance Under Contention and Idempotent Retransmissions

Contention experiments used three synchronized bursts of 100 INSTALL requests. Workloads combined 5, 10, or 20 same-slot pairs with independent installations. The nominal rates of 5%, 10%, and 20% represent expected installation exclusions per 100 submissions, with two contested requests per pair. Table 7 and Figure 10 detail HTTP-level results. Fabric MVCC invalidations (HTTP 409) and endorsement failures (HTTP 422) are distinguished; both are excluded from accepted ledger counts.

Table 7. Outcomes and latency for the three 100-request contention bursts.

Planned Rate	Accepted (HTTP 201)	MVCC (HTTP 409)	ENDORSE (HTTP 422)	Mean (ms)	p95 (ms)	Burst Rate (resp./s)
5%	95	4	1	1085.7	1236	58.31
10%	90	6	4	1296.7	1717	57.97
20%	80	11	9	1112.6	1247	80.06

Figure 10. Disposition of 100 synchronized INSTALL submissions at planned conflict-exclusion rates of 5%, 10%, and 20%. Each burst contained an independent set of shared-slot pairs.

All independent installations succeeded, and every contested pair had exactly one accepted installation. Of 300 total requests, 265 were accepted, 14 were rejected during endorsement, and 21 were invalidated via MVCC. Ledger checks confirmed 95, 90, and 80 active placements per workload, aligning with accepted decisions and showing no duplicate slot or component IDs in the reconstructed state. The diagnostic reports retained an unverified-failure status for the endorsement exceptions; the observed structural consistency result is therefore distinct from a fully successful execution classification.

Across all HTTP responses, mean latency varied non-monotonically among the three single-burst workloads (Figure 11). Regarding accepted submissions, mean latency reached 1081.2, 1304.7, and 1140.8 ms for target rates of 5%, 10%, and 20%. Logged endorsement errors featured an ABORTED status, indicating inadequate endorsement totals, though specific chaincode-related causes remained unidentified.

Figure 11. Mean and p95 latency across all HTTP responses in synchronized contention bursts, including unsuccessful responses. These are single-burst measurements rather than repeated steady-state estimates.

Five requests were used to evaluate idempotency: an initial INSTALL, its identical sequential replay, a modified payload using the same operationId, and two concurrent submissions of another identical operation (Table 8). The initial request and sequential replay both returned HTTP 201 (ACCEPTED). The modified-payload request failed during endorsement (HTTP 422), although the available diagnostics did not establish the precise cause. Among the concurrent duplicates, one transaction committed successfully (HTTP 201), while the other was invalidated by Fabric’s MVCC mechanism (HTTP 409). Ledger inspection confirmed only one persisted event and acceptance decision per operation, without duplicate effects on the reconstructed states.

Table 8. Request-level outcomes in the idempotency and retransmission experiment.

Submission	HTTP Code	Observed Result	Latency (ms)
Initial INSTALL	201	ACCEPTED	626
Identical sequential replay	201	ACCEPTED	541
Reused ID, modified payload	422	ENDORSE failure	8
Concurrent replay A	409	MVCC invalidation	573
Concurrent replay B	201	ACCEPTED	573

3.3.4. Baseline Comparison

The impact of the unified causal consistency mechanisms on performance was assessed through a comparison experiment. The baseline configuration retained structural and temporal validation, MVCC protection, idempotency, and acceptance decisions, while excluding causal versioning and causal-frontier analysis. Both configurations used the same REST API and Hyperledger Fabric infrastructure.

For each configuration, synchronized INSTALL workloads with 100 and 200 concurrent clients were run three times, for a total of 12 runs. Between configurations, the ledger was reset, and different test data was utilized in subsequent runs. All 1800 transactions were successfully committed and accepted, without validation failures.

Table 9 presents the results, while Figure 12 compares mean latency and observed throughput. At 100 clients, Unified increased mean latency by 8.11% compared with Baseline. At 200 clients, the unified configuration exhibited lower mean latency, although the baseline configuration maintained slightly higher throughput at both concurrency levels.

Table 9. Performance comparison of Baseline and Unified configurations under synchronized INSTALL workloads.

Configuration	Clients	Mean Latency (ms)	SD (ms)	Mean p95 (ms)	Throughput (req/s)
Baseline	100	1363.67	1380.73	1579.33	52.27
Unified	100	1474.23	1454.51	1671.00	49.78
Baseline	200	1920.13	676.90	2129.00	81.60
Unified	200	1785.70	565.69	2017.33	77.12

SD represents the standard deviation of mean latency across three runs. Mean p95 is the average of run-level 95th percentiles. Throughput represents the observed burst completion rate.

Figure 12. Baseline and Unified performance under synchronized INSTALL workloads; (a) mean response latency; (b) observed request completion rate.

The results indicate no consistent latency penalty from the additional causal mechanisms. However, substantial between-run variability limits the precision of the comparison. The experiment characterizes their performance impact under controlled single-machine conditions rather than establishing performance advantages in distributed deployments.

4. Discussion

The proposed model addresses a fundamental limitation of blockchain-based lifecycle records: transaction ordering alone does not establish the temporal and causal consistency of product histories. The model allows product composition to be reconstructed without discarding earlier installations, removals, or corrections by separating persistent component identities, lifecycle assertions, and acceptance decisions. Causal dependencies describe its relationship to other recorded events. On the other hand, effective time describes when a lifecycle assertion applies. While functional validation shows the system maintains provenance and structural and temporal constraints during repair and reuse cycles, these guarantees ensure recorded information consistency rather than physical truth. Compared with the approaches summarized in Table 1, the proposed model combines temporal, causal, and structural validation within a single event acceptance procedure, although its robustness has not been directly benchmarked against other implementations.

The concurrency experiments provide further evidence that structural consistency can be maintained when independent actors submit overlapping lifecycle operations. Using Fabric’s MVCC and guard keys, the system prevents incompatible states resulting from conflicting transactions, while independent operations can proceed without unnecessary contention in the tested scenarios. Experiments highlighted that MVCC invalidates conflicting transactions before commitment, whereas semantic rejections are recorded as explicit decisions within successful transactions. Endorsement errors represent a third, distinct failure type. While idempotency tests prevented duplicate effects from retransmissions, the specific origin of modified-payload endorsement failures could not be established. The observed MVCC invalidations are consistent with the transaction failure mechanisms analyzed by Chacko et al. [11], while direct throughput comparisons with Fabric benchmarks [31] are limited by differences in deployment configurations and workloads.

The performance results show that the prototype handles concurrent lifecycle operations while maintaining required consistency. State-changing transactions—burdened by endorsement, ordering, and validation—showed lower throughput than direct GET requests. Higher concurrency improved write throughput up to the ranges observed in the experiments, but higher client numbers also increased latency. This trade-off was also seen in high-load synchronized INSTALL bursts. These findings reflect the overall system’s performance. The additional baseline experiment provides an initial assessment of the performance impact of causal versioning and causal-frontier analysis. No consistent latency penalty was observed, although substantial between-run variability limits the interpretation of the measured differences.

Historical reconstruction presents a more substantial scalability concern. While latency did not rise linearly for individual DPP histories of 3 to 50 events during controlled tests, reconstruction slowed significantly as the global ledger’s history expanded. This stems from the current system processing the entire global history to reconstruct product states. Although ledger size is not the only confirmed factor, historical retrieval requires optimization. Implementing per-product indexing, incremental materialized views, or off-chain projections of committed lifecycle events could reduce redundant processing and enable historical ledger position queries currently unsupported by the asOfPosition = 0 interface.

Several limitations constrain the generalization of these findings. All experiments were performed on a single computer rather than a physically distributed consortium network. While the baseline comparison included three repetitions per configuration and concurrency level, the remaining performance measurements were based on single runs. Synchronized conflict tests did not measure sustained throughput under continuous contention, and the available endorsement diagnostics did not explain all submission failures. Furthermore, the baseline comparison was limited to selected causal consistency mechanisms and INSTALL workloads, while validation with real industrial data remains for future work.

Practical deployments also require consortium governance mechanisms for resolving disputes over asset registration and policy enforcement. Large-scale physical identity verification may require delegated responsibilities or external certification, since the blockchain cannot independently verify physical assets. Furthermore, policy evolution requires coordinated updates and versioned rules to preserve the interpretation of historical decisions.

5. Conclusions

This paper introduced an integrated model for temporal provenance, causal versioning, and conflict resolution in distributed DPPs. Through the integration of persistent component IDs, effective-time containment relationships, causal relationships, and defined acceptance decisions, the model preserves lifecycle histories across repair and reuse operations while enforcing structural and temporal consistency constraints.

Implemented with Hyperledger Fabric, the prototype underwent functional, concurrency, and performance testing. These evaluations verified correct lifecycle state reconstruction, consistent management of competing operations, and the prevention of duplicate effects during the tested idempotency scenarios. Performance measurements demonstrated the prototype’s ability to process concurrent transactions while revealing differences between direct queries and commit-confirmed operations. Furthermore, reconstructing histories exhibited increased latency as the global ledger expanded, identifying an important scalability limitation.

The evaluation was conducted on a single-machine setup, while the baseline comparison was limited to selected causal consistency mechanisms and INSTALL workloads. Future work will target indexed history reconstruction, ledger-position-aware queries, and validation on distributed infrastructure using larger industrial datasets. Overall, the findings demonstrate the feasibility of integrating temporal and causal consistency mechanisms into blockchain-based DPP systems while identifying the architectural improvements required for broader deployment.