A Modular, Logistics-Centric Digital Twin Framework for Construction: From Concept to Prototype

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

This paper presents the ConLogTwin framework, a modular digital twin system designed for construction logistics management. The authors employ a design science research methodology to develop a technical architecture that integrates planning data with real-time site data through structured storage and automated services. 
While the paper addresses an important problem in construction digitalization, several limitations undermine its contribution.
1. The paper's most critical weakness is the absence of real-world validation. The authors acknowledge this limitation themselves, stating that "the framework has not yet been validated in a full-scale field study" (line 13). For a framework claiming to address practical construction logistics challenges, the lack of empirical testing severely limits the credibility of performance claims. The demonstrative implementation appears to be a basic proof-of-concept rather than a robust system tested under realistic conditions.
2. The technical architecture largely combines existing technologies (MongoDB, Docker, FastAPI, MQTT) without significant innovation. The authors acknowledge that "the underlying technology itself is not new" (line 666). The primary contribution appears to be a specific data model for construction logistics, but this model's advantages over existing approaches are not convincingly demonstrated through comparative analysis or performance metrics.
3. The paper provides no concrete evidence for claimed benefits such as "reducing costs and improving coordination" (line 11). Without cost-benefit analysis, performance benchmarks, or comparative studies, these claims remain unsubstantiated. The economic feasibility of maintaining the proposed infrastructure is not addressed.
4. The five-entity data model (project, building, component, package, delivery) appears overly simplistic for the complexity of construction logistics. The paper doesn't address how this model would handle: multi-phase projects with evolving requirements; complex dependencies between deliveries and work sequences; integration with existing enterprise systems; scalability across different project types and sizes.
5. The paper mentions "strong security mechanisms" (line 293) as requirements but provides minimal detail on implementation. Given the sensitive nature of construction project data and the multi-stakeholder environment, this represents a significant oversight.
6. The three scenarios presented (Section 7.2) are overly simplistic and don't reflect the complexity of real construction logistics challenges. More sophisticated scenarios involving multiple simultaneous disruptions, conflicting stakeholder priorities, or system failures would better test the framework's robustness.
7. The paper does not present any actual results for the scenarios described in Section 7.2. The three scenarios mentioned (pages 19-20, lines 641-647) are presented as brief conceptual descriptions without any implementation, testing, or results
The authors conclude these scenarios "illustrate how the modular and service-oriented architecture enhances resilience and decision support" (lines 648-649), but this conclusion is unsupported by any actual data, measurements, or demonstrated functionality.
This represents a significant methodological flaw. The scenarios are presented as part of the "Evaluation of the ConLogTwin" section, yet they provide no empirical evidence, performance metrics, or even simulated results. They read more like hypothetical use cases or requirements specifications rather than evaluation results. This absence of results reinforces my earlier critique about the lack of validation. The paper presents what the system is designed to do rather than demonstrating what it actually accomplishes, which undermines the credibility of the evaluation section and the overall contribution of the work.

Author Response

Comment 1: The paper's most critical weakness is the absence of real-world validation. The authors acknowledge this limitation themselves, stating that "the framework has not yet been validated in a full-scale field study" (line 13). For a framework claiming to address practical construction logistics challenges, the lack of empirical testing severely limits the credibility of performance claims. The demonstrative implementation appears to be a basic proof-of-concept rather than a robust system tested under realistic conditions.

Response 1: We agree that a field study would provide valuable validation. However, this paper is explicitly positioned as a reference architecture with a demonstrative prototype, rather than a full proof-of-concept or deployed system. A large-scale field evaluation is out of scope for this contribution but is planned as future research. We have clarified this positioning in the abstract, introduction, and evaluation sections to avoid misinterpretation.

Comment 2: The technical architecture largely combines existing technologies (MongoDB, Docker, FastAPI, MQTT) without significant innovation. The authors acknowledge that "the underlying technology itself is not new" (line 666). The primary contribution appears to be a specific data model for construction logistics, but this model's advantages over existing approaches are not convincingly demonstrated through comparative analysis or performance metrics.

Response 2: We agree that the underlying technologies are established. We view this as a strength, as it enhances practical applicability and reduces implementation barriers. The scientific contribution lies in the modular integration of these technologies into a coherent reference architecture tailored for construction logistics. To emphasize this, we added a comparison table in the discussion chapter highlighting differences between ConLogTwin and typical DMS/CDE setups and existing DT frameworks. (Table 5 & Lines 715f)

Comment 3: The paper provides no concrete evidence for claimed benefits such as "reducing costs and improving coordination" (line 11). Without cost-benefit analysis, performance benchmarks, or comparative studies, these claims remain unsubstantiated. The economic feasibility of maintaining the proposed infrastructure is not addressed.

Response 3: We acknowledge this point. A quantitative cost-benefit analysis is indeed challenging at this stage, as benefits are difficult to monetize without large-scale deployment. Performance benchmarking is also hardware-dependent and therefore not central to a reference architecture paper. Instead, our evaluation takes the form of a qualitative requirement-based assessment. We revised the wording in the abstract and evaluation sections to make this scope clearer and to avoid overstating performance claims. (Lines 643f, 653f, 686f)

Comment 4: The five-entity data model (project, building, component, package, delivery) appears overly simplistic for the complexity of construction logistics. The paper doesn't address how this model would handle: multi-phase projects with evolving requirements; complex dependencies between deliveries and work sequences; integration with existing enterprise systems; scalability across different project types and sizes.

Response 4: The model is intentionally kept simple to ensure clarity and usability. It covers the essential entities of construction supply chains. Advanced dependencies between deliveries and work sequences are not modeled directly, as these are typically handled by planning tools. We added clarifications that timestamps and versioning support evolving project requirements, and that scalability is ensured through the underlying infrastructure. We also highlight that automated delivery planning modules can accommodate sequence dependencies where necessary. (Lines 517f)

Comment 5: The paper mentions "strong security mechanisms" (line 293) as requirements but provides minimal detail on implementation. Given the sensitive nature of construction project data and the multi-stakeholder environment, this represents a significant oversight.

Response 5: We agree that security and data sovereignty are crucial in practice. However, a detailed implementation lies outside the scope of this paper. We clarified that the technologies used (e.g., Docker, MongoDB, MQTT) already provide well-established security mechanisms. We adjusted the text to make clear that these considerations are acknowledged but not the focus of this work. (Line 692)

Comment 6: The three scenarios presented (Section 7.2) are overly simplistic and don't reflect the complexity of real construction logistics challenges. More sophisticated scenarios involving multiple simultaneous disruptions, conflicting stakeholder priorities, or system failures would better test the framework's robustness.

Response 6: We thank the reviewer for this valuable comment. We have revised Section 7.2 to clearly state that the evaluation is a qualitative assessment, not a quantitative evaluation of a final system. The scenarios were sharpened to better reflect practical complexity, but they remain illustrative examples used to verify whether the architecture meets previously identified requirements. We also renamed the section from “Evaluation” to “Qualitative Assessment” to avoid misunderstanding. (Section 7)

Comment 7: The paper does not present any actual results for the scenarios described in Section 7.2. The three scenarios mentioned (pages 19-20, lines 641-647) are presented as brief conceptual descriptions without any implementation, testing, or results. The authors conclude these scenarios "illustrate how the modular and service-oriented architecture enhances resilience and decision support" (lines 648-649), but this conclusion is unsupported by any actual data, measurements, or demonstrated functionality. This represents a significant methodological flaw. The scenarios are presented as part of the "Evaluation of the ConLogTwin" section, yet they provide no empirical evidence, performance metrics, or even simulated results. They read more like hypothetical use cases or requirements specifications rather than evaluation results. This absence of results reinforces my earlier critique about the lack of validation. The paper presents what the system is designed to do rather than demonstrating what it actually accomplishes, which undermines the credibility of the evaluation section and the overall contribution of the work.

Response 7: We thank the reviewer for the comment. The scenarios in Section 7.2 are conceptual illustrations demonstrating how ConLogTwin’s modular architecture and services (e.g., Automated Delivery Planning, Dashboard, Data Integration/Preprocessing) could address typical construction logistics challenges. This work provides a simple reference architecture and a demonstrative prototype rather than a full empirical evaluation. We have revised the section to clarify which framework modules are involved in each scenario and how they contribute to resolving the respective challenge. Full-scale validation and quantitative assessment are planned as future work. (Section 7.2)

Reviewer 2 Report

Comments and Suggestions for Authors

The paper presents ConLogTwin, a modular Digital Twin framework for construction logistics that integrates planning data, IFC models, and live site telemetry within a layered architecture and service layer, aiming to support real time coordination and decision making.  The architecture, depicted in Figure 7 on page 13, couples a Sensor DB, a ConLog DB, and a Media DB through a web API, and provides services for IFC decomposition, automated delivery planning, and delivery surveillance based on geofencing and image analysis.  A containerized prototype using MongoDB, MinIO, FastAPI, and MQTT demonstrates feasibility, while full scale validation remains pending. The main novelties lie in the logistics centric integration, an IFC linked flexible data model, and service oriented extensibility.

Some major comments of mine:

- The manuscript appears to overstate its degree of novelty. Table 1 on  page 10 aggregates established DT lines for logistics, including transport optimisation, delivery tracking, and on site silo models, which implies a capacious prior corpus. The conclusion concedes the base technologies are not new. Differences rest mainly in the chosen combination and the  emphasis on logistics, yet no systematic comparison to extant frameworks is presented to locate the incremental contribution.

- The abstract explicitly states that no full  scale field study has been conducted, leaving effectiveness in practice to be tested in future work. Section 7 offers requirements coverage, three illustrative scenarios, and a risk table, with no measurements, no comparative indicators, and no project  scale deployment to verify operability.

- Figure 7 on page 13 and Section  5.2.1 present a ConLogTwin Core that separates Sensor DB, ConLog DB, and Media DB for storage. Table 2 on  page 18 selects MongoDB with eventual consistency rather than PostgreSQL with ACID guarantees, a choice defended qualitatively only in the text, not apodictic. There is no load testing or representative query workload to evidence safe delivery scheduling, avoidance of double booking, or loss free updates for inventory and unloading bay reservations.

- Section 3.2.2 treats security, standardisation, and sovereignty as criteria, yet it  specifies no model for access control, encryption, audit logging, or deletion. The implementation  suggests an authentication service at the API, with no identity architecture or rights mapping across client, contractor, LSP, and authority for location, imagery, and plate data. Risk tabulation lists role based controls without enforceable verification, a perfunctory rubric.

- The service layer is incipient and thin on algorithms, and remains unimplemented. Two central services, automated delivery planning and delivery surveillance via geofencing or image analysis, are only conceptual in Section 5.2.2, without constraint specifications, algorithms, or acceptance criteria. The prototype in Section 6  comprises the database, the object store, the API, and the IFC decomposition service, with no quantitative results for accuracy, latency, or system load. ISO 42010 compliance is asserted through viewpoint descriptions without artefacts or independent assessment. The dashboard in Figure  10 remains at design stage, with no user testing to substantiate usability, so the core capability remains speculative rather than demonstrable.

Author Response

Comment 1: The manuscript appears to overstate its degree of novelty. Table 1 on  page 10 aggregates established DT lines for logistics, including transport optimisation, delivery tracking, and on site silo models, which implies a capacious prior corpus. The conclusion concedes the base technologies are not new. Differences rest mainly in the chosen combination and the  emphasis on logistics, yet no systematic comparison to extant frameworks is presented to locate the incremental contribution.

Response 1: We agree and would like to clarify: our contribution is not the invention of a new technology, but the design of a reference architecture for construction logistics digital twins, built on open-source technologies and structured for modularity and adaptability. We revised the abstract and conclusion to clearly articulate this scope and contribution.

Comment 2:  The abstract explicitly states that no full  scale field study has been conducted, leaving effectiveness in practice to be tested in future work. Section 7 offers requirements coverage, three illustrative scenarios, and a risk table, with no measurements, no comparative indicators, and no project  scale deployment to verify operability.

Response 2: As noted in our response to Reviewer 1, this is a deliberate choice of scope. This work focuses on designing and presenting the reference architecture. A field study will follow in future work, and we have made this distinction clearer in the revised manuscript.

Comment 3: Figure 7 on page 13 and Section  5.2.1 present a ConLogTwin Core that separates Sensor DB, ConLog DB, and Media DB for storage. Table 2 on  page 18 selects MongoDB with eventual consistency rather than PostgreSQL with ACID guarantees, a choice defended qualitatively only in the text, not apodictic. There is no load testing or representative query workload to evidence safe delivery scheduling, avoidance of double booking, or loss free updates for inventory and unloading bay reservations.

Response 3: We expanded the discussion on database choices. While MongoDB’s eventual consistency model can theoretically introduce risks, our practical experience shows these issues rarely occur when implemented carefully. Conversely, PostgreSQL faces scalability limitations for large data streams. We clarified that our design acknowledges this trade-off, and we recommend careful implementation and monitoring to mitigate potential issues. For the simplicity of implementation only one DBMS is chosen for SensorDB and ConLogDB. MinIO is used as MediaDB. (Lines 593f)

Comment 4: Section 3.2.2 treats security, standardisation, and sovereignty as criteria, yet it  specifies no model for access control, encryption, audit logging, or deletion. The implementation  suggests an authentication service at the API, with no identity architecture or rights mapping across client, contractor, LSP, and authority for location, imagery, and plate data. Risk tabulation lists role based controls without enforceable verification, a perfunctory rubric.

Response 4: As in Reviewer 1’s comment, we clarified that security is not a central scope of this paper. We acknowledge its importance but rely on existing proven mechanisms of the employed technologies. The revised text makes this scope boundary clearer. (Lines 692)

Comment 5: The service layer is incipient and thin on algorithms, and remains unimplemented. Two central services, automated delivery planning and delivery surveillance via geofencing or image analysis, are only conceptual in Section 5.2.2, without constraint specifications, algorithms, or acceptance criteria. The prototype in Section 6  comprises the database, the object store, the API, and the IFC decomposition service, with no quantitative results for accuracy, latency, or system load. ISO 42010 compliance is asserted through viewpoint descriptions without artefacts or independent assessment. The dashboard in Figure  10 remains at design stage, with no user testing to substantiate usability, so the core capability remains speculative rather than demonstrable.

Response 5: We agree. A detailed technical deep dive into planning algorithms or surveillance methods would exceed the scope of this architecture-focused paper. Instead, we added clarifications on the role of these modules within the architecture, while noting that their algorithmic underpinnings remain an area for further research and separate publications. (Lines 493f, 448f)

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The authors have thoroughly addressed all of the reviewer’s previous comments and suggestions. The revised version adequately incorporates the requested changes and improvements. I have no further comments or recommendations. The manuscript is acceptable in its current form.

Author Response

We sincerely thank the reviewer for their positive evaluation and confirmation that the revised manuscript meets the expectations. We appreciate the constructive feedback throughout the review process, which has helped us improve the quality and clarity of the paper.

Reviewer 2 Report

Comments and Suggestions for Authors

Thanks for detailed clarification and improvement of the work. All concerns of the reviewer has been considered carefully. The manuscript reaches a level of an acceptance.

Author Response

We sincerely thank the reviewer for their positive evaluation and confirmation that the revised manuscript meets the expectations. We appreciate the constructive feedback throughout the review process, which has helped us improve the quality and clarity of the paper.