Skip to main content
This page defines the concepts used across the rest of the documentation.

​
Agent-driven execution model

A Visor-enabled agent follows this model:
  1. Resolve one explicit runtime target and keep its daemon session warm.
  2. Read compact semantic memory before requesting visual or source evidence.
  3. Execute a known action or deterministic route.
  4. Observe and annotate an exact token only when the app reaches an unknown state.
  5. Capture targeted evidence and evaluate assertions when verification requires it.
  6. Persist map evidence, artifacts, and structured results.

​
Key concepts

​
Runtime target

A runtime target is the environment Visor connects to. A target includes:
  • device identity
  • platform inferred from the selected device
  • Appium server location
  • app identifier when one is required

​
Action

An action is one unit of interaction or evidence capture. Available actions today:
  • tap
  • navigate
  • act
  • screenshot
  • wait
  • source
Each action produces a structured payload. Some actions also write files.

​
Agent memory

Agent memory is the compact semantic view of a local app map. It contains named screens, meaningful actions, destination recognizers, route reliability, and unresolved gaps without exposing raw UI trees or dynamic user content. The agent reads this file before using screenshots or UI source. Visor keeps the larger runtime index separate because the executor needs details that are inefficient and unsafe to place in model context.

​
Deterministic route

A deterministic route is an agent-authored plan with one or more ordered safe paths. Each step includes a command, arguments, and an exact destination selector. Visor executes the plan within one daemon request, checkpoints every outcome, and returns needs_discovery when no supplied path matches the live state.

​
Scenario

A scenario is a JSON document with four functional sections:
  • meta: identifies the scenario
  • config: defines runtime-related defaults such as timeout, seed, and artifact directory
  • steps: the ordered actions to execute
  • assertions: checks evaluated after the steps complete
A scenario is the unit used for validation, full execution, and benchmarking.

​
Step result

Each scenario step produces a step result. A step result contains:
  • the step id
  • the command name
  • pass or fail status
  • duration in milliseconds
  • returned details from the adapter
  • an error payload if the step failed

​
Assertion result

Assertions run after all steps have executed. Important behavior:
  • Visor does not stop before the assertion phase just because a prior step failed.
  • Assertions are evaluated against the current app state at the end of the step sequence.
  • Unsupported assertion types are treated as failures.

​
Artifact

An artifact is a file written to disk during execution. Common artifacts:
  • screenshots as .png
  • UI source dumps as .xml
  • summary and timeline reports
  • JUnit XML
  • environment metadata
  • a minimal HTML report

​
Determinism signature

A determinism signature is a hash of the run structure and results. It is derived from:
  • platform
  • step ids
  • step commands
  • step statuses
  • step details, excluding variable artifact paths
  • assertion results
The signature is used to compare repeated runs.

​
Determinism score

The determinism score is the percentage of repeated runs whose signature matched the first run in the benchmark set. A higher score means the scenario behaves more consistently.

​
Reading the results correctly

When you analyze a Visor run, separate the result into these layers: This separation matters because the envelope is optimized for quick machine handling, while the artifacts are optimized for deeper review.