Learned steps

A Learned step performs browser actions that worked in an earlier passing Scenario run, then checks the current page again. Reusing those actions avoids model turns for that step and can make repeat runs faster.

Learning happens automatically for eligible saved browser Scenarios. Run the Scenario normally; there is no script to write or recording to select.

Read a learned step

Open a Scenario run and expand a Learned or Healed badge beside a step. The details show:

• The original step: what the Scenario asked Verify to do.
• An earlier passing run: a link to the run that supplied the learning.
• Actions: what this run did, such as clicking a named control or navigating to a path.
• Checks that proved it: what this run checked to establish that the step completed.

The replay timeline also marks learned events with a graduation cap. Select an event to seek to its timestamp. Choose the Learned or Healed link in the timeline legend to open this guide.

These labels describe how a step ran. Passed, Failed and Blocked describe its result. A learned step passing does not mean the whole Scenario passed.

How replay works

After a Scenario passes and its cleanup completes, Verify can retain the actions and checks that completed its steps. A later eligible run receives the matching learning and tries it against the app as it exists now.

For ordinary controls, learning records signals such as the control's role, accessible name and nearby text. On replay, Verify finds the control again from those signals. Visual clicks can instead use an anchor and offset, or a position within the viewport.

The saved checks must pass against the current browser state before the step completes. Verify collects fresh evidence; an earlier passing verdict alone cannot complete today's step. Learning reduces repeated decisions, so a whole run's speed still depends on page loading, app behavior, checks and any model work that remains.

Example

Suppose a Scenario includes this step:

Open the GitLab source-control guide from Docs.

On a passing run, Verify might learn these actions:

1. Activate the Docs link.
2. Navigate to /docs/verify/source-control/gitlab.

It could retain a URL check for /docs/verify/source-control/gitlab and a check that the guide heading is visible. The next run performs the actions again, then checks its own URL and heading. If both checks pass through replay, the step shows Learned.

The exact actions and checks depend on the run. Expand your step to see what Verify actually used. For a task such as creating an order, look for checks of the requested result in addition to navigation; reaching the right URL alone may not prove that the order was created.

When the page changes

Verify attempts to find learned controls again. When a control has moved, it can try to repair the match. A successful repaired replay appears as Healed.

If a control cannot be found, an action is unsupported, or a saved check does not pass, the model takes over at the incomplete step. It must still satisfy the Scenario's requirements. Replay can resume at later steps that have usable learning.

A page change does not automatically mean a failure: the model may complete the same task by a different route. It can also discover a real regression or become blocked. Inspect the actions, checks and evidence to understand the result. New learning is retained only after a passing run with completed cleanup.

Outcomes

Expected outcomes are the Scenario's final requirements. Learned outcome checks run only after all journey steps complete.

After those checks run, an independent review assesses the outcome against fresh evidence. Checks passing alone do not finalize a learned outcome. Its Learned details link to the source run and explain that independent review took place.

For example, after a learned sequence creates an order, the outcome might require “The new order appears with the correct total.” The run rechecks the result and the independent review evaluates the evidence before accepting that outcome.

When learning applies

Learning currently applies to single-actor website Scenarios with a configured Verify environment. It does not apply to multi-actor Scenarios or desktop and Android computer-use runs.

Verify offers learning for the same project, Scenario and Persona when:

• The step or outcome text and the account's sign-in method still match what was learned.
• A run has passed that learning within the last 14 days. Successful reuse refreshes this period.
• Its checks fit the target app's origin. Relative URL checks can work across environments; an absolute URL check for another origin requires fresh learning for that target.

Editing a step's wording or changing the sign-in method makes that entry require fresh learning. Some steps can be learned while others run through the model. First runs and runs without eligible learning work normally through the model.

Learning is scoped to saved Scenario execution; an exploratory run or a similar-looking task does not automatically share another Scenario's learned steps.

Credentials and test data

Granted credentials are represented by credential handles in learned actions, rather than saved as password values. Replay resolves the current grant when it needs to fill a credential. Email sign-in actions retrieve a fresh code or link. Run-specific naming can use a run tag so later runs do not reuse the original tag.

Ordinary non-credential input can be retained as part of an action. Keep real customer data and secrets out of Scenario instructions and test fixtures. Use managed credentials for test-account sign-in.

Next, inspect a run and its evidence or read about the Verify agent.