A mobile task finishes, and the automation system produces a short record:
App opened. Item selected. Save tapped. Run completed.
That record may be useful for tracking execution. But could another team use it to teach an agent what to do—or judge whether the task was completed correctly?
The answer depends on what the record preserves and what the intended use requires.
In the previous article, we examined how delayed feedback, interruptions, and starting conditions can change mobile behavior. This article follows the evidence after execution: what must remain available for those behaviors to become useful training or evaluation data?
A Log Can Be Useful Without Answering Every Question
Automation records serve different purposes. A record intended to diagnose a failed command may differ from one designed to preserve an agent's observations and decisions.
Nor are automation systems limited to recording commands. Android's Espresso framework, for example, distinguishes UI actions from assertions that check view state. A test can perform an interaction and then check an expected condition. Espresso documentation
The issue is therefore not whether something is called a log or a dataset. It is whether the available evidence supports the question being asked.
A sufficiently detailed execution record can be a strong starting point. A short command history may leave important questions unanswered.
What Does “Completed” Mean?
Consider an illustrative task: save a selected item to a particular list and confirm that it appears there. This is a worked example, not an ARMARRAY test result.
Suppose the record says that the Save action was issued and the run completed. Without a definition of that status, several interpretations remain possible.
The automation sequence may have reached its final instruction. The application may have displayed a confirmation. Or the intended item may have been checked in the correct destination list.
These are different claims.
For this task, a useful completion criterion is that the intended item is present in the specified list. A record supporting that conclusion needs to identify what was checked and what was observed—not merely carry a reassuring status label.
If no outcome check was captured, the result remains unverified. It should not silently become either success or failure.
The Missing Context May Have Existed Only During the Run
Someone watching the task may remember the selected item, the active account, or the screen visible before the tap. A later consumer of the record does not share that memory.
The record needs enough task context to explain what the action was supposed to accomplish. Saving an item to the wrong list can look successful if the intended destination was never preserved.
It also needs the relevant observation associated with the action. A tap coordinate without the corresponding interface may be hard to interpret. An image captured after the action cannot automatically stand in for what the agent saw before choosing it.
Finally, the relationship between records matters. If screenshots and events cannot be reliably associated with the same run and step, their presence alone does not establish a usable sequence.
This does not mean collecting every available signal. It means retaining the evidence necessary for the intended use.
Training and Evaluation Ask Different Things of the Record
Suppose the goal is to create examples of what action to take from a given observation. The selected action needs to be paired with the information available at that decision point and the relevant task goal.
A run that eventually succeeds does not automatically make every action in it a desirable demonstration. A redundant tap or an avoidable detour may need to be excluded, reviewed, or explicitly identified, depending on the training objective.
Now suppose the purpose is evaluation. The consumer may need a defined task, relevant starting conditions, a completion rule, and evidence showing whether that rule was met.
The same run can contribute to both uses, but its suitability should be assessed separately. There is no single “AI-ready” label that removes the need to define the purpose.
Formatting Does Not Restore Missing Evidence
Converting a text log into JSON can make it easier to process. Renaming a field from “done” to “success” does not establish that the intended outcome was checked.
Likewise, grouping screenshots into a folder does not establish which observation preceded which action.
Some gaps can be repaired when the supporting artifacts still exist: linking a preserved observation to an event, documenting an existing assertion, or clarifying a status definition. Other gaps require another run because the relevant state was never captured.
Annotation should preserve this distinction. An observed outcome, a reviewer's interpretation, and an unresolved result should remain distinguishable.
A Practical Review of the Save Record
Before selecting this run for reuse, ask:
- What item and destination did the task specify?
- What did the agent observe before choosing Save?
- Can that observation be associated with the recorded action?
- What result was checked, and what evidence supports it?
- Which parts remain unknown or were added through later review?
If those questions can be answered, the record has a clearer basis for reuse. If they cannot, the next step is to identify the missing evidence—not simply increase the volume of similar runs.
This is a review of fitness for purpose, not a complete data schema. Detailed recording fields and collection methods come later in the series.
Physical Execution Is One Part of the Chain
Running on a physical Android device can provide evidence from that device and its configured environment. It does not automatically preserve the task definition, connect observations to actions, or validate the result.
ARMARRAY's focus is the physical Android execution layer. A workflow using that layer still needs a recording and review process appropriate to its training or evaluation objective.
The infrastructure makes execution possible. The collection design determines which evidence survives it.
Next: The Task as a Connected Sequence
The gap between an automation record and useful AI data becomes smaller when another person can reconstruct the task, interpret the decisions, and inspect the basis for the outcome.
Logs may already contain much of that evidence. The work is to establish what they support, connect what belongs together, and leave missing information visible.
The next article examines the mobile task trajectory: how observations, actions, state transitions, and outcomes form a connected account of execution.