Protocol Dependence Graphs (PDGs)

• PDGs are labeled directed graphs that capture control-flow and data dependencies in protocols, enabling formal execution planning.
• They are constructed in three stages—syntax, semantics, and execution—to parse natural language, analyze reagent flows, and enforce spatial-temporal constraints.
• Extended variants like PS-PDGs support parallel execution by encoding order, atomicity, and dataflow constraints, significantly boosting parallelization efficiency.

A Protocol Dependence Graph (PDG) is a labeled directed graph that models the execution and data dependencies within a protocol, originating from natural-language instructions and formalized for machine interpretation. PDGs serve as a bridge from unstructured protocol descriptions to rigorous, executable representations suitable for automation—particularly in the context of self-driving laboratories and scientific workflows—while preserving the causality, consistency, and explicit knowledge required for empirical reproducibility (Shi et al., 2024). The PDG concept has also been adapted to capture parallel and hierarchical dependencies in compiler design, where variants such as the Parallel Semantics Program Dependence Graph (PS-PDG) encode the complete set of ordering, atomicity, and dataflow constraints necessary for semantically valid parallel execution (Homerding et al., 2024).

1. Formal Structure and Definition

The PDG for a protocol with $k$ ordered steps is given as $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$ where:

• $O = \{o_1, ..., o_k\}$: operation nodes, one per protocol step;
• $R = \{r_1, ..., r_m\}$: reagent-state nodes representing named inputs, intermediates, or outputs;
• $E_{\mathrm{op}} \subseteq O \times O$: control-flow edges encoding permitted execution orderings (sequential, branching, looping constructs);
• $E_{\mathrm{reg}} \subseteq O \times O$: data-dependence edges modeling reagent flows; $(o_i \to o_j) \in E_{\mathrm{reg}}$ iff $$\mathrm{Out}(o_i) \cap \mathrm{In}(o_j) \neq \varnothing$$;
• $$C = C_{\mathrm{op}} \cup C_{\mathrm{reg}} \cup C_s \cup C_t$$: constraints enforcing spatial (e.g., device capacity) and temporal (e.g., safety) consistency.

Operation nodes encode $\mathit{action}(o)$, $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$0, and $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$1; reagent nodes store $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$2, $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$3, and $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$4.

In the parallel programming domain, the PS-PDG generalizes the classical PDG, supporting additional node types (Instr, Hier), edge types (directed with data selectors, undirected mutual exclusion), node traits (Atomic, Orderless, Singular), parallel-semantic variables, and region/context labeling to exhaustively capture the semantics of parallel execution (Homerding et al., 2024).

2. PDG Construction Workflow

The PDG construction is performed in three fundamental stages:

1. Syntax-Level PDG (Operation Dependence Synthesis) Natural-language protocol text is parsed into a formal DSL via dependency parsing and few-shot NER, and a candidate DSL program is synthesized using an Expectation-Maximization (EM)-style procedure. Control-flow edges $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$5 are produced by compiling the DSL to an AST and performing in-order traversal to identify sequential, branch, and loop dependencies. The worst-case complexity is $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$6 for $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$7 steps with up to $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$8 parameters, although heuristic pruning enhances practical efficiency (Shi et al., 2024).
2. Semantics-Level PDG (Reagent Flow Analysis) Data-dependence edges $$\mathit{PDG} = (O, R, E_{\mathrm{op}}, E_{\mathrm{reg}}, C)$$9 are constructed by tracking reagent definitions and kills via an extended pushdown automaton, determining which operation produces (defines) and consumes (kills) each reagent. The computation follows a reaching-definitions schema, with the worst-case complexity of $O = \{o_1, ..., o_k\}$0; empirical data indicates that data kills are adjacent in $O = \{o_1, ..., o_k\}$190% of cases, yielding near-linear behavior (Shi et al., 2024).
3. Execution-Level PDG (Spatial-Temporal Dynamics) The static PDG is augmented with predicate constraints $O = \{o_1, ..., o_k\}$2 representing device limits, safety checks, and implicit context. Execution-level validation includes partial trace simulation to ensure that no protocol execution trace violates spatial or temporal requirements. This phase also exhibits $O = \{o_1, ..., o_k\}$3 complexity, reducible using context windows (Shi et al., 2024).

3. Node and Edge Types Across Stages

The following table summarizes node and edge types introduced at each PDG construction stage:

Stage	Node Types	Edge Types
Syntax	OperationNode $O = \{o_1, ..., o_k\}$4 (action, params, conds)	$O = \{o_1, ..., o_k\}$5 (seq), $O = \{o_1, ..., o_k\}$6 (branch)
Semantics	ReagentNode $O = \{o_1, ..., o_k\}$7 (name, qty, unit)	$O = \{o_1, ..., o_k\}$8 if $O = \{o_1, ..., o_k\}$9
Execution	ExecutionNode $R = \{r_1, ..., r_m\}$0, ConstraintNode $R = \{r_1, ..., r_m\}$1	ConstraintEdge $R = \{r_1, ..., r_m\}$2, $R = \{r_1, ..., r_m\}$3, $R = \{r_1, ..., r_m\}$4

Attributes are stage-dependent: syntax-level nodes express control logic; semantics-level nodes encode reagent state; execution-level nodes/edges attach capacity, safety, and temporal predicates (Shi et al., 2024). In the PS-PDG, nodes have types (Instr, Hier) and traits (Atomic, Orderless, Singular), edge kinds include context-annotated directed and undirected edges, and variables link with use/def hyperedges for fine-grained privatization/reduction semantics (Homerding et al., 2024).

4. Algorithms and Computational Complexity

Syntax-Level (Operation Dependence Synthesis)

Parsing and DSL synthesis are performed via dependency analysis and EM steps: $E_{\mathrm{reg}} \subseteq O \times O$8 Complexity: $R = \{r_1, ..., r_m\}$5 worst-case (Shi et al., 2024).

Semantics-Level (Reagent Flow Analysis)

An extended PDA manages reagent reaching-definitions and kills, emitting data dependences upon kill events. Complexity: $R = \{r_1, ..., r_m\}$6 worst-case; typically linear in realistic protocols (Shi et al., 2024).

Execution-Level (Constraint Simulation)

At each operation step, spatial and temporal constraints are enforced on the current execution context: $E_{\mathrm{reg}} \subseteq O \times O$9 Complexity: $R = \{r_1, ..., r_m\}$7 forward/backward, with optimizations possible (Shi et al., 2024).

For PS-PDGs, polynomial-time algorithms ($R = \{r_1, ..., r_m\}$8) construct the enriched graph from IRs annotated with parallel constructs by emitting nodes, analyzing traits, adding directed/undirected and use/def (U/D) edges, and constructing hierarchical contexts (Homerding et al., 2024).

5. Illustrative Examples

Protocol PDG Example (Self-Driving Laboratory)

Protocol excerpt: “Split the mixture equally into two 50 mL round-bottom flasks. Stir the mixture at room temperature for 5 min.”

• Syntax-level:
  • $R = \{r_1, ..., r_m\}$9: split(target=mixture, count=2, vol=50 mL)
  • $E_{\mathrm{op}} \subseteq O \times O$0: stir(target=mixture_split, temp=RT, time=5 min)
  • Control-flow: $E_{\mathrm{op}} \subseteq O \times O$1
• Semantics-level:
  • $E_{\mathrm{op}} \subseteq O \times O$2 flask1_mixture(50 mL), flask2_mixture(50 mL) $E_{\mathrm{op}} \subseteq O \times O$3
  • $E_{\mathrm{op}} \subseteq O \times O$4 flask1_mixture, flask2_mixture $E_{\mathrm{op}} \subseteq O \times O$5
  • Data-dependence: $E_{\mathrm{op}} \subseteq O \times O$6
• Execution-level:
  • Check: each flask capacity $E_{\mathrm{op}} \subseteq O \times O$7 mL; stirring at RT is safe.

The resulting PDG integrates both sequential and data dependences (Shi et al., 2024).

PS-PDG Example (Parallel Programming)

OpenMP-like code: $(o_i \to o_j) \in E_{\mathrm{reg}}$0 Construction yields:

• Nodes: instructions, hierarchical regions (for loop, critical section)
• Traits: orderless, atomic
• Directed edges: enforce correct data consumption (e.g., $E_{\mathrm{op}} \subseteq O \times O$8 for $E_{\mathrm{op}} \subseteq O \times O$9), reduction flow
• Undirected edges: atomicity/mutual exclusion within critical region
• Variables: $E_{\mathrm{reg}} \subseteq O \times O$0 (reducible), edges for use and definition

Any schedule obeying these constraints will be semantically correct under the program’s parallel execution model (Homerding et al., 2024).

6. Empirical Performance and Evaluation

Quantitative assessments in the context of laboratory protocols demonstrate that the automated PDG pipeline achieves translation performance at approximately 85% of expert quality, as measured by BLEU and ROUGE scores over JSON-serialized outputs. Statistically significant improvement was observed over leading baselines (t-test: $E_{\mathrm{reg}} \subseteq O \times O$1, $E_{\mathrm{reg}} \subseteq O \times O$2). The evaluation corpus comprised 75 protocols with a total of 1,166 steps across five scientific domains, benchmarked against cross-validated human annotations (Shi et al., 2024).

For the PS-PDG, empirical evaluation using the NOELLE LLVM-based auto-parallelizer on the NAS C-benchmarks (on a 56-core system) revealed that PS-PDGs offered on average 2.5$E_{\mathrm{reg}} \subseteq O \times O$3 more parallelization options than classic PDGs (PDG: $E_{\mathrm{reg}} \subseteq O \times O$4; PS-PDG: $E_{\mathrm{reg}} \subseteq O \times O$5 per loop) and improved ideal critical-path speedup by 30–60% across all benchmarks. On specific kernels, PS-PDGs enabled up to 8$E_{\mathrm{reg}} \subseteq O \times O$6 more parallelism compared to only 1.7$E_{\mathrm{reg}} \subseteq O \times O$7 from PDG (Homerding et al., 2024).

7. Theoretical Guarantees and Significance

The PDG formalizes all essential dependencies for execution planning, enabling the deterministic automation of complex protocols in empirical sciences. For PS-PDGs in the programming context, the structure is both sound and minimal: any parallel execution schedule that satisfies all PS-PDG constraints is semantically faithful to the original program, and every encoded constraint is provably necessary—removal of any single constraint enables existence of a schedule that can violate program semantics (Homerding et al., 2024).

Thus, PDGs, including their extended parallel forms, provide a foundational abstraction for both scientific laboratory automation and advanced program compilation, preserving correctness, efficiency, and the explicit formalization of implicit operational knowledge (Shi et al., 2024, Homerding et al., 2024).