VeriSafe Agent (VSA): Mobile GUI Verification

Updated 7 July 2026

VeriSafe Agent (VSA) is a formal verification system for mobile GUI agents that converts natural language instructions into deterministic DSL specifications.
It decouples action generation via LFMs from rule-based pre-action verification, achieving up to 98.33% accuracy and enhancing task completion by 90–130%.
Its architecture integrates an LFM-powered agent, a verification engine, and developer-defined state predicates to ensure safe and predictable mobile automation.

VeriSafe Agent (VSA) is a formal verification system for mobile Graphical User Interface (GUI) agents that is designed to deterministically ensure that an agent’s actions strictly align with user intent before conducting an action. It functions as a logically grounded safeguard for Large Foundation Model (LFM)-based mobile automation by translating natural language instructions into a formally verifiable specification in a domain-specific language (DSL), then performing runtime, rule-based verification before the UI is affected. In the reported implementation, VSA is layered atop M3A, a GPT-4o-powered Android GUI agent, and is evaluated on 300 user instructions across 18 widely used mobile apps, where it achieves 94.3%–98.33% verification accuracy and improves task completion by 90%–130% (Lee et al., 24 Mar 2025).

1. Conceptual basis and problem setting

Mobile GUI agents built on LFMs can interpret interfaces and execute multi-step tasks from natural language instructions, but the underlying automation remains unreliable because of the probabilistic nature of LFMs and the ambiguity and context-dependence of mobile tasks. VSA is introduced specifically to address this failure mode by inserting a deterministic pre-action verification layer between the agent’s proposed action and the actual app execution. The stated objective is not to replace the agent’s LFM, but to ensure that the action path remains consistent with a formalized interpretation of user intent (Lee et al., 24 Mar 2025).

The central design choice is the decoupling of action generation from action verification. LFMs are used where natural-language flexibility is required, namely instruction encoding and semantic checking, while formal logic is used where safety and consistency are required, namely runtime action validation. This division gives VSA its characteristic hybrid profile: it robustly interfaces with LFM-based agents but mitigates their unreliability by decoupling formal verification from LFM action generation. The paper characterizes this as the first logic-grounded pre-action verification layer for mobile GUI agents and, more broadly, as the first attempt to bring the rigor of formal verification to GUI agent (Lee et al., 24 Mar 2025).

A common misconception is that VSA is an LLM-reflection method. The reported system is structurally different: reflection baselines invoke GPT-4o at every proposed action or after the action, whereas VSA uses the LFM only at instruction/specification time and relies on deterministic logic evaluation afterward. This suggests that the main novelty lies not merely in improved prompting, but in relocating verification from probabilistic inference to executable formal constraints.

2. System architecture and execution workflow

VSA is organized around three system layers: the LFM-based GUI agent, the VSA verification layer, and a developer-defined state predicate library. The end-to-end workflow is explicitly staged: developer annotation, instruction encoding, agent action interception, verification, feedback, and iterative task outcome handling (Lee et al., 24 Mar 2025).

Component	Function	Notes
LFM-based GUI agent	Proposes GUI actions	Example implementation uses M3A with GPT-4o
VSA verification layer	Checks whether an action is valid before execution	Uses formal specification and updated app state
Developer-defined state predicate library	Defines app states and triggers for state transitions	Requires ~5–10 lines per state

The runtime sequence is as follows. First, developers define app states and triggers for state transitions using a provided VSA library; if source is unavailable, annotation tools can be used. Second, when a user instruction arrives, the Intent Encoder leverages GPT-4o to translate it into a DSL specification. Third, when the GUI agent proposes an action, the developer library predicts the effect without actual execution. Fourth, the verification engine checks whether the proposed action is logically consistent with the specification and updated app state. Fifth, if verification fails, VSA generates structured feedback and the agent retries or adjusts; otherwise, the action is allowed. The process iterates until either task completion or agent termination (Lee et al., 24 Mar 2025).

The architectural significance of this workflow is that verification is performed pre-action rather than post hoc. The paper emphasizes that the developer library can pre-compute expected state changes before action execution, enabling true pre-action verification and preventing irreversible operations. This places VSA closer to runtime assurance and guardrailing than to conventional action-monitoring or trace-analysis systems.

3. Autoformalization and the domain-specific language

A defining feature of VSA is its autoformalization pipeline, which converts natural language user instructions into formal specifications. The input to this process is the user’s instruction together with a list of developer-defined state predicates and variables. The pipeline then proceeds through LFM-based drafting, self-corrective encoding, and experience-driven encoding, producing a DSL specification that encodes the user’s intent as logic rules (Lee et al., 24 Mar 2025).

In the drafting stage, the Intent Encoder prompts an LLM with the instruction and available states to generate a DSL draft. In the self-corrective stage, syntax checking verifies well-formedness and type alignment, while semantics checking decodes the DSL back into plain English through a separate LLM and compares it with the original instruction. Discrepancies trigger iterative refinement. In the experience-driven stage, successfully encoded and verified specifications are cached, and commonly used predicates from cache are proposed for later instructions within the same app, reducing errors and improving consistency (Lee et al., 24 Mar 2025).

The DSL is Horn clause-based. Each rule has the form

$p_1 \land p_2 \land \dots \land p_n \rightarrow o$

where the $p_i$ are predicates over app state and $o$ is an objective or terminal state. The grammar reported for the specification is:

Specification ::= Rule*
Rule         ::= (Pred1 ∧ ... ∧ PredN) → Objective | (Pred1 ∧ ... ∧ PredN) → Done
Pred         ::= Objective | StatePred(Constraint*)
Constraint   ::= Variable Operator Constant
Operator     ::= = | ≠ | ≈ | > | ≥ | < | ≤ | ⊆ | ⊈
Constant     ::= String | Number | Boolean | Date | Time | Enum

The DSL supports hierarchical expressiveness through predicates, constraints, objectives, and rule chaining. The paper’s restaurant-reservation example illustrates this explicitly: $\begin{align*} R_1: &\;\; \textsf{RestaurantInfo}(\textsf{name}=\text{``R''}) \land \textsf{ReserveInfo}(\textsf{date}=\text{Today}, \textsf{time}<\text{19:00}, \textsf{available}=\text{True}) \rightarrow \textsf{Reserve} \ R_2: &\;\; \textsf{Reserve} \land \textsf{ReserveResult}(\textsf{success}=\text{True}) \rightarrow \textsf{Done} \ R_3: &\;\; \textsf{RestaurantInfo}(\textsf{name}=\text{``R''}) \land \textsf{ReserveInfo}(\textsf{date}=\text{Today}, \textsf{time}<\text{19:00}, \textsf{available}\ne\text{True}) \rightarrow \textsf{Done} \end{align*}$

This formalization strategy is notable because it maps ambiguous instructions into explicit objectives, conditional branches, and completion conditions. A plausible implication is that VSA’s correctness depends not only on the verification engine but also on the quality of the autoformalized DSL, which is why the paper devotes substantial machinery to syntax checking, semantic back-translation, and cached predicate reuse.

4. Developer library, runtime verification, and feedback

The developer library is the substrate that makes runtime verification feasible. Developers declare state predicates, which encode abstract app states and their relevant variables, and wrap UI event handlers with VSA-provided triggers that pre-compute expected state changes before action execution. The reported annotation burden is approximately 5–10 lines per state (Lee et al., 24 Mar 2025).

Verification is divided into two phases. Predicate-level verification is a soft check: every time a state variable is updated, predicates that use that variable are re-evaluated, and if a predicate is false, VSA gives a soft warning to the agent. Actions are not blocked at this point. Rule-level verification is a hard check: at critical actions, when the agent marks intent to satisfy an objective, the entire rule’s preconditions are checked; if all predicates are not true, the action is blocked and hard feedback lists all missing predicates (Lee et al., 24 Mar 2025).

The logic is fully deterministic once the DSL specification has been generated. The paper summarizes the logical core again in Horn clause form: $(p_1 \land p_2 \land \ldots \land p_n) \rightarrow o$ Each state variable update triggers re-evaluation of relevant predicates and rules using Boolean logic. The system therefore differs sharply from LLM-based reflection, where validation itself is another probabilistic language-model query.

Feedback is not restricted to binary acceptance or rejection. VSA provides roadmap feedback after encoding, predicate-level soft feedback during intermediate deviations, and rule-level hard feedback at action checkpoints. Hard feedback enumerates exactly which conditions are still unsatisfied and blocks progress until they are corrected. The paper argues that this systematic feedback avoids the vagueness and contradictions found with LLM-based feedback generation (Lee et al., 24 Mar 2025). This suggests that VSA is intended not merely as a filter, but as a corrective supervisory layer that shapes the agent’s subsequent action proposals.

5. Experimental evaluation and reported results

The empirical evaluation uses VSA layered atop M3A on a Google Pixel 8 smartphone. The dataset consists of 300 user instructions from 18 popular mobile apps, partitioned into 150 “Correct” and 150 “Wrong” cases. It includes 125 instructions from LlamaTouch with average 6 steps, and 25 challenging long-horizon instructions with average 19 steps and up to 40 steps (Lee et al., 24 Mar 2025).

The baselines are two LFM-based reflection methods: pre-action reflection in the style of AppAgent v2, with GPT-4o invoked at every proposed action, and post-action reflection in the style of Mobile-Agent v2, with GPT-4o invoked after the action. Two VSA variants are reported: VSA-Cold, which uses self-corrective encoding only, and VSA-Warm, which adds experience-driven encoding through cached predicate suggestions. Evaluation metrics include verification accuracy, precision, recall, F1 score, true positives, false positives, true negatives, false negatives, task completion boost when the agent receives feedback, and cost and latency overhead (Lee et al., 24 Mar 2025).

The principal results are quantitative. VSA achieves 94.3%–98.33% verification accuracy, with up to 98.33% on LlamaTouch. It yields up to a 25.6% absolute accuracy improvement over reflection baselines and maintains high accuracy as tasks grow complex, whereas reflection methods’ accuracy drops due to compounded LLM errors. Reported error rates are false positive 2.7% and false negative 0.7%. Majority voting over multiple formalizations mitigates LLM randomness, and 100% accuracy is reached on the challenging dataset with only 5 majority attempts. When agents receive VSA feedback, task completion rate increases by 90%–130%; specifically, 13/15 previously failed challenging tasks are corrected, while reflection agents fail to correct any (Lee et al., 24 Mar 2025).

The evaluation also reports a systems-level efficiency result. VSA incurs a constant, negligible overhead because the LFM is used only at initial specification time, while reflection methods have cost and latency that scale with the number of agent steps, described as $O(N)$ . The paper states that this leads to doubled latency and cost at reasonable task lengths for reflection baselines. In context, this is important because safety layers for GUI agents are only practical if they do not dominate the interaction budget.

6. Interpretation, scope, and terminological ambiguity

Within the reported framework, VSA establishes a model in which natural language is autoformalized into a deterministic, logic-grounded guardrail for mobile automation. The paper presents this as a new paradigm for safe and reliable automation of mobile tasks, combining the flexibility of LFMs with the rigor and interpretability of formal methods (Lee et al., 24 Mar 2025). A cautious interpretation is that the system’s reliability hinges on three jointly necessary conditions: adequate developer-defined state predicates, correct autoformalization of user intent, and accurate simulation of pre-action state transitions.

Another frequent misunderstanding is that VSA eliminates the need for LFMs. The reported design explicitly does not do so. GPT-4o remains responsible for translating user instructions into DSL specifications, decoding those specifications for semantic consistency checks, and powering the underlying GUI agent. What VSA removes is the dependence on LFM inference for ongoing step-by-step action validation. Its stated contribution is therefore a verification wrapper around LFMs rather than an alternative to them (Lee et al., 24 Mar 2025).

The acronym “VSA” is also ambiguous in the wider arXiv literature. In autonomous driving, “VSA” denotes Vehicle Sideslip Angle in work on uncertainty-aware hybrid learning for virtual sensors (Kalyanasundaram et al., 8 Apr 2025). In radar localization, “VSA” denotes a velocity synthesis-assisted localization algorithm for multi-site SISO radar systems (Qin et al., 17 Apr 2026). In hyperdimensional computing, “VSA” denotes Vector Symbolic Architectures, including MBAT and sequence-encoding methods (Gallant, 2022, Rachkovskij et al., 2022, Rachkovskij, 2021). In the present context, however, VSA refers specifically to VeriSafe Agent, a logic-based action verification framework for mobile GUI agents.

This terminological overlap matters because the mobile-agent VSA belongs to a different research lineage from the other uses of the acronym. Its primary vocabulary is formal verification, Horn clause reasoning, state predicates, and runtime guardrails, rather than vehicle dynamics, radar Doppler synthesis, or hypervector representations. The shared acronym is therefore nominal rather than conceptual.