Log2Plan: Test Planning & GUI Automation

• Log2Plan is a set of planning constructs that formalizes both logical test-plan generation and adaptive GUI automation.
• It employs Boolean dependencies, minimal Horn implications, and NP-hard ordering constraint optimization to infer redundant tests.
• It integrates task mining with two-level planning to create robust, personalized GUI automation workflows adaptable to deviations.

Log2Plan denotes two distinct planning constructs in recent research. In one usage, it designates a logical pipeline for generating expected-optimal test execution plans from Boolean dependencies among requirements, platforms, and test outcomes (Morciniec et al., 2016). In the other, it names an adaptive GUI automation framework that combines structured two-level planning with task mining over user behavior logs (Lee et al., 26 Sep 2025). The two usages arise in different domains—software test management and desktop GUI automation—but both turn structured intermediate knowledge into executable plans and both support adaptation when execution deviates from expectation or context.

1. Terminology and scope

A terminological distinction is necessary. The 2016 paper "A Logical Approach to Generating Test Plans" does not itself name its method "Log2Plan"; the label is used for the paper’s logical pipeline that converts Boolean knowledge about dependencies among test results, together with a user’s expectation of those results, into an expected-optimal test execution plan (Morciniec et al., 2016). By contrast, the 2025 paper is explicitly titled "Log2Plan: An Adaptive GUI Automation Framework Integrated with Task Mining Approach" and introduces a planner–executor architecture for robust GUI task automation (Lee et al., 26 Sep 2025).

Usage	Domain	Core representation
Logical pipeline	Test-plan generation	$\Phi_R \wedge \Phi_T \wedge \Phi_P$ and $Xpctd$
GUI framework	GUI automation	$D$, Task Groups, GlobalPlanner, LocalPlanner

The shared name can therefore be misleading if the application domain is not stated. In the testing literature, Log2Plan refers to logical entailment, redundancy, Horn implications, and ordering constraints. In GUI automation, it refers to Task Blocks, Task Groups, staged retrieval, and grounding from high-level actions to low-level GUI operations. This suggests a family resemblance at the level of planning abstraction rather than a single continuous research lineage.

2. Logical test-plan generation from Boolean dependencies

In the logical setting, the problem begins with a test suite $T=\{test_1,\dots,test_n\}$ in which each test case $test_i$ has a Boolean outcome $x_i \in \{true,false\}$, with $true$ denoting success and $false$ denoting fail (Morciniec et al., 2016). Requirements and test platforms induce logical dependencies among outcomes, and the objective is to minimize the number of actually executed tests by inferring as many outcomes as possible from already executed tests. A test is droppable when, given the logical model $\Phi$ and the observed outcomes so far $E$, its value is logically entailed: $Xpctd$0 or $Xpctd$1.

The formal model introduces Boolean variables for requirements $Xpctd$2, tests $Xpctd$3, and expectation variables $Xpctd$4. The formula $Xpctd$5 captures dependencies among requirements extracted from a structured requirements document with hierarchy parent and types $Xpctd$6. These dependencies include conjunctive implications such as $Xpctd$7 and disjunctive implications such as $Xpctd$8. The formula $Xpctd$9 links tests to requirements through the encoding

$D$0

when $D$1. Platform monotonicity is represented by $D$2, where comparable requirements across platforms yield implications of the form $D$3. During partial execution, the current test status is captured by $D$4, with $D$5 for successful tests and $D$6 for failed tests.

Expectation enters through $D$7 and the expectation model $D$8. If $D$9, then $T=\{test_1,\dots,test_n\}$0; if $T=\{test_1,\dots,test_n\}$1, then $T=\{test_1,\dots,test_n\}$2. A test plan $T=\{test_1,\dots,test_n\}$3 is a total order over $T=\{test_1,\dots,test_n\}$4, and its quality is evaluated under the expected outcomes by how many tests become inferable and can therefore be dropped. If an observed result deviates from expectation, the adaptation policy updates $T=\{test_1,\dots,test_n\}$5 and recomputes the ordering constraints and plan.

The logical approach is explicitly grounded in determinism and soundness assumptions. The model is assumed to encode implications, equivalences, and platform-related monotonicity soundly, so entailment corresponds to correct inference. Within that model, the algorithm is complete for discovering ordering constraints that guarantee redundancy under the expected outcomes.

3. Algorithmic pipeline, formal guarantees, and complexity

The logical Log2Plan pipeline proceeds in four stages (Morciniec et al., 2016). First, it computes dependencies between test results by building $T=\{test_1,\dots,test_n\}$6, eliminating requirement variables to obtain $T=\{test_1,\dots,test_n\}$7, converting $T=\{test_1,\dots,test_n\}$8 to CNF, and saturating the resulting clause set by resolution closure until a fixed point is reached. The result is a clause set representing all entailed dependencies among test results.

Second, it maps dependencies between test results to dependencies between expected results. Literals over test variables are replaced by literals over expectation variables according to $T=\{test_1,\dots,test_n\}$9: if a test is expected to succeed, $test_i$0 is replaced by $test_i$1 and $test_i$2 by $test_i$3; if a test is expected to fail, the polarity is reversed. Each clause is then rewritten as an implication over expectation variables.

Third, it infers ordering constraints from minimal Horn dependencies. Horn implications with exactly one positive literal on the right-hand side are retained, subsumed dependencies are removed, and each minimal Horn implication

$test_i$4

is converted into the ordering constraint $test_i$5. These constraints encode the ordering conditions under which the head test is guaranteed to become redundant when the antecedent tests are executed first and their outcomes match expectation.

Fourth, it computes an optimal plan $test_i$6 by selecting a maximum satisfiable subset of the ordering constraints. This is formulated as a variant of minimum feedback arc set in a directed hypergraph, which is NP-hard, after which topological sorting yields the final total order. The notion of optimality is precise: the plan maximizes the number of inferred ordering constraints that can be satisfied simultaneously and therefore maximizes the number of tests that can be dropped under expected outcomes.

The formal results are correspondingly strong. The soundness lemma states that if $test_i$7, then dropping the test preserves knowledge because every model of $test_i$8 assigns $test_i$9 the value $x_i \in \{true,false\}$0. The completeness theorem states that if there exists a sequence $x_i \in \{true,false\}$1 such that, under expected outcomes, $x_i \in \{true,false\}$2 is redundant after executing $x_i \in \{true,false\}$3, then the algorithm infers the Horn implication

$x_i \in \{true,false\}$4

and emits the corresponding ordering constraint. The optimality theorem then establishes that the plan produced from a maximum satisfiable subset of inferred ordering constraints maximizes the number of guaranteed redundant tests under expected outcomes.

A small worked example illustrates the mechanism. Given $x_i \in \{true,false\}$5, $x_i \in \{true,false\}$6, and $x_i \in \{true,false\}$7, resolution yields, among other clauses, $x_i \in \{true,false\}$8. Under an optimistic expectation assignment, the minimal Horn dependencies generate $x_i \in \{true,false\}$9, and a valid topological order is $true$0. If $true$1 executes successfully, then $true$2 and $true$3 become inferable, and $true$4 follows from $true$5; only $true$6 needs to be executed, whereas a naive plan would execute all four tests.

The computational cost is substantial. Quantifier elimination, CNF conversion, and resolution closure may all be exponential in the number of requirements and tests in the worst case. The maximum satisfiable subset problem over ordering constraints is NP-hard. The approach therefore relies on SAT solvers, quantifier-elimination techniques, resolution-based saturation, and hypergraph feedback arc set heuristics for practical use.

4. Adaptive GUI automation through task mining and two-level planning

The 2025 Log2Plan framework addresses a different planning problem: robust GUI task automation under UI variation, long-horizon workflows, and user-specific habits (Lee et al., 26 Sep 2025). Its stated motivation is that record-and-replay and template-driven systems break under layout changes and variant flows, while LLM- or VLM-based planner–executor agents suffer from brittle generalization, high latency, context-window pressure, and limited long-horizon coherence. The framework’s goals are robustness, adaptability, long-horizon coherence, personalization, and efficiency.

Its architecture combines task mining with a structured two-level planner. Raw GUI logs are pre-processed into Task Blocks of the form $true$7, using pattern rules that map variable-length traces to 19 predefined high-level GUI events. GPT-4o then organizes these blocks hierarchically into Task Groups labeled with $true$8, $true$9, $false$0, and $false$1, and segments them into numbered individual tasks. These Task Groups are embedded with text-embedding-ada-002, and retrieval uses cosine similarity

$false$2

together with staged diversity selection to retrieve $false$3 Task Groups. For each generated plan step, the system fetches the top-2 similar individual tasks.

High-level planning is performed by GlobalPlanner. Given a user command $false$4 and the retrieved Task Groups, it produces a task list $false$5, where $false$6. Low-level grounding is handled by LocalPlanner. For the current task $false$7, it inspects the GUI context $false$8, with $false$9, selects an appropriate task block from the task dictionary $\Phi$0, adapts object placeholders to the current interface, and emits a low-level action sequence $\Phi$1 together with a feasibility flag $\Phi$2.

Execution uses PyWinAuto and PyAutoGUI to perform low-level actions such as press, type, click, doubleclick, rightclick, drag, scroll, and focus. If $\Phi$3 is true, a pop-up requests manual input. Memory is maintained over retrieved patterns, component dictionaries, and per-step observations $\Phi$4. If a task becomes infeasible or fails, LocalPlanner can revise the selected block or request user assistance, and GlobalPlanner can be re-invoked with updated context and retrieved patterns. The framework formalizes this dynamic update as $\Phi$5.

A representative task dictionary entry is the Rename Task Block: $\Phi$6. For the command “Rename the paper about Multihead Attention to Transformer,” LocalPlanner grounds this block to $\Phi$7. This grounding illustrates the framework’s central claim: high-level action schemas are stable, while low-level objects are resolved against the current GUI context.

5. Evaluation, empirical behavior, and case studies

The 2025 framework is evaluated on 200 real-world tasks: 100 in-house, 50 sampled from Skyvern, and 50 from ScreenAgent (Lee et al., 26 Sep 2025). The environments span Local desktop apps, Web platforms, productivity software denoted App, and cross-application workflows denoted Crossover. The log base comprises approximately 20–21 hours of user activity, segmented into 141 interaction files across 12 sessions, with intentionally imbalanced domains to test generalization to unseen environments.

The principal metrics are task success rate $\Phi$8, average end-to-end execution time per task in seconds, subtask completion rate

$\Phi$9

averaged across 200 tasks, and long-horizon robustness stratified by low-level action sequence length.

System	SR	Avg sec/task
ReAct	18.0%	28.6
UFO2	46.5%	118.2
Log2Plan w/o TM	28.0%	44.2
Log2Plan	61.7%	80.0

Subtask completion further differentiates the methods: UI-TARS achieves 36.9%, UFO2 62.8%, Log2Plan w/o TM 58.7%, and the full Log2Plan system 93.4%. The ablation is important because it isolates the role of task mining: removing task mining reduces full success to 28.0% but still leaves 58.7% subtask completion, indicating that the two-level planning structure alone aids partial progress, while retrieval from mined patterns is responsible for much of the end-to-end gain. For long-horizon tasks, baselines degrade sharply as sequence length increases, whereas Log2Plan maintains over 60% success in the 25–30 and 30+ action bins.

The case studies emphasize cross-application composition and context-sensitive grounding. In the Word–Outlook lab meeting workflow, the command is to create a lab meeting note in Word using a template, schedule a meeting, invite team members, attach the note in Outlook, and send the item. Retrieval draws on frequency-based extraction, similarity-based adaptation, and context-aware reasoning, while the high-level plan proceeds through opening Word, opening the template, saving the note, switching to Outlook, creating a calendar item, adding attendees, attaching the note, and sending. Local grounding resolves concrete controls such as the “Attach” button and the file chooser. In the file-renaming example, success depends on resolving the current target by name and control-type rather than by absolute position, which the framework cites as a source of robustness under list reordering and mild UI variation.

6. Limitations, misconceptions, and relation to adjacent work

The two Log2Plan usages share a planning orientation but have different limitations and comparison points. In the logical test-planning pipeline, the optimized objective is the number of satisfied ordering constraints, described as guaranteed redundancy opportunities under expected outcomes, not necessarily the absolute minimum executed tests across all outcome branches (Morciniec et al., 2016). The framework also assumes deterministic relationships under $E$0; flaky or nondeterministic tests are explicitly out of scope, and if $E$1 is UNSAT, no inference is sound. When dependency models are incomplete, optimality holds only relative to the encoded information. The approach is compared primarily against fixed orders and greedy heuristics, as well as against coverage-based, cost-aware, regression-history, mutation-based, and system-model prioritization methods, with the claim that it is orthogonal because it exploits logical entailment among test outcomes.

In the GUI automation framework, limitations arise from the repository of mined behavior and from the interface model (Lee et al., 26 Sep 2025). Redundant or low-significance logs can accumulate and dilute retrieval quality. Component identification relies primarily on textual labels, which makes visually similar elements with ambiguous names difficult to distinguish. Failure modes include mis-clicks caused by ambiguous object names and repeated re-planning when dynamic content or unseen affordances violate assumed task-block sequences. Future work is explicitly directed toward log filtering and deduplication, lightweight visual recognition within component viewports, and more explicit uncertainty handling in LocalPlanner.

A common misconception is to treat the two usages as instances of the same system. They are not. One is a formal method for reducing test execution through entailment, minimal Horn dependencies, and maximum satisfiable subsets of ordering constraints; the other is a retrieval-augmented planner–executor framework for GUI automation that operates over mined action–object patterns, structured task dictionaries, and live GUI context. A plausible implication is that the shared name reflects a recurring architectural idea—planning from compact logical or symbolic intermediates rather than from purely stepwise execution—while the underlying technical stacks, optimization problems, and empirical benchmarks remain domain-specific.