Transactional CRUTD Protocol

• Transactional CRUTD Protocol is an extension of CRUD that integrates physical transfers, ensuring atomicity, consistency, isolation, and durability in lab operations.
• It implements a two-phase commit process with pre/post-condition checks, meticulous locking, and rollback mechanisms to maintain state integrity.
• The protocol synchronizes digital twins with physical devices via ROS 2, enabling robust error handling and seamless recovery in dynamic laboratory environments.

The transactional CRUTD protocol is a reconciliation and orchestration layer introduced in UniLabOS, an AI-native operating system for autonomous laboratories. CRUTD extends the classic database CRUD interface by elevating Transfer (physical material movement) to a first-class, transactional primitive alongside Create, Read, Update, and Delete. It unifies digital state transitions and embodied, physical experiments by ensuring that every change to the laboratory’s logical and physical resources is atomic, consistent, isolated, and durable, even under network partitions, hardware failures, and concurrent activity. The protocol is implemented atop ResourceDict collections and is tightly coupled to device actuation via ROS 2, enabling robust coordination and digital-twin synchronization across heterogeneous laboratory infrastructure (Gao et al., 25 Dec 2025).

1. Definition and ACID-Style Guarantees

CRUTD stands for Create, Read, Update, Transfer, Delete. This extends the canonical CRUD (Create, Read, Update, Delete) interface by incorporating Transfer as a transactional operation involving physical actuation:

• Create (C): Instantiates new resources in the laboratory’s digital model.
• Read (R): Queries current resource states.
• Update (U): Modifies digital attributes of existing resources.
• Transfer (T): Moves physical material between resources (e.g., vials, wells) as a tightly coupled operation between digital state and material flow.
• Delete (D): Removes resources, retiring both their digital and physical presence.

In the laboratory context, CRUTD is endowed with ACID-style guarantees:

ACID Property	Laboratory Interpretation	Mechanism
Atomicity	All-or-nothing material ops	Two-phase commit
Consistency	Digital & material validity	Pre/post-conditions
Isolation	No interference between transactions	Resource-level locks
Durability	Changes survive failures	Event log/provenance

Atomicity ensures that each operation, particularly Transfer, either fully reconciles digital and physical state or reverts both. Consistency ties every operation to material balances and connectivity constraints. Isolation relies on locking at the resource (node) level. Durability is achieved by appending every event to the ResourceDict store (the provenance graph), making changes persistent across host crashes or restarts.

2. Two-Phase Commit Specification and Reconciliation Logic

The laboratory’s state is modeled as $S \in \mathrm{ResourceDictCollection}$, with each ResourceDict having (config, data, extra, version counter). A transaction $T$ is a sequence of CRUTD primitives ($op_1, \ldots, op_n$), each associated with pre-condition $P_i$ and post-condition $Q_i$.

For $Transfer(src, dst, v)$:

Pre-condition (Material Feasibility):

$$P_t(src, dst, v) \equiv \big(src.data.volume \geq v \big) \land \big(dst.data.volume + v \leq dst.config.max\_volume\big) \land \big((src, dst) \in E_{PhysicalGraph}\big)$$

Post-condition (State Consistency):

$$Q_t(src, dst, v) \equiv src.data.volume' = src.data.volume - v \land dst.data.volume' = dst.data.volume + v \land dst.parent\_uuid = dst.parent\_uuid$$

Two-phase Reconcile Pattern:

• Phase 1: Plan & Validate
  • Acquire locks on $src$ and $dst$.
  • Check $P_i$ under current $S$.
  • Reserve digital state tentatively.
• Phase 2: Execute & Confirm
  • Dispatch actuation commands (e.g. aspirate, dispense).
  • Await device feedback and optionally sensor readings.
  • Verify post-condition $Q_i$.
  • If satisfied: persist changes, increment version counters, release locks.
  • If failed: rollback to previous $S$, release locks, emit error event.

A state-machine abstraction:

$s_0 \xrightarrow[\text{lock} %%%%14%%%% P_t?]{\ } s_0^* \xrightarrow[\text{actuate}]{\ } s_1^* \xrightarrow[Q_t?]{\ } s_1$; if $Q_t$ fails, revert to $s_0$.

3. Integration with Laboratory Dual-Topology Models

UniLabOS implements a dual-topology paradigm for laboratory resource management:

• Logical Resource Tree ($T_l$): Encodes containment and ownership, such as "vials on decks" or "decks on devices". Transfer can be interpreted as reparenting a node by updating its parent_uuid.
• Physical Connectivity Graph ($G_p$): Encodes feasible material transfers, including tubing, robotic reachability, and machine connectivity. Only permissible transfers, with $(src, dst) \in E(G_p)$, are committed.
• Digital-Twin Synchronization: Every CRUTD event is timestamped and published to the ROS 2 topic bus, guaranteeing that 3D simulators and planning agents have a consistent, up-to-date view of $T_l \cup G_p$.

This implementation ensures that digital operations (in ResourceDict) are always synchronized with embodied material state, enforcing strong provenance and repeatability.

4. Failure Detection, Handling, and Recovery Mechanisms

The CRUTD protocol incorporates multiple safeguards against operational failures:

• Fine-Grained Locking: Each ResourceDict node carries an in-memory lock; transactions contend only for resources they touch, enforcing mutual exclusion.
• Version Numbers: Every commit increments a record’s version; locking plus version checks implements optimistic concurrency, aborting and retrying on race conditions.
• Two-phase Commit Rollback: On device failure or post-condition mismatch (e.g., sensor does not read expected volume), all tentative changes are reverted, and a structured error event with full provenance is emitted.
• Network-Partition Tolerance: Host nodes queue CRUTD operations per device. In WAN failures, hosts continue executing queued jobs locally. Reconnection triggers handshake and subtree resynchronization (merging UUIDs and version vectors).
• Isolated Task Queues: In multi-host deployments, sites losing connectivity pause their local queue while others proceed independently. Recovery involves reconciling only the impacted subtrees.

A plausible implication is that the protocol can maintain experiment integrity and recover gracefully even under both device and network faults.

5. Representative Liquid-Handling Example

The concrete implementation in UniLabOS is illustrated with a liquid-handling transfer, in which $v$ units are moved from Well A to Well B:

def transfer_liquid(src_uuid, dst_uuid, v): # Phase 1: Plan & Validate src = get_resource(src_uuid) dst = get_resource(dst_uuid) with lock(src_uuid), lock(dst_uuid): assert src.data.volume >= v, "Insufficient volume" assert dst.data.volume + v <= dst.config.max_volume, "Capacity exceeded" assert (src_uuid, dst_uuid) in physical_graph.edges # Reserve digital state tentatively src.data.volume -= v dst.data.volume += v src.version += 1; dst.version += 1 # Phase 2: Execute & Confirm cmd = PumpCommand(aspirate=v, source=src.location, dispense=v, target=dst.location) result = send_to_device(cmd) # long-running ROS 2 Action if not result.success: rollback(src_uuid, dst_uuid) raise TransferError("Device actuation failed") # Optional sensor check measured = read_sensor(dst_uuid, 'volume') if abs(measured - dst.data.volume) > v * 0.05: rollback(src_uuid, dst_uuid) raise TransferError("Post-condition mismatch") # Commit is implicit because we already updated data # Finalize and publish provenance emit_crutd_event('Transfer', src_uuid, dst_uuid, v)

Here, locks implement resource-level isolation, tentative updates occur under lock, and after device and sensor validation, the state becomes permanent and is published to the event log.

6. Performance, Robustness, and Empirical Observations

UniLabOS reports qualitative performance and robustness metrics for CRUTD without publishing raw throughput numbers. Key findings include:

• Peer-to-peer DDS messaging yields sub-100 ms state update latencies under contention.
• Hosts can execute queued jobs offline for tens of minutes during cloud disconnections.
• In the distributed electrolyte foundry, queue pausing and site independence are supported; when network connectivity resumes, only changed subtrees are resynchronized, with no observed data loss.
• Multi-node contention scenarios (e.g., decentralized compute-intensive closed loops) sustain control-loop latencies below 50 ms via direct sensor-compute P2P streams, maintaining control even during host unavailability.

Correctness is asserted through the two-phase protocol with pre/post-conditions; isolation is enforced by resource locks; durability by mandatory event logging. The system demonstrates robust orchestration and multi-node coordination in diverse laboratory automation settings (Gao et al., 25 Dec 2025).

A plausible implication is that the CRUTD protocol enables agent-ready, reproducible, and provenance-aware autonomous experimentation while assuring operational integrity across distributed and heterogeneous laboratory environments.