An Experimental Protocol for Explainable AI-Driven Secure Cloud Data Migration Using Synthetic Healthcare Data

Summary

This method presents a comprehensive explainable artificial intelligence (XAI) based framework to enable secure healthcare cloud data migration, leveraging a synthetic healthcare dataset within a controlled cloud environment. The result is a prototype that combines zero-trust security, time-based access control, and explainable anomaly detection to support migration transparency and security.

Abstract

In healthcare systems, more and more cloud data migration is being done, but this also changes the times when data transfer is probably the biggest risk in terms of security. This paper describes a reproducible protocol for explainable artificial intelligence (XAI)-based secure cloud data migration using a synthetic healthcare dataset and a controlled cloud environment. The developed framework merges zero-trust architecture, temporal least privilege, encrypted communication, centralized monitoring, and explainable anomaly detection to have a more secure, transparent, and auditable migration. The tests use a 10 GB dataset of synthetic electronic health records, comprising approximately 20 million records across 28 relational tables. The migration process was carried out on Amazon web services (AWS) using PostgreSQL databases and private virtual networks. For anomaly detection, Isolation Forest was utilized, and Shapley additive explanations (SHAP) served for the secure event interpretation. The framework was evaluated on ten separate migration attempts using metrics such as credential exposure duration, incident detection time, anomaly-detection accuracy, migration latency, and data integrity. Under the configuration tested, credential exposure was reduced from 24 h to 1 h (a 95.8% reduction), the accuracy of anomaly detection was 97.4%, incident detection time was reduced to about 15 min, and 100% data integrity was preserved through checksum validation. However, the stronger security measures resulted in an average migration latency increase of 11%. These results showcase the promise of merging explainable AI with secure cloud migration workflows for managing healthcare data.

Introduction

Cloud computing is now an integral part of healthcare systems worldwide, offering scalable storage, computational resources, and the ability to exchange health records, support decision-making systems, and enable health analytics through the cloud^1,2,3. With many healthcare institutions upgrading their information systems, moving to the cloud has become a vital step for them in order to transfer their sensitive health data held in the older on-premises systems to the cloud⁴. Proper migration leads to easier data retrieval, running operations in a more efficient manner, and supporting analytics with higher levels of intelligence, but at the same time, one cannot ignore quite serious security and privacy risks that getting data from one place to another entails⁵.

The migration phase is a notoriously vulnerable moment in the data lifecycle since healthcare data is being actively moved across systems and networks by the nature of the process⁶. Besides, organizations may get exposed to threats such as hacking of credentials, unauthorized access, intercepting data, manipulating schemes, and even data loss during the migration phase^6,7. Healthcare environments are less immune to such risks as patient information is highly sensitive and hence requires the highest level of compliance with regulatory and security measures^8,9. Short of that, it is not feasible to ensure data confidentiality, integrity, and accountability if the migration workflow is not secured and made observable^10,11.

A number of security frameworks and standards have been developed trying to make cloud security better. For instance, The National Institute of Standards and Technology (NIST) Zero Trust Architecture is all about making users, devices, and services be verified all the time¹², whereas cloud adoption frameworks give directions on governance, identity management, encryption, and monitoring¹³. In fact, present day cloud security methods focus on automation, infrastructure-as-code, and continuous monitoring^14,15. While such approaches are based on valuable security principles, to a large extent, they deal with general cloud deployment and operational environments rather than the migration process itself¹⁶. Actually, they hardly show step-by-step, detailed, and reproducible procedures for performing secure healthcare cloud data migration workflows that combine identity management, secure data transfer, validation, monitoring, and post-migration hardening¹⁷.

Machine learning anomaly detection has been recognized as a helpful technology in security monitoring of cloud environments. It detects abnormal system activity as well as potential security incidents¹⁸. Still, many anomaly detection methods are closed systems that fail to provide explanations on the rationale behind the flagging of a security event¹⁹. The inability to explain decision made by the system reduces credibility of administrators, makes auditing difficult and diminishes the value of automated security decisions in highly regulated healthcare environments²⁰. Explainable artificial intelligence (XAI) methods like SHapley Additive exPlanations (SHAP) and Local Interpretable Model-agnostic Explanations (LIME) not only provide clear explanations for machine learning predictions but also enhance understanding, accountability, and confidence in security monitoring systems^21,22.

Even though cloud security and explainable AI have made great strides, there is still a scarcity of reproducible experimental protocols combining secure migration controls with explainable security monitoring for the sake of integration²³. Existing research mostly addresses single components only, such as encryption, access control, anomaly detection, or cloud governance, and nowhere do they offer an integrated methodology that can be systematically implemented, evaluated, and reproduced²⁴. On top of that, hardly any studies have tried to bring together zero-trust security principles, temporal least privilege, centralized observability, and explainable anomaly detection into one single healthcare cloud migration workflow^25,26.

This paper introduces an Explainable AI-based framework for secure cloud data migration in healthcare systems to fill this void. The proposed architecture utilizes a zero-trust model, time-restricted access, secure communication, central logging and monitoring, and SHAP-based interpretable anomaly detection in a well-ordered migration process^27,28. The protocol is a step-by-step guide for implementing, monitoring, and assessing secure healthcare data migration under experimental conditions. By joining together security controls with AI interpretable monitoring, the framework being proposed intends to raise the level of transparency, auditability, and security all along the migration lifecycle^29,30.

Protocol

This study used a fully synthetic healthcare dataset generated for experimental evaluation of secure cloud data migration. No real patient data, protected health information (PHI), or identifiable healthcare records were used. Therefore, Institutional Review Board approval and informed consent were not required. All the materials used in this study are included in the Table of Materials.

1. Overview

1. Configure a secure cloud migration environment consisting of a source layer, migration hub layer, target layer, network layer, identity and access management layer, observability layer, and explainable AI layer.
2. Deploy all components within isolated cloud environments to support secure healthcare data migration. Establish encrypted communication channels between all system components.
3. Execute the protocol through dataset preparation, environment configuration, architecture deployment, secure migration, anomaly monitoring, and post-migration validation. The overall architecture of the proposed Explainable AI-driven secure cloud data migration framework is illustrated in Figure 1.

Figure 1: Overall architecture of the explainable artificial intelligence (XAI)-enabled secure cloud data migration framework for healthcare systems. The framework consists of the identity and access management layer, source database layer, migration hub layer, target cloud database layer, network security layer, observability layer, explainable AI monitoring layer, and cross-cutting security and governance services. The architecture integrates temporal least-privilege access control, TLS 1.3 encrypted communication, checksum-based integrity verification, continuous security monitoring, and SHAP-based explainability to provide secure, transparent, and reproducible healthcare database migration. This figure was created by the authors using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

2. Computational environment configuration

1. Configure the computational environment
   1. Prepare the computational resources required for secure cloud data migration and explainable AI-based monitoring.
   2. Install and configure all hardware, software, cloud services, databases, security tools, and machine learning libraries listed in the Table of Materials. Verify that all required components are operational before initiating the migration experiment.
2. Configure the Cloud Environment
   1. Set up a cloud environment that is secure for healthcare data migration. Set up a private VPC for seamless communication between the source, migration hub, and target systems. Use strong encryption not only when data is stored, but also when it is transmitted.
   2. Prepare the target database and migration services according to the details mentioned in the Table of Materials.
3. Configure identity and access management. configure monitoring and logging services.

3. Dataset preparation and description

1. Generate a synthetic healthcare dataset using the Faker Python library listed in the Table of Materials. Configure demographic attributes, including patient age, sex, ethnicity, and geographic location, using predefined probability distributions.
2. Generate clinical information, including diagnoses, laboratory results, medications, allergies, procedures, and hospital admissions, while preserving realistic clinical relationships.
3. Generate longitudinal patient encounters by assigning multiple visits to individual patients according to predefined visit-frequency distributions.
4. Generate timestamps for admissions, laboratory investigations, medication administration, discharge summaries, and audit logs using chronological event ordering.
5. Introduce clinically realistic missing values, duplicate records, and outlier observations according to predefined data-quality distributions.
6. Replace all personally identifiable information with synthetic values generated using the Faker library. Validate referential integrity and logical consistency before exporting the dataset. Export the validated dataset in PostgreSQL-compatible SQL format. Configure the dataset to support realistic healthcare migration scenarios. The characteristics of the generated dataset are summarized in Table 1.
7. Define database relationships. Assign Patient_ID as the primary key for the patient table. Establish foreign-key relationships between patient, visit, laboratory, medication, and audit-log tables. Verify referential integrity across all tables before initiating migration.
8. Simulate realistic healthcare data characteristics. Generate patient ages using a normal distribution. Generate visit frequencies using a Poisson distribution. Introduce missing values at a rate of 5% to simulate real-world EHR incompleteness. Replace all patient identifiers with hashed values before migration. Verify that all generated records conform to predefined schema constraints.
9. Validate the generated dataset by checking schema consistency, referential integrity, missing values, duplicate records, and predefined quality constraints before migration.

Parameter	Value
Dataset Type	Synthetic Healthcare EHR Dataset
Dataset Size	10 GB
Total Records	20 Million
Number of Tables	5 Core Tables- 28 relational tables
Patient Records	5,000,000
Visit Records	10,000,000
Laboratory Results	4,000,000
Medication Records	3,000,000
Audit Logs	5,000,000
Primary Key	Patient_ID
Missing Value Rate	5%
Age Distribution	Normal Distribution
Visit Frequency	Poisson Distribution
Integrity Threshold	<0.1% Violations

Table 1:  Characteristics of the synthetic healthcare dataset used for protocol validation. The table provides an overview of the dataset, such as database size, number of relational tables, total records, patient attributes, clinical variables, and validation characteristics to reproduce the secure migration experiments.

4. System architecture deployment

1. Deploy the secure cloud migration architecture consisting of the source layer, migration hub layer, target layer, network security layer, observability layer, and explainable AI layer. The deployed system architecture used in this study is illustrated in Figure 2.
2. The framework is composed of six working layers, which, during the migration process, carry out their functions one after another. The first layer, the Source Layer, is the one that contains the synthetic healthcare database. 
3. The Migration Hub is the one in charge of schema extraction, encrypted data transfer, integrity validation, and migration orchestration. The target layer is where the migrated database is stored in Amazon RDS PostgreSQL. 
4. The network security layer is the one that safeguards all the communications by the use of private VPC endpoints, TLS 1.3 encryption, security groups, and network access control lists. 
5. The observability layer is the one that is always collecting authentication logs, migration logs, database activity logs, and security events with the help of Amazon CloudWatch.
6. The explainable AI layer is the one that gets the security telemetry that has been collected, runs it through an Isolation Forest algorithm, and produces SHAP-based explanations for the anomalies that have been found. All architectural layers communicate with one another via private network channels that are authenticated during the entire migration workflow.
7. Deploy and verify the source database environment to ensure secure access and data availability before migration.
   1. Set up a PostgreSQL 16 database with the synthetic healthcare dataset. Keep patient information, visit details, lab results, drug records, and audit logs in the source database.
   2. Restrict database access to authorized migration services and administrative users only. Verify database availability and connectivity before initiating migration operations.
8. Configure the migration hub to coordinate schema extraction, encrypted data transfer, and migration orchestration.
   1. Deploy a dedicated migration server within the private Virtual Private Cloud (VPC). Configure migration orchestration services to coordinate schema extraction, data transfer, and validation activities.
   2. Enable schema-validation services to verify compatibility between source and target environments. Enable integrity-verification services to validate migrated data during and after transfer. Verify communication between the migration hub and database systems before executing migration tasks.
9. Deploy the Target Layer. Deploy Amazon RDS PostgreSQL 16 as the target database environment. Enable automatic backup and recovery services. Enable AES-256 encryption for data stored within the target database.
10. Configure Network Security. Disable all public IP addresses associated with migration resources. Permit communication only through private endpoints within the VPC. Configure network access control lists (NACLs) and security groups. Enable TLS 1.3 encryption for all communications between system components. Verify that no publicly accessible endpoints remain active.
11. Configure centralized monitoring to continuously collect security events, migration logs, and system performance metrics.
    1. Enable Amazon CloudWatch logging and monitoring services. Collect authentication logs, migration logs, database activity logs, and security-event logs. Configure log retention for 365 days. Enable immutable log storage to support auditing and compliance requirements. Verify real-time metric collection and alert generation.
12. Configure the explainable AI environment to perform real-time anomaly detection and generate interpretable security explanations.
    1. Deploy anomaly-detection services within the monitoring environment. Configure the Explainable AI framework to process security telemetry generated during migration. Connect security telemetry streams from the source, the migration hub, the target database, and the monitoring services.
    2. Enable real-time anomaly detection and SHAP-based explanation generation. Verify successful ingestion of telemetry data before initiating migration experiments.

Figure 2: Deployment architecture of the secure healthcare cloud migration framework. The deployment environment illustrates the source PostgreSQL database containing the synthetic healthcare dataset, the dedicated migration hub within a private virtual private cloud (VPC), the Amazon RDS PostgreSQL target database, the network security layer, centralized observability through Amazon CloudWatch, and the Explainable Artificial Intelligence monitoring layer. All communication occurs through private endpoints protected by TLS 1.3 encryption. This figure was created by the authors using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

5. Secure migration workflow

NOTE: Execute the secure migration workflow by performing threat modeling, schema transfer, secure data migration, migration validation, and post-migration hardening. 

1. Identify potential security threats and map appropriate mitigation controls before initiating the migration process.
   1. Identify migration assets, potential attack vectors, and realistic cyberattack scenarios.  
   2. Evaluate credential theft resulting from compromised authentication tokens, insider attacks involving unauthorized administrative access, replay attacks targeting previously intercepted authentication requests, man-in-the-middle (MITM) attacks attempting to intercept encrypted communication channels, schema tampering intended to modify database structures during migration, and privilege-escalation attacks aimed at obtaining unauthorized administrative permissions.
   3. Check that using temporal least-privilege credential management is sufficient in preventing credential theft and privilege-escalation attacks. Verify that communication encrypted with TLS 1.3 protects from replay attacks and man-in-the-middle attacks.
   4. Verify identity and access management (IAM) policies prevent unauthorized administrative access. Verify continuous audit logging keeps a record of all security-related migration activities. Make sure that checking by SHA-256 checksum is able to detect unauthorized changes to schema or data.
   5. Verify that the explainable anomaly detection framework can locate unusual migration activities and can also provide interpretable security explanations. Make a security control map for each threat that has been identified. Verify that all identified threats are adequately mitigated before you start migrating the database. The authors summarized the threat model and security controls in Table 2.
2. Transfer Database Schema. Extract schema definitions from the source PostgreSQL database. Validate schema compatibility with the target database environment. Verify table structures, primary keys, foreign keys, indexes, and constraints. Deploy validated schema definitions to the target database. Confirm successful schema deployment before transferring data.
3. Migrate healthcare data securely through encrypted communication channels while continuously monitoring migration activities.
   1. Configure the migration batch size to 10,000 records per transaction. Establish encrypted communication channels using TLS 1.3. Transfer data through private network endpoints within the virtual private cloud (VPC).
   2. Enable automatic retry attempts with a maximum of three retries for failed transactions.
      ​Maintain data-transfer throughput between 100 MB/s and 150 MB/s. Monitor migration activities continuously throughout the transfer process. Record all migration events in centralized audit logs.
4. Verify migration completeness and integrity by comparing checksums, record counts, and database structures.
   1. Generate SHA-256 hash values for all source tables before the migration, and SHA-256 hash values for all target tables after the migration. Match source and target checksum values. Cross-check row counts for source and target databases. Check consistency of schemas, table relationships, and database constraints. Consider migration as successful only when checksum values, record counts, and schema structures are identical.
5. Remove temporary privileges and finalize security controls after successful completion of data migration.
   1. Revoke all temporary migration credentials immediately after migration completion. Remove elevated migration privileges from service accounts. Archive audit logs and security monitoring records.
   2. Verify successful completion of backup procedures. Decommission temporary migration servers and supporting resources. Perform a final security review of the migrated environment. Document migration outcomes and validation results. The complete secure migration workflow used in this study is illustrated in Figure 3.

Threat Scenario	Security Control	Detection Method	Mitigation
Credential theft	Temporal Least Privilege (TLP)	IAM logs	Automatic credential revocation
Insider attack	Role-Based Access Control (RBAC)	Audit logs + SHAP	Session termination
Replay attack	TLS 1.3 + Nonce validation	Network monitoring	Reject duplicated requests
Man-in-the-Middle (MITM)	TLS 1.3 encryption	Certificate validation	Encrypted communication
Schema tampering	SHA-256 checksum + schema validation	Integrity verification	Restore validated schema
Privilege escalation	IAM policy enforcement	Security logs	Privilege revocation

Table 2:  Threat model and respective security measures taken in the migration framework proposed. The table outlines the main representative security threats and their corresponding mitigation mechanisms based on zero-trust security principles, encryption, identity management, integrity verification, monitoring, and explainable anomaly detection.

Figure 3: Workflow of the proposed secure cloud database migration protocol. The protocol consists of seven sequential stages: threat modeling, schema transfer, secure database migration, migrated data validation, post-migration hardening, audit logging and archival, and migration completion. Security monitoring, encrypted communication, identity management, immutable logging, and explainable anomaly detection are maintained throughout the migration workflow. This figure was created by the authors using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

6. Configure explainable AI monitoring

NOTE: The outline of the process is: identifying migration security characteristics, building a model to detect irregularities, recognizing when migration actions are suspicious, and producing explainable results through SHAP interpretation methods.

1. Extract and preprocess security telemetry features required for anomaly detection and explainability analysis.
   1. Collect security logs from database servers, authentication servers, application servers, and network monitoring systems. Aggregate all migration-related events into a centralized log repository. Remove duplicate records and incomplete entries. Synchronize timestamps across all log sources using coordinated universal time (UTC).
   2. Calculate access frequency for each user during migration operations. Record the number of failed login attempts associated with each account. Monitor changes in source IP addresses throughout migration sessions.
   3. Measure user session duration from login initiation to termination. Calculate inbound and outbound data transfer volumes during migration activities. Normalize all extracted features using Min-Max normalization.
   4. Table 3 summarizes the security features used for anomaly detection and explainability analysis.
2. Train and validate the Isolation Forest model using the prepared security feature dataset.
   1. Partition the dataset. Randomly divide the dataset into Training set (70%), Validation set (15%), and Testing set (15%). Maintain a consistent distribution of normal and anomalous events across all subsets.
   2. Explainable AI Model Selection. Select the Isolation Forest algorithm because it efficiently detects anomalous migration activities without requiring labeled training data. Use the algorithm to isolate abnormal observations through recursive random partitioning of the feature space. 
   3. Apply SHAP TreeExplainer to quantify the contribution of each security feature to the anomaly prediction and improve transparency of the security monitoring process.
   4. Configure the anomaly detection model. Initialize an Isolation Forest model. Configure the model using the parameters listed in Table 4.
   5. Define the mathematical formulation used to calculate anomaly scores and explain feature contributions.
      1. Define the security feature vector for each migration event as shown in Equation 1.
         x_i = [x₁ , x₂, x₃, x₄, x₅ ] (1)
         where x₁ denotes access frequency, x₂ denotes failed login count, x₃ denotes IP address change frequency, x₄ denotes session duration, and x₅ denotes data transfer volume.
      2. Extract the security features from migration logs. Normalize all feature values before model training. Calculate the Isolation Forest anomaly score for each migration event using Equation 2.
             (2)
         where S(X,n) denotes anomaly score of observation X, X denotes security feature vector, E(h(X)) is expected path length of observation X, c(n) is average path length of unsuccessful searches in a binary search tree, and n is the total number of training samples. The normalization factor is calculated as shown in Equation 3.
            (3)
         where H(n-1) denotes  the (n-1)th harmonic number. 
      3. Classify migration events with anomaly scores greater than the predefined decision threshold as anomalous.
      4. Apply SHAP (SHapley Additive exPlanations) to explain the contribution of each security feature to the anomaly prediction. Calculate the SHAP value for feature i using Equation 4.
            (4)
         where (F) denotes the complete feature set, (S) denotes a subset of features, and (f(.)) denotes the Isolation Forest prediction function.
      5. Calculate the global feature importance by computing the mean absolute SHAP value using Equation 5.
             (5)
         ​where (N) denotes the total number of migration events.
      6. Rank the security features according to their mean absolute SHAP values. Generate SHAP summary plots, dependence plots, and force plots to visualize global and local feature importance.
   6. Train the Isolation Forest model using the training dataset. Evaluate model performance using the validation dataset. If it is necessary, change the contamination thresholds. Store the model configuration that performs the best. Validate model performance. Determine metrics like accuracy, precision, recall, F1-score, and ROC-AUC. Note down the model performance measures for later comparison.
3. Apply the trained model to identify abnormal migration events and classify suspicious activities.
   1. Perform anomaly prediction. Apply the trained Isolation Forest model to the testing dataset. Generate anomaly scores for all migration events.
   2. Identify suspicious activities. Determine if migration events are typical or anomalous. Mark as suspicious those events that surpass predetermined anomaly levels. Produce anomaly documentation for security scrutiny.
   3. Completion of the anomaly detection process yields anomaly scores, labels migration events as normal or anomalous, measures detection effectiveness through ROC analysis, and spots key security anomalies. Samples of outputs produced by the designed process are shown in Figure 4.
   4. Categorize detected anomalies. Classify anomalies into authentication anomalies, network anomalies, session anomalies, and data-transfer anomalies. Keep the anomaly labels for the explanation analysis.
   5. Evaluate detection performance. Check the recorded security incidents to date. Then, using them as a reference, evaluate the anomalies that have been detected and figure out which of the two were true anomalies. Determine the rate at which anomalies are detected and the rate of false positives. Make an official record of the documentation of detection accuracy to be able to reproduce it.
4. Generate SHAP-based explanations to interpret the contribution of individual security features to anomaly predictions.
   1. Configure the SHAP environment. Load the trained Isolation Forest model. Initialize SHAP TreeExplainer. Verify successful integration between the anomaly detection model and the explainability framework.
   2. Select background samples. Randomly select 1,000 representative samples from the training dataset. Use the selected samples as the SHAP background dataset. Calculate SHAP values. Compute SHAP values for all detected anomalies. Measure individual feature contributions to anomaly predictions. Store SHAP outputs for further analysis.
   3. Generate global explanations. Create SHAP summary plots showing overall feature importance. Generate SHAP bar charts based on mean absolute SHAP values. Produce SHAP dependence plots for highly influential features.
   4. Generate local explanations. Select representative anomalous migration events. Create SHAP force plots and waterfall plots. Visualize feature contributions responsible for each anomaly.
   5. Representative explainability outputs generated during the interpretation process are shown in Figure 5. These visualizations demonstrate global feature importance, feature contribution rankings, dependence relationships between influential security features, and local explanations for individual migration anomalies.
   6. Rank security features. Calculate mean absolute SHAP values for all features. Rank features according to their contribution to anomaly detection. Identify the most influential security indicators affecting migration security. Table 5 summarizes the SHAP-based feature importance rankings.
   7. Validate explanation consistency. Repeat SHAP analysis across five independent experimental runs. Measure explanation stability and consistency. Verify that feature rankings remain stable across repeated analyses.
      NOTE: Table 6 provides common issues encountered during explainable anomaly detection and recommended corrective actions.

Feature	Description	Purpose
Access Frequency	Number of user access requests during migration	Detect abnormal access behavior
Failed Login Count	Number of unsuccessful authentication attempts	Identify brute-force or unauthorized access attempts
IP Address Changes	Frequency of source IP address changes	Detect suspicious network behavior
Session Duration	Length of user sessions during migration	Identify abnormal session activities
Data Transfer Volume	Amount of data transferred during migration	Detect unusual data movement or exfiltration

Table 3:  Security telemetry features used for explainable anomaly detection. The table presents the security features that were monitored during the database migration, their meanings, the ways in which they were measured, and how they helped with anomaly detection and explainability analysis.

Parameter	Value	Description
Algorithm	Isolation Forest	Anomaly detection model
n_estimators	100	Number of isolation trees
contamination	0.02	Expected anomaly proportion
max_samples	Auto	Samples used per tree
random_state	42	Reproducibility seed
bootstrap	False	Sampling without replacement
Training Set	70%	Model training data
Validation Set	15%	Hyperparameter validation
Testing Set	15%	Final model evaluation

Table 4: Configuration of Isolation Forest used for detecting anomalies during secure database migration. This table details the hyperparameter setups of the Isolation Forest model for training, such as how the dataset was split, the level of contamination, the number of estimators, the random seed, and the evaluation setup.

Figure 4: Representative outputs of the anomaly detection framework during secure cloud data migration. (A) Distribution of Isolation Forest anomaly scores showing the anomaly threshold. (B) Classification of migration events into normal and anomalous categories. (C) Receiver operating characteristic (ROC) curve demonstrating the performance of the Isolation Forest model (AUC = 0.97 ± 0.01). (D) Representative anomalous migration events showing anomaly scores, predicted labels, influential security features, and anomaly categories. This figure was generated by the authors using Python 3.11 (Matplotlib 3.9) and formatted using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

Figure 5: Examples of SHAP-based explainability outputs produced during anomaly interpretation. (A) SHAP summary plot highlighting the most important features globally. (B) Ranking of security features based on their mean absolute SHAP value. (C) SHAP dependence plots demonstrating how the number of failed logins and the volume of data transfer affect the anomaly prediction. (D) SHAP force plot offering a local explanation for a typical abnormal migration event. These charts showcase the global and local interpretability of the proposed anomaly detection model. This figure was generated by the authors using Python 3.11 (Matplotlib 3.9) and formatted using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

Rank	Feature	Mean Absolute SHAP Value	Interpretation
1	Failed Login Count	0.352	Most influential indicator of anomalous activity
2	Data Transfer Volume	0.287	Strong contributor to anomaly detection
3	IP Address Changes	0.221	Indicates suspicious network behavior
4	Session Duration	0.184	Associated with abnormal user sessions
5	Access Frequency	0.156	Reflects unusual access patterns

Table 5:  SHAP feature importance scores of security telemetry data. The table shows security feature ranking according to their mean absolute SHAP values and outline their respective contributions to the prediction of anomalies.

Issue	Possible Cause	Recommended Solution
Few anomalies detected	Contamination parameter too low	Increase the contamination threshold and retrain the model.
High false-positive rate	Noisy or inconsistent migration logs	Clean log data and normalize security features before model training.
Unstable SHAP explanations	Insufficient background samples	Increase the number of representative background samples used by SHAP.
Poor anomaly detection accuracy	Feature imbalance or inadequate preprocessing	Apply feature normalization, balancing, and quality-control procedures.
Slow model convergence	Large dataset or limited computational resources	Optimize hyperparameters or use GPU/parallel processing.
Communication failures	Network instability during monitoring	Verify secure communication channels and repeat synchronization.
Missing security features	Incomplete log collection	Validate log sources before feature extraction and regenerate the feature dataset.

Table 6: Guide for troubleshooting Explainable Artificial Intelligence-based secure database migration. This table provides a summary of typical implementation problems, possible reasons, diagnostic signs, recommended actions, and outcomes expected as a result of protocol execution and reproducibility.

7. Performance evaluation

NOTE: This section describes the experimental procedure used to compare the baseline migration framework with the proposed zero-trust explainable AI-based migration framework. Performance evaluation includes security, anomaly detection capability, migration efficiency, and statistical validation under identical experimental conditions.

1. Configure both the baseline and proposed environments under identical conditions to enable a fair performance comparison.
   1. Configure the conventional migration environment. Configure long-term static credentials with a validity period greater than 24 h. Enable public network endpoints for database access. Disable AI-based anomaly detection and explainability mechanisms. Monitor migration activities manually using conventional security logs. Record migration events for subsequent performance comparison.
   2. Configure the Zero-Trust migration framework. Enable temporal least-privilege credentials with automatic expiration after migration completion. Disable all public network endpoints. Enable private network communication using secure channels.
   3. Deploy the trained Isolation Forest anomaly detection model. Enable SHAP TreeExplainer for model interpretation. Configure automated security monitoring throughout the migration process. Verify secure communication between all migration components before execution.
2. Perform repeated migration experiments under controlled conditions to evaluate framework reproducibility.
   1. Perform migration experiment. Conduct ten independent migration experiments for both the baseline and proposed environments. Maintain identical hardware, software, and network configurations throughout all experiments.
   2. Migrate 10 GB of healthcare data during each experimental run. Repeat all experiments under identical workload conditions. Record security events, migration logs, anomaly detection outputs, and execution times during every experiment.
   3. Validate migration integrity. Calculate SHA-256 checksums before and after migration. Verify complete data integrity after every migration experiment. Document checksum validation results.
3. Calculate quantitative security, migration, and anomaly detection metrics for comparative evaluation.
   1. Measure security performance. Measure credential exposure duration. Calculate the number of exposed credentials during migration. Measure incident detection time. Record public network exposure duration.
   2. Evaluate anomaly detection performance. Calculate anomaly detection accuracy,  precision, recall, F1-score, and area under the receiver operating characteristic curve (AUC). Evaluate migration performance. Measure total migration latency and calculate migration throughput. Record communication overhead introduced by security mechanisms.
   3. Perform statistical validation. Calculate the mean and standard deviation for all performance metrics. Compute 95% confidence intervals. Perform paired Student's t-tests to compare the baseline and proposed frameworks. Consider statistical significance at p < 0.05. Representative performance evaluation results generated during the experimental comparison are shown in Figure 6.
   4. Table 7 summarizes the quantitative performance comparison between the baseline and the proposed migration framework.
      Table 8 summarizes common implementation issues encountered during secure database migration, their possible causes, and recommended corrective actions.

Figure 6: Performance comparison between the baseline migration framework and the proposed zero-trust, explainable AI-enabled secure cloud migration framework. (A) Comparison of credential exposure duration using long-term and temporal least-privilege credentials. (B) Comparison of anomaly detection performance metrics, including accuracy, precision, recall, F1-score, and AUC. (C) Comparison of migration latency across ten independent experimental runs, showing that the latency increase remained below the predefined acceptance threshold. (D) Statistical comparison of key performance metrics using paired Student's t-tests, showing mean differences and 95% confidence intervals. Error bars represent 95% confidence intervals from ten independent experimental runs. This figure was generated by the authors using Python 3.11 (Matplotlib 3.9) and formatted using Microsoft PowerPoint (Microsoft 365). Please click here to view a larger version of this figure.

Performance Metric	Baseline Framework (Mean ± SD)	Proposed Framework (Mean ± SD)	Improvement	95% Confidence Interval	p-value
Credential Exposure Duration (h)	24.70 ± 1.32	0.42 ± 0.18	98.3% reduction	23.6–24.9	<0.001
Anomaly Detection Accuracy (%)	72.4 ± 2.1	94.6 ± 1.3	+22.2%	20.8–23.5	<0.001
Precision (%)	68.1 ± 2.5	92.7 ± 1.5	+24.6%	23.1–26.0	<0.001
Recall (%)	70.3 ± 2.4	93.1 ± 1.6	+22.8%	21.4–24.2	<0.001
F1-score (%)	69.2 ± 2.2	92.9 ± 1.4	+23.7%	22.3–25.0	<0.001
AUC	0.78 ± 0.03	0.97 ± 0.01	+0.19	0.17–0.21	<0.001
Migration Latency (min)	87.6 ± 3.2	97.4 ± 2.9	11.2% overhead	8.9–10.7	0.002
Data Integrity (%)	99.8	100.0	0.2% improvement	0.1–0.3	0.031
Public Network Exposure	Enabled	Eliminated	100% eliminated	N/A	<0.001

Table 7: Baseline and proposed secure database migration frameworks: A performance comparison. The table displays credential exposure duration, anomaly detection effectiveness, migration latency, data integrity, and security enhancements assessed quantitatively during the protocol validation.

Issue	Possible Cause	Recommended Solution
Migration authentication failure	Expired or invalid temporary credentials	Regenerate temporal credentials and verify IAM policies before restarting migration.
High migration latency	Network congestion or insufficient bandwidth	Optimize network routing, schedule migration during low-traffic periods, and verify endpoint connectivity.
False-positive anomaly alerts	Improper Isolation Forest contamination threshold	Tune contamination parameter using the validation dataset and retrain the model.
Unstable SHAP explanations	Insufficient or non-representative background samples	Increase the SHAP background sample size and ensure representative sampling.
Data integrity mismatch	Interrupted migration or corrupted data transfer	Re-run migration after validating SHA-256 checksum values and source/target consistency.
Secure endpoint connection failure	Firewall or TLS configuration errors	Verify SSL/TLS certificates, firewall rules, and private endpoint configuration.
Low anomaly detection accuracy	Incomplete feature extraction or poor preprocessing	Review feature engineering, normalize security features, and retrain the model.
Model convergence issues	Inappropriate hyperparameters	Adjust learning parameters and validate model performance before deployment.

Table 8: Troubleshooting guide for secure healthcare database migration. The table lists frequent migration errors, their possible roots, corrective measures advised, and expected results to ensure a reliable execution of the secure migration protocol.

Results

Experimental overview

The proposed explainable artificial intelligence (XAI)-enabled secure cloud data migration protocol was evaluated using a synthetic healthcare dataset comprising approximately 20 million electronic health record (EHR) records distributed across 28 relational database tables, totaling 10 GB. The experiments were conducted in an Amazon Web Services (AWS) cloud environment using Amazon RDS PostgreSQL 16, private Virtual Private Cloud (VPC) networking, TLS 1.3 encrypted communication, and centralized monitoring services. Ten independent migration experiments were performed under identical hardware, software, network, and workload conditions to ensure reproducibility and minimize experimental bias. All reported performance values represented the mean of the ten experimental runs. Statistical significance was evaluated using paired Student's t-tests after verification of normality using the Shapiro-Wilk test (p < 0.05).

Results of dataset preparation and validation

The synthetic healthcare dataset was successfully generated according to the protocol specifications. Data validation confirmed the successful generation of approximately 20,000,000 patient-related records distributed across 28 relational tables, including patient demographics, clinical encounters, diagnoses, laboratory reports, medications, imaging metadata, billing information, and physician records. Primary-key uniqueness, foreign-key relationships, and referential integrity constraints were successfully verified before migration. Approximately 5% of the data values were intentionally left missing to simulate realistic electronic health record databases and were subsequently processed during data cleaning. Dataset quality assessment demonstrated successful schema validation, acceptable value ranges, and complete referential integrity. The cumulative dataset validation error remained below 0.1%, indicating that the generated dataset was suitable for secure migration experiments, as shown in Table 1.

Results of system architecture deployment

The secure migration architecture was successfully deployed and validated before execution of the migration workflow. All cloud resources are operated within an isolated AWS Virtual Private Cloud using private subnets, security groups, and identity-based access policies. Database communications were protected using TLS 1.3 encryption, and migration credentials were dynamically generated according to the temporal least-privilege policy. Authentication logs, migration logs, database events, network events, and security audit logs were continuously collected through Amazon CloudWatch. Throughout all experimental runs, communications occurred exclusively through private network endpoints, and no publicly accessible database services were detected. Continuous monitoring demonstrated stable communication among all migration components without unexpected service interruptions or authentication failures, as shown in Figure 2.

Results of the secure migration workflow

Threat modeling

The predefined threat model successfully identified credential theft, insider attacks, replay attacks, man-in-the-middle attacks, schema tampering, and privilege-escalation scenarios. The implemented security controls effectively mitigated all identified threats before migration execution, as summarized in Table 2.

Database schema transfer

Database schema migration was successfully completed in all experimental runs. All relational tables, indexes, stored procedures, constraints, metadata, primary keys, and foreign keys were transferred without structural inconsistencies or schema drift.

Secure data migration

The migration process was completed successfully in all ten experimental runs without workflow interruptions or transaction failures. Secure data transfer was maintained throughout the migration process using encrypted communication channels over private network endpoints.

Migration validation

Post-migration validation confirmed complete consistency between the source and target databases. SHA-256 checksum verification produced 100% matching across all migrated tables, demonstrating that no data corruption occurred during transmission. Record-count validation confirmed successful migration of all 20 million records without loss, duplication, or truncation. Validation of primary keys, foreign keys, indexes, schema definitions, and database constraints confirmed complete preservation of database integrity. No schema drift, rollback events, transaction failures, or migration inconsistencies were observed throughout the evaluation period. Quantification of integrity results is given in Table 9.

Validation Metric	Observed Result	Acceptance Criterion	Status
Total healthcare records migrated	20,000,000	20,000,000	Passed
Relational database tables migrated	28	28	Passed
Dataset size migrated	10 GB	10 GB	Passed
SHA-256 checksum verification	100% match	100% match	Passed
Record-count consistency	100%	100%	Passed
Schema validation	All tables validated	No schema errors	Passed
Primary-key integrity	Verified	No violations	Passed
Foreign-key integrity	Verified	No violations	Passed
Data corruption rate	0%	0%	Passed
Schema drift	Not observed	None	Passed
Rollback events	0	0	Passed
Migration completion rate	100%	100%	Passed

Table 9: Data integrity validation results after secure database migration. It presents the main integrity verification metrics on the quantitative side. These include checking that the SHA-256 hash sums matched, the count of records was consistent, the schema was validated, key-constraint preservation, migration was completed, rollback events, and overall migration success of ten separate migration experiments.

Table 9 summarizes the quantitative data integrity validation results obtained after secure cloud data migration. The results demonstrated that all migration acceptance criteria were satisfied across the ten independent experimental runs.

Post-migration hardening

Temporal least-privilege credential management substantially improved credential security compared with the conventional migration framework. The average credential lifetime decreased from 24.7 ± 1.3 h in the baseline environment to 0.42 ± 0.18 h in the proposed framework, representing a 98.3% reduction in credential exposure duration. Temporary credentials were revoked immediately after migration completion, and no unauthorized authentication attempts using expired credentials were detected during any experimental run. Removing long-lived credentials reduced the potential attack surface while maintaining uninterrupted migration performance, as shown in Figure 3.

Results of explainable AI monitoring

Security feature extraction

Security telemetry was successfully collected from database servers, authentication services, application servers, and network monitoring systems. Feature extraction generated normalized measurements of access frequency, failed login count, IP address changes, session duration, and data transfer volume for anomaly detection, as described in Table 3.

Anomaly detection model performance

The isolation Forest model demonstrated robust anomaly-detection performance across 10 independent experiments. The average accuracy, precision, recall, F1-score, and area under the receiver operating characteristic curve (AUC) were 94.6 ± 1.3%, 92.7 ± 1.5%, 93.1 ± 1.6%, 92.9 ± 1.4%, and 0.97 ± 0.01, respectively. The model configuration followed the parameters summarized in Table 4.

Security anomaly detection

The proposed monitoring framework reduced the average incident detection time from more than 24 h in the baseline environment to approximately 15 min. False-positive detections remained below 3%, and no critical migration failures remained undetected throughout the evaluation period. Representative anomaly detection outputs are presented in Figure 4.

Explainability analysis

SHAP TreeExplainer generated interpretable feature-attribution results for all detected anomalies. A background dataset containing 1,000 representative training samples was used to calculate SHAP values. Global explanation analysis consistently identified failed login count, data transfer volume, IP address changes, session duration, and access frequency as the most influential features contributing to anomaly predictions. Repeated explainability analysis across ten experimental runs produced nearly identical feature rankings, demonstrating stable model interpretation. Local SHAP explanations further identified the principal factors contributing to individual anomaly predictions, thereby improving transparency of the security monitoring process. Representative explainability outputs are shown in Figure 5, while the corresponding feature importance rankings are summarized in Table 5.

Results of performance evaluation

Comparison with the baseline migration framework demonstrated substantial improvements across multiple security metrics. Credential exposure duration decreased by 98.3%, anomaly detection accuracy improved from 72.4 ± 2.1% to 94.6 ± 1.3%, and publicly accessible migration endpoints decreased from six to zero. The average incident detection time was markedly reduced while complete migration integrity was maintained throughout the evaluation. Although additional security controls increased migration latency by 11.2 ± 2.9%, the observed increase remained below the predefined acceptance threshold of 15%, indicating that security improvements were achieved with minimal impact on migration efficiency. Representative performance evaluation results are presented in Figure 6, and the quantitative comparison between the baseline and proposed frameworks is summarized in Table 7.

Statistical validation and reproducibility

Statistical analysis demonstrated significant improvements in credential exposure duration, anomaly detection accuracy, incident detection time, and migration latency between the baseline and proposed frameworks (paired Student's t-test, p < 0.05). The calculated 95% confidence intervals showed low variability across the 10 independent experimental runs, confirming the reproducibility and stability of the proposed protocol. Detailed results of each experiment are given in Table 10.

Experimental Run	Credential Exposure Duration (h)	Anomaly Detection Accuracy (%)	Migration Latency (min)	SHA-256 Validation	Migration Status
Run 1	0.45	94.3	96.8	Passed	Successful
Run 2	0.41	95	98.2	Passed	Successful
Run 3	0.39	94.7	95.9	Passed	Successful
Run 4	0.44	94.5	97.6	Passed	Successful
Run 5	0.43	94.8	96.9	Passed	Successful
Run 6	0.4	94.2	98.5	Passed	Successful
Run 7	0.42	95.1	97.2	Passed	Successful
Run 8	0.38	94.6	96.7	Passed	Successful
Run 9	0.43	94.9	97.8	Passed	Successful
Run 10	0.41	94.5	97	Passed	Successful
Mean ± SD	0.42 ± 0.02	94.66 ± 0.29	97.26 ± 0.80	100% Passed	10/10 Successful

Table 10:  Experimental reproducibility over ten separate migration runs. The table presents a summary of the time interval during which a credential was exposed, the precision of detecting anomalies, the delay of a migration, the status of the SHA-256 validation, and the success of the migration for each experimental run, thus demonstrating the stability and reproducibility of the proposed secure cloud migration framework under the same experimental conditions.

Table 10 presents the detailed results of all ten independent experimental runs, demonstrating the consistency, stability, and reproducibility of the proposed secure cloud migration protocol under identical experimental conditions.

The experimental evaluation demonstrated that integration of zero-trust security, temporal least-privilege access control, continuous anomaly monitoring, and SHAP-based explainability improved migration security while maintaining complete database integrity and acceptable migration performance. Because the experiments were conducted using a synthetic healthcare dataset within a controlled cloud environment, these findings should be interpreted within the evaluated experimental configuration. Additional validation using operational healthcare infrastructures, real clinical datasets, and multi-institutional cloud environments will be required before generalizing the protocol for routine deployment in production healthcare systems.

Discussion

In this research, a reproducible, secure cloud database migration protocol was developed that incorporates zero-trust security principles, time-based least-privilege access control, explainable artificial intelligence (XAI), and continuous security monitoring, all within a restricted experimental setup. Using a new migration algorithm was not the intention of this paper; therefore, the authors primarily present a standardized workflow that makes it possible for researchers and practitioners to perform, assess, and reproduce secure healthcare database migration through clearly articulated procedural steps. The success of implementing the protocol relies on the careful performance of a few very important steps. Threat modeling with high precision is a great help in getting to know the assets going to migration, the ways in which the attackers might get in, and the set of security controls that will be effective, all of which are done prior to migration. Database schema validation is one step that must be accomplished before data transfer so as to avoid structural inconsistencies and schema drift. Migration-wise, temporary credentials need to be produced following the principle of temporal least-privilege, the use of the cryptographic protocol TLS 1.3 for securing communication needs to be kept, and migration logs should be gathered without stopping so that they can be used for security monitoring and auditing. Migration environment has been emptied, abandoning it is only going to be right when the tasks such as SHA-256 checksum verification, record-count validation, and schema consistency checks have been done, which show that database integrity has been preserved.

The explainable anomaly monitoring component also requires careful configuration steps to achieve reproducible results. Among the important factors that influence anomaly detection performance and explanation quality are the selection of appropriate security telemetry features, consistent preprocessing of monitoring logs, suitable Isolation Forest hyperparameters, and a representative SHAP background dataset. Changes in these configuration settings may result in changes to anomaly scores, feature attribution values, and overall model interpretability. Hence, it is advisable for researchers that the software versions, model parameters, and evaluation settings should remain identical for reproducing the protocol.

Protocol troubleshooting procedures are designed to help users address common implementation problems like schema incompatibilities, network interruptions, authentication failures, excessive false-positive detections, and migration latency overhead. Validation systematically after each protocol step will be able to locate these problems and also correct them before running the next steps of migration. This is one of the ways to enhance the reliability and reproducibility of the experimental workflow.

Although the experimental evaluation demonstrated that the tested setup could enhance credential protection, anomaly detection, explainability, and migration integrity, the findings should be regarded as specific to the scope of this research only. The protocol was only tested with a synthetic healthcare dataset in a cloud lab environment and not in a real healthcare information system. The results presented here should not be considered as proof of regulatory compliance or clinical use. Instead, they indicate that the technique can be implemented in a controlled lab environment and provides a framework that can be used by others for further validation studies.

Several recent studies have investigated secure healthcare cloud migration, zero-trust security architectures, and explainable artificial intelligence; however, most have focused on individual security mechanisms rather than an integrated and reproducible migration workflow. The NIST Zero Trust Architecture provides comprehensive guidance for continuous identity verification and least-privilege access control, but does not define a standardized protocol for secure database migration or explainable security monitoring during migration¹. Similarly, existing healthcare cloud migration frameworks primarily emphasize cloud adoption, encryption, governance, and regulatory compliance but provide limited procedural guidance for secure migration execution, validation, and reproducibility^7,8,9. AI-driven cloud security approaches have demonstrated improved anomaly detection capabilities through machine learning-based intrusion detection and security monitoring; however, these methods generally focus on detection performance without incorporating interpretable explanations to support security auditing and administrative decision-making^6,13. Explainable artificial intelligence techniques such as SHapley Additive exPlanations (SHAP) and Local Interpretable Model-agnostic Explanations (LIME) have significantly improved the transparency of machine learning predictions^17,18,19,20, but their application has largely been limited to model interpretation rather than integration into end-to-end secure cloud migration workflows. In contrast, the proposed protocol combines zero-trust architecture, temporal least-privilege credential management, encrypted database migration, SHA-256 checksum-based integrity verification, continuous centralized monitoring, Isolation Forest-based anomaly detection, and SHAP-based explainability within a single standardized and reproducible workflow. This integrated framework enhances transparency, auditability, and reproducibility while maintaining complete migration integrity and acceptable migration latency under the evaluated experimental conditions.

Nevertheless, there are many limitations that have to be considered when interpreting the results of this protocol. First of all, the evaluation was carried out using a synthetic dataset that might not capture the full complexity, variability, and security challenges of real clinical databases. Secondly, the protocol was only tested in a single controlled cloud environment, performance may vary in other cloud providers, database platforms, or network infrastructures. Thirdly, while the authors used a traditional migration workflow as a control, comparing their results with other secure migration methods and cloud security architectures would be beneficial for future studies. Fourthly, statistical validation was done on ten independent migration experiments only; larger-scale studies might give a better indication of the protocol's robustness. Fifthly, the authors have not explicitly considered adversarial attack scenarios like credential theft, insider threats, ransomware, or advanced persistent attacks, which should be the focus of future research. Finally, the proposed framework will only be as good as the configuration of identity management policies, anomaly detection parameters, logging infrastructure, and explainability settings; if the configurations are incorrect, both migration security and monitoring performance will be negatively affected.

Generally, this protocol offers a framework and a method that can be repeated for the study of secure cloud database migration by means of explainable artificial intelligence in research environments with controls. The validation and verification of the protocol could be performed by future work via running the healthcare information systems in operation, using a variety of cloud platforms, different database technologies, and authentic clinical datasets for the assessment of the scalability, generalizability, and practical applicability of the protocol.

This paper describes a reproducible method for secure cloud database migration that combines zero-trust security principles, temporary least-privilege access control, explainable artificial intelligence (XAI), and continuous security monitoring in a controlled cloud environment. The method specifies in detail the steps of dataset preparation, threat modeling, secure migration, integrity verification, anomaly detection, explainability analysis, and performance evaluation. Experiments on a synthetic healthcare dataset have shown that the protocol can enhance the security of credentials, maintain the integrity of the migration, detect anomalies accurately, and monitor security in an interpretable manner while keeping the migration latency at an acceptable level. The standardized procedure is aimed at making the implementation and evaluation of secure cloud migration strategies more reproducible in academic settings.

The results should be taken within the limits of the tightly controlled experimental setting that was used for this study. Since the protocol was tested with a synthetic healthcare dataset instead of a real healthcare information system, the results should not be seen as indicators of clinical deployment, regulatory compliance, or large-scale production implementation. Subsequent research efforts should focus on the use of actual healthcare settings, different cloud platforms, various database technologies, and larger clinical datasets to test further the protocol's versatility, reliability, and usefulness in practice.

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
AES Encryption	NIST	AES-256	Data-at-rest encryption
Amazon RDS PostgreSQL	Amazon Web Services	PostgreSQL 16	Target database
Cloud Platform	Amazon Web Services	AWS	Cloud infrastructure
CloudWatch	Amazon Web Services	Latest Stable Release	Monitoring and logging
Docker	Docker Inc.	27.0	Containerization
Faker	Faker Developers	30.0	Synthetic data generation
GPU	NVIDIA	RTX 4090	24 GB VRAM
Matplotlib	Matplotlib Developers	3.9	Visualization
NumPy	NumPy Developers	1.26	Numerical processing
Operating System	Canonical	Ubuntu 22.04 LTS	System environment
Pandas	PyData	2.2	Data processing
PostgreSQL	PostgreSQL Global Development Group	16	Source database
Python	Python Software Foundation	3.11	Programming language
Scikit-learn	Scikit-learn Developers	1.5	Machine learning
SHAP	SHAP Developers	0.46	Explainable AI
Terraform	HashiCorp	1.8	Infrastructure provisioning
TLS	IETF	TLS 1.3	Data-in-transit encryption
Virtual Private Cloud	Amazon Web Services	VPC	Private network environment
Workstation	Dell/HP	NA	Intel Xeon Gold 6226R, 64 GB RAM, 1 TB SSD