Digital-Twin-Guided Protocol for Supply Chain Risk Prediction and Mitigation with Neural Sequence and Graph Models

Summary

This protocol details a reproducible digital-twin workflow integrating data ingestion, sequence-and-graph-based risk prediction, propagation simulation, and policy optimization. It specifies software versions, parameters, checkpoints, and troubleshooting steps to support faithful replication in industrial settings.

Abstract

Supply chains require real-time risk prediction and mitigation under high uncertainty and network interdependence. This protocol describes a reproducible digital-twin (DT) workflow that links data ingestion, spatiotemporal risk forecasting, risk propagation simulation, and mitigation policy optimization in a single containerized stack. For prediction, we integrate an interpretable sequence-and-graph model that combines a Bi-LSTM with graph convolution to capture temporal dynamics and network dependencies. For mitigation, proximal policy optimization (PPO) learns actionable decision policies from simulated disruptions, enabling cost-aware responses rather than post hoc diagnosis. To support deployment and replication, we provide a hierarchical key-risk-indicator taxonomy that separates endogenous and exogenous risks, together with version-pinned environments, data contracts, and validation checkpoints. Representative results demonstrate both predictive and decision-level gains. On a 300-node automotive network, the approach improves F1 by 19.3% and extends the early-warning horizon by 5.2 h. In a 2021 U.S. port-congestion replay, PPO reduces delays and emergency-response costs by over 20%. The workflow scales to 500-node simulations with millisecond-level latency while maintaining stable long-horizon performance. Dual validation with historical-event replay and online simulation confirms improved accuracy, robust decision quality, and practical scalability. Limitations and adaptation guidelines are discussed to facilitate transfer to new supply-chain settings.

Introduction

The global supply networks are under constant uncertainty, where local disruptions can propagate across supplier tiers and transport lanes and trigger system-wide slowdowns. In many organizations, risk monitoring still relies on retrospective reports or periodic audits, which are useful for documenting incidents and compliance but are less effective for fast-changing operational streams. When data evolves minute by minute, decision makers need a workflow that supports continuous sense-making, near-term prediction, and timely intervention rather than post hoc diagnosis¹.

Traditional tools such as risk registers and statistics-based early-warning models remain valuable for standardization and high-level tracking, yet they typically abstract away the dynamic interactions among facilities, inventories, capacities, and flows. The digital-twin-based workflow described here complements these approaches by maintaining continuous state synchronization and enabling scenario-based assessment, so that what-if disruptions and mitigation actions can be tested before they reach the shop floor or the yard. In practice, the twin serves as a cyber-physical representation that mirrors key operational states and constraints, providing an actionable basis for proactive mitigation rather than retrospective reporting².

Recent supply chain research has highlighted increasing vulnerability to disruptions caused by globalized supplier networks, fluctuating demand patterns, geopolitical instability, and climate-driven events. Traditional risk management approaches rely heavily on retrospective reporting and static assessments, which fail to capture rapidly evolving operational conditions or the complex interdependencies within multi-tier networks. Practical deployment hinges on two requirements. Risk must be quantified with indicators that are comparable across plants and regions; otherwise, thresholds drift, and alarms become arbitrary, and the twin must meet explicit latency and fidelity targets so that simulated states track operational reality closely enough to support control decisions^3,4. Building on these requirements, this protocol describes a reproducible workflow that connects data contracts to decision policies within one continuous system. Temporal signals are summarized with bidirectional long short-term memory, network structure is encoded with graph convolution, and attention weight visualization is used to keep the modeling step interpretable to operators and auditors^5,6,7,8. Although data-driven models and early digital-twin applications have improved situational awareness, they often remain fragmented, lacking unified mechanisms for real-time perception, spatiotemporal prediction, and actionable decision support. These gaps underscore the need for an integrated protocol that combines high-fidelity digital-twin environments with advanced sequence and graph learning models to enable timely, interpretable, and scalable risk monitoring in dynamic industrial systems. Mitigation strategies are obtained through proximal policy optimization trained against the twin, which allows trade-offs among service level, delay, and cost to be tuned without affecting live operations^9,10.

This research is for medium-to-large supply networks (100–500 nodes) with streaming data volumes of 1–5 million records/day and moderate data quality (≥85% completeness, ≤5% missingness after preprocessing). Real-time deployment requires sustained end-to-end latency below 100 ms and stable synchronization (<0.5% drift) and may be limited to low-bandwidth or non-containerized environments.

Protocol

We confirm that this study uses de-identified enterprise and logistics records, together with synthetic disruption scenarios, with no human or animal involvement. Access to raw operational logs was granted in writing by the data-owning organizations and approved by the institutional data governance committee prior to data extraction. Data access was managed through role-based access control; all access events were logged; and audit trails will be retained for ≥3 years after publication. When reporting disruption cases, we generalize or mask firm-identifying attributes (e.g., facility names, customer identifiers, contract IDs, and exact geolocations) to reduce re-identification risk. Copies of data-use approvals and consent/permission letters can be provided to the journal upon request and will be included as supplementary documentation for editorial review.

1. Digital twin concept, architecture, and standards

1. Define the digital twin according to Grieves’ information mirror model, and specify a five-layer stack (physical, virtual, data, connection, application) with clear layer responsibilities and interfaces, as emphasized in Grieves’ early work and ISO 23247 standards. System design documents and ISO-23247 schemas are used as the primary inputs, with layer definitions normalized into a five-layer abstraction for consistent architectural mapping^2,11.
2. Illustrate the end-to-end architecture in Figure 1; declare global identifiers (assetID, modelID, runID), the canonical time base (UTC), and the naming scheme for datasets and experiments. Standardize asset metadata, model registries, and experiment logs into unified ID formats (assetID/modelID/runID) and timestamp them in UTC before architectural integration.
3. Adopt open standards for interoperability: use OPC UA/IEC 62541 and MQTT v5 for field-to-platform exchange, REST/GraphQL for service APIs, and FMI/AutomationML for model exchange and topology description. Note any cross-domain schema gaps and provide adapters with explicit fidelity notes. OPC UA/MQTT field streams and AutomationML/FMI model files are parsed, validated, and converted through schema adapters to maintain interoperability across platforms^2,12,13,14.
4. Synchronize all nodes with IEEE 1588 PTP, enforce sub-100 ms end-to-end latency for closed-loop use, and document acceptance limits for jitter and clock drift. Record validation and adapter round-trip checks in Table 1. Clock-sync logs, network traces, and round-trip latency samples are collected and cleaned to verify sub-100 ms timing constraints and PTP synchronization accuracy¹⁵.
5. Pause Point: After Steps 1.1–1.4, pause to confirm schema round-trips (export, import, and validation) and latency compliance before proceeding.
   Validate schema round-trips: confirm export/import/validation logs show no errors.
   Latency metrics: end-to-end <100 ms; jitter <5 ms; clock drift <1 ms/min.
   Dashboard snapshot: ensure Table 1 is populated with adapter round-trip times and synchronization errors.

2. Analytical technologies for risk perception and prediction

1. Train predictive models on historical multi-source logs (orders, telemetry, events) to establish early-warning capability; fix random seeds and record data splits for reproducibility. Standardize numerical variables, apply one-hot encoding to categorical features, and construct sequences using sliding windows (e.g., 12–24 time steps).
2. Split data into 70% training, 15% validation, and 15% testing. Use a Bi-LSTM with 2 layers (128–256 units), dropout 0.2–0.3, and Adam optimizer (LR = 1e-3). Log all random seeds to ensure reproducibility. Clean historical order logs, telemetry, and event streams, standardize, encode, and convert them into sliding-window sequences for Bi-LSTM training.
3. Apply unsupervised anomaly detection methods (e.g., isolation forest, robust covariance, autoencoders) when labeled data is sparse and calibrate thresholds using precision–recall trade-offs. Normalize inputs with Min-Max scaling, then train isolation forests with 100–200 trees or autoencoders with 3–5 hidden layers. Tune thresholds using PR-curve optimization and evaluate using reconstruction error or anomaly score distributions. Normalize unlabeled operational logs (Min-Max) and transform them into anomaly-score features for isolation forest or autoencoder training and threshold calibration^16,17.
4. Integrate sequence- and graph-based models (e.g., Bi-LSTM with attention and GCN) to capture temporal patterns and spatial dependencies across supplier–transport networks. Create adjacency matrices from supplier–transport linkages and normalize with symmetric degree scaling. The hybrid model combines Bi-LSTM outputs with 1–2 GCN layers (hidden size 64–128) and a fully connected classification head. Train for 30–50 epochs, with early stopping based on validation F1^18,19.
   NOTE: The graph convolution step in the proposed model updates node representations using the normalized aggregation rule shown in Equation (1), enabling each node to incorporate information from its neighbors while preserving structural balance. This formulation ensures stable feature propagation across the supply-chain network and provides the foundation for capturing spatial dependencies within the digital-twin architecture.
      (1)
    is the adjacency matrix with self-loops added. refers to the degree matrix of . H^(l) is the node feature matrix at layer l. W^(l) is the trainable weight matrix and σ(•) is the ReLU activation function. Supplier–transport network tables are converted into adjacency matrices and normalized with symmetric degree scaling before feeding into the hybrid sequence–graph model.
5. Use natural language processing to extract policy and market signals from news and bulletins and apply computer vision to detect port disruptions from monitoring feeds with privacy masking. To extract sentence embeddings from policy or market bulletins, use a pretrained transformer (e.g., BERT-base), and then apply lightweight CNNs or MobileNet for port-feed frame analysis after privacy blurring. Prior to fusion, normalize all external-modal embeddings²⁰.
6. Construct a knowledge graph of suppliers, lanes, facilities, and contracts to enable causal queries and root-cause tracing; export snapshots for Figure 2. Create nodes from suppliers, products, routes, and facilities, then construct edges with contractual linkages and logistics flows. Use RDF or property-graph format, entity resolution rules, and graph validation to detect unconnected components²¹.
7. Search strategy clarification and keyword construction
   1. Refine the search method to clearly present the structure and logic of query terms. Group search terms by concept and combine using Boolean operators to ensure systematic and reproducible searching. For example, the full query string used was:
      (“supply chain risk” OR “supply disruption”) AND (“digital twin” OR “simulation”) AND (“prediction” OR “early warning”).
      Displaying the search syntax in structured form clarifies the execution sequence and reduces ambiguity. Separating technology, domain, and functional keywords demonstrates transparency and supports reviewers in verifying the search process.
   2. Troubleshooting: When there are too many alerts, increase aggregation windows, introduce hysteresis, or raise anomaly thresholds using robust statistics. If models drift or become unstable, retrain on a fixed schedule and maintain backtesting logs to document performance changes.

3. Risk classification and key indicator system

1. Classify risks into endogenous (linear propagation within the enterprise network) and exogenous (multi-node shocks from external sources). Provide examples and mapping rules^22,23.
2. Establish a multi-tier Key Risk Indicator (KRI) system covering supplier stability, production operations, logistics performance, and information integration; define each KRI, its data source, and update cadence. Filter supplier, operations, logistics, and integration datasets; aggregate and align them to generate tiered KRI values with defined update frequencies.
3. Present the KRI definitions, formulas, and alert thresholds in Table 2; document acceptance criteria and escalation playbooks²⁴.
   1. Quality control: Authenticate the KRI system by requiring a minimum concordance of 0.7 between generated alerts and historical incident logs. Release the KRI threshold only after passing concordance testing. To obtain empirical validity, back-test the multi-tier KRI system against historical incident logs using concordance testing.
   2. Threshold setting and back-testing: Set alert thresholds for each indicator (e.g., Level 1 alert: delivery fulfillment <95%; Level 2 alert: delivery fulfillment <85%; demand fluctuation >5%) and back-test them against 18 months of operational history and timestamped disruption records. Define concordance as the proportion of KRI alerts that match actual incident occurrence within a ±12 h window. Confirm that the concordance mean meets the release criterion (≥0.7) before operational use.
   3. Threshold maintenance: In subsequent deployments, modify thresholds by periodic retesting and back-testing, or adjust the testing window based on seasonal trends and anomaly frequency.
4. KRI threshold performance in true incident capture vs. false alarms
   1. Test each KRI threshold in the Risk-Type-Indicator table and back-test against 18 months of historical incident logs to determine operational usefulness. For each indicator, compute the true incident capture rate (recall), defined as the percentage of real disruption events identified prior to or at the time of occurrence. Compute the false alarm rate, defined as the proportion of alerts for which no disruption occurs within a ±12 h window. Use these metrics to quantify the trade-off between sensitivity and operational noise in early warning (Table 3).
5. Scenario-based evaluation of the proposed spatiotemporal model
   1. Evaluate prediction accuracy, calibration reliability, and computational efficiency of the proposed Bi-LSTM + Attention + GCN spatiotemporal fusion model using three representative disruption scenarios: equipment failure risk, geopolitical disruption risk, and cascading multi-node network failure. Use Mean Absolute Error (MAE), Brier Score, and decision-cycle computation time as evaluation metrics (Table 4).

4. Quantification models

1. Apply probability-based models (e.g., Monte Carlo) to estimate event likelihood and expected loss; report convergence diagnostics and confidence intervals. Sample disruption probabilities from empirical distributions or fitted parametric models. Run 5,000–10,000 iterations, calculate estimated loss per node, and report 95% confidence intervals²⁵.
2. Transform expert judgments into quantitative scores using fuzzy logic (e.g., fuzzy AHP/FIS); calibrate membership functions from historical outcomes. Develop pairwise comparison matrices using expert inputs, translate linguistic concepts into triangular fuzzy numbers, and calculate aggregated weights using geometric means. Defuzzify using the centroid method to obtain crisp risk scores²⁶.
3. Employ network analysis to map propagation paths and identify vulnerable nodes via centrality and percolation thresholds; export candidate cut-sets. Filter supplier, operations, logistics, and integration datasets; aggregate and align them to generate tiered KRI values with defined update frequencies.
4. Calculate node centrality metrics (degree, betweenness, eigenvector) and simulate propagation using threshold or SIR-style models with configurable transmission probabilities (e.g., 0.1–0.3). Identify key nodes by prioritizing propagated influence across 500–1,000 simulation runs^27,28.
5. Compare probability, fuzzy, and network models in Table 5; select by scenario fit, data availability, and interpretability. Pause Point: lock parameter baselines and archive configuration files before moving to deployment.
   Output: parameter baselines saved in configuration files.
   Logs: convergence diagnostics, confidence intervals, and centrality calculations archived.

5. Overall architecture and functional modules

1. Organize capabilities into five domains and seven layers; map perception, quantification, prediction, decision, and execution modules to containerized microservices with versioned APIs.
2. Provide the seven-layer functional mapping in Table 6 with service names and dependencies.
3. Implement real-time data collection via an end–edge–cloud pipeline; define sampling frequencies, batching rules, and QoS in Table 7; record broker topics and retention policies. Illustrate the pipeline in Figure 3^29,30.
4. Construct virtual models using Graph-SLAM for layout and flows, agent-based simulation for behaviors, and CFD tools for environment constraints; bundle scenario presets for Figure 4.
5. Ensure synchronization below 100 ms using pub/sub messaging and PTP; capture runtime latency, throughput, and packet-loss metrics, and provide raw metrics in the supplementary datasets.
6. Develop decision-support modules for early warning, sandbox simulation, and operator visualization; expose REST endpoints and role-based dashboards. Normalize early-warning outputs, simulation results, and visualization parameters for dashboard rendering.
   Check: ingestion pipeline active; sample messages processed via MQTT/OPC-UA.
   Check: model endpoints respond to test requests (REST/GraphQL).
   ​Data Availability Note: archive configuration files, model weights, and simulation seeds; provide checksums and a read-only repository link in the Data Availability section.
7. Hyperparameter settings for risk prediction model
   1. See Table 8 for hyperparameter settings of the workflow (Bi-LSTM, GCN, fusion gate, PPO modules, and training environment settings).
8. Paired sample t-test
   1. Use a paired sample t-test to assess whether the observed improvements in model performance (e.g., prediction accuracy, early-warning horizon, propagation precision, and decision-quality indicators) differ significantly between the baseline outputs and the proposed method under matched scenarios. Compute the test statistic using Equation (2):
         (2)
      where is the mean paired difference between baseline and proposed outputs, s_d is the standard deviation of the paired differences, m is the number of paired observations (matched simulation scenarios), and u is the paired t-test statistic.

Results

Experimental setup

The protocol uses Python 3.11 with PyTorch 2.1, scikit-learn 1.3, NetworkX 3.1, pandas 2.1, numpy 1.27, and optional TensorFlow 2.14. Simulations rely on Graph-SLAM (g2o 2025.10, ROS2), AnyLogic 2025 for agent-based modeling, and ANSYS Fluent 2025 or OpenFOAM v11 for CFD. Data exchange is supported through MQTT v5, OPC-UA, and FastAPI for model serving, with containerization via Docker 24.0 and NVIDIA Toolkit. Required hardware includes ≥16-core CPUs, ≥512 G...

Discussion

The study’s findings support the view that digital-twin-enabled learning pipelines can strengthen supply chain risk management by coupling state synchronization with data-driven forecasting. The experimental results indicate that the Bi-LSTM–attention backbone, combined with GCN-based spatial encoding, improves predictive accuracy and extends the early-warning horizon, which is consistent with recent evidence that spatiotemporal forecasting benefits from incorporating exogenous signals and network structure i...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
AnyLogic Simulation Platform	The AnyLogic Company	N/A	Multi-method modeling software for agent-based, discrete-event, and system dynamics simulations, integrated with TensorFlow
NVIDIA A100 GPU Server Cluster	NVIDIA Corporation	N/A	Used for parallel training of Bi-LSTM-Attention + GCN models and PPO optimization within the digital twin platform