# Verify reference

Detailed Verify setup, Discovery, recordings, Scenario dependencies, fixtures, schedules, billing and supported app environments.

For the short, three-step introduction, start with [Get started with Verify](/docs/verify).

## Test your app like a user would

Verify opens your app in a browser, tries real user tasks, and shows you what worked and what broke. You can watch it work and replay the results.

Start with a website URL. You don't need a repository or test scripts.

With the optional browsing sidebar enabled for your organization, signing in opens
the welcome and setup page with **Verify**, **Agents** and **CI** in the sidebar,
even when you have one project. Use the sidebar's Back button to move from a project to its project list, then to **Verify**, **Agents**
and **CI**. Back changes only the menu and leaves your current page open.
Selecting a product, project or destination such as **Scenarios** or **Run history**
opens its page. Selecting **Verify** opens the welcome page with its project menu. The agent workspace uses the same sidebar for its roster and threads.
Organizations outside this rollout keep the existing navigation.

To act out a journey yourself, use the [local Scenario recorder](/docs/verify/local-recorder). Record in private Chrome, mark important elements, then review and run the generated YAML draft.

New Team workspaces are invoiced $500 upfront for 3,000 browser minutes. Your subscription
renews monthly on your signup date, when your browser-minute allowance resets.
Usage beyond the allowance is charged at renewal alongside the next month's
subscription. Existing customers keep their current billing terms.

## Prepaid browser packages

New prepaid workspaces get one included discovery once test access is settled in setup: when you continue from the test account step, or skip it, before checkout. Saving an app URL, through guided setup or an agent, does not start it. It signs in with the test account you chose, or maps public pages if you skipped it, with up to six parallel browsers for ten minutes, without a subscription or card. **Exit setup** opens that discovery, and it keeps running while you finish onboarding. After Stripe Checkout, you return directly to the same discovery, including its results if it has already finished. If you change the test account after it starts, your first run after checkout uses the new account instead.

Your offer shows the monthly price and included browser minutes for further testing. Saving a card does not unlock paid usage: the monthly payment must be confirmed first. Your app stays saved while onboarding checks for payment confirmation.

Additional browser minutes cost $1 each before applicable tax and are purchased in advance in billing settings. Purchased minutes carry forward until used; included monthly minutes reset at renewal. After the included discovery, new runs require an active paid package and reserve their maximum browser budget. Unused reserved minutes return when the run ends, and extra usage is never added to a later bill. The included discovery does not consume paid minutes and cannot be restarted with a new time budget after it ends.

Owners can cancel at the period boundary while retaining purchased minutes. Reactivation is support-assisted during the pilot. Existing metered and Enterprise workspaces keep their agreed terms.

## Record a Scenario

Choose **Record a Scenario** in the Scenario editor and act out the journey in the private browser. When you finish, return to Composal to create the draft. Recorded user actions are kept in order, with one action per step, up to the Scenario limit of 1,000 steps. Background requests and automatic redirects are supporting events, so the recorded event count can be higher than the draft's step count. Account sign-in is handled by the selected test account and is removed from its steps.

To call out something essential, choose **Mark important element**, then select it on the page. Enter what the test must do or verify and choose **Add required check**. Selecting an element does not click it in the app. Keyboard users can focus an element in the remote app, then press **Ctrl+Shift+M** or choose **Mark focused element**. Each check stays at that point in the journey and retains your wording in the draft. Review the draft before saving; adding a check does not run it.

Passwords and stored secrets are withheld from recording. Ordinary field values can be recorded; keep secrets out of your check instructions.

## <span className="docs-step-number">1</span> Add your app and explore it

1. Open **Verify** and add a project for your app.
2. Add the URL you want to test, such as your staging site. This is your **environment**.
3. If your app needs a login, [add a test account](/docs/verify/credentials). Use an account with data you are comfortable changing.
4. Start **Discovery**. Tell it which parts of your app to explore and what it is allowed to do.

Discovery explores your screens and user flows, then suggests tests. You can watch its browsers while it works.

If the coordinator's browser times out during initial setup, Verify retries with a fresh coordinator after a short delay, up to four consecutive startup attempts within the run's deadline. Each failed attempt stays in the results with its error. This recovery happens before application actions begin; it does not replay a failed action. If startup retries are exhausted while time remains, choose **Retry browser startup** to schedule one fresh coordinator in the same run. This preserves its deadline, tester budget, instructions and earlier evidence. Canceled runs, expired runs and failures after application actions cannot use this retry.

Open **Product map** in your project's sidebar for one persistent journey map of your app. Every Discovery run adds to this shared map as it explores; the map is not tied to an individual run. A dedicated Luna model with low reasoning labels each screen's purpose, layout regions, and controls. Matching screen states are reused across runs, accounts, and revisions, while changed layouts and permissions remain distinct states. The default view combines all captured revisions and accounts; use the filters to inspect a specific scope. The map opens with screenshot previews for a small graph of URL sections and their recorded connections. The **Observed persona** selector shows captures and journeys attributed to a configured persona, such as a user or administrator. View cards name the personas observed there. This records what each persona experienced; it does not prove that another persona cannot access the view. Choose **Explore as** when starting a Discovery run to pin its persona’s role, goals and account. The scanner follows that perspective and attributes new captures to it. Anonymous personas stay signed out; account personas require an allowed credential. Signup personas use Scenario runs. Older Discovery captures without persona provenance remain under **Persona not recorded**. Open a section to browse readable view previews, then select a view to focus its recorded paths across the app. Documentation URLs share browsing cards across preview deployments; **recorded views** lets you open each original recording. This grouping does not merge screen identities or join executions. The graph immediately redraws and fits those connected views; unrelated branches stay outside the focused canvas. These connections show observed navigation, not a qualified end-to-end journey. Press **Esc** or choose **Back to section** to return to its previews. Press **Esc** again to return to all sections. Click a view inside the focused graph to open its details; choose **Explore view states** for its internal states, or use the expand button for its full screenshot. Solid connections represent recorded actions; dashed connections represent automatic changes. Hover a screen or arrow to emphasize its connections and arrowheads; keyboard focus on a screen provides the same tracing. Unrelated views fade while the screens connected by the highlighted arrows remain fully visible. Zoom out to replace small screenshots with larger view titles; zoom in to reveal captures again. The graph stays visible at every zoom level. Choose **Areas** to browse app areas and narrow the map. In a journey tree, choose **Follow flow** and select a retained execution to keep its full path highlighted while other branches fade. **Previous** and **Next** move through its recorded screen occurrences, including repeated visits; arrows show the selected execution’s actions. **Exit focus** restores the whole tree; **Exact captures** opens that execution’s historical storyboard. The tree uses shared-screen previews, which may be newer than the execution; the storyboard keeps the exact historical screenshots. Focus follows recorded variant membership, not every reachable screen, and does not qualify replay coverage. Dashed alternatives are inferred and not explored; dotted links need evidence. Open the recorded-end control to inspect the expected outcome, missing evidence, or a truncated preview. Connections refresh in the background while the retained graph stays usable. A limit notice appears when the retained inventory is incomplete. Use **Toggle app navigation** and **Hide journeys** to give the canvas more room; **Show journeys** restores the rail. Journey search matches canonical goal names and purposes across all pages, within your account and revision filters. Enter a search and press Enter or choose **Search journeys**; the URL retains it independently of screen search. The journey list remains beside the graph. Choose a goal once, then use its ordered steps or **Previous** and **Next** to keep the map and exact historical capture in sync. **Variants and Replay** opens the evidence and replay controls. Use **Areas** or the area filter to focus on a part of the app, and **Screens** for an accessible grid. **Fit Loaded Map**, **Fit Journey** and **Center Selection** control the visible graph; only loaded states are drawn. The map opens fitted to the app sections. The journey rail keeps observed goals beside the canvas; select a goal to follow its ordered captures. Drag to pan freely, scroll or pinch to zoom around the pointer, and use Shift+scroll to pan horizontally. With the canvas focused, use arrow keys to pan, +/− to zoom, Home to fit the loaded map, and 0 to return to 100%. Selected connections show their recorded actions at 50% zoom and above. Search, revision and account filters stay above the workspace; **Capture Dates** reveals the time filters. Questions and their bounded answers sit below the map.

Select a journey to open its first key screen at a readable size. **Key steps** groups intermediate loading captures into their recorded transitions. When a recording returns to its starting screen, **Part** controls let you follow each section separately; a return does not prove a retry or a successful outcome. The sidebar, graph and full-screen viewer follow the same ordered steps. Choose **Recording** to inspect every retained capture, including repeated visits and loading frames. Failures, unresolved actions and a terminal loading screen stay visible. Open **Evidence** for the observed result, missing evidence, other recorded paths and replay controls. Older links to an intermediate capture open the complete recording. **All journeys** returns to the goal list; **Fit Journey** fits the current part explicitly.

Select a screen to open its inspector. **Overview** keeps the purpose and screenshot close at hand; **Actions** shows recorded connections and controls; **Evidence** holds capture IDs, identity review and captured layout details. Screenshot expansion is an explicit action, so selecting a screen keeps the inspector available.

Discovery receives a bounded summary of the shared map for its selected revision and account to help extend existing coverage. Earlier observations are context and must be rechecked in the current browser.

Screen labeling and journey detection run in the background and can finish after the browser stops. New captures take priority over recovery work. Repeated evidence deliveries reuse pending map work, and accepted label changes share one pending journey capture per run. Missed enqueues remain recoverable from the retained evidence.

With map retrieval enabled, Discovery can also search historical states, inspect captured layouts and action evidence, read unexplored branches, and plan candidate paths. These reads stay within the run's selected revision and login account. A planned path needs a fresh replay before it can establish current behavior.

With source mapping enabled, Discovery also reads your connected repository to plan coverage. It inspects routes and navigation, then relevant components, forms, permissions, feature flags and tests to identify likely goals, branches and prerequisites. Source references retain their repository, commit, path and line numbers. A declared deployed commit is used when available; otherwise each exploration pins a repository snapshot and marks its build match as unverified. Source hints remain candidates until confirmed in the browser. They do not grant access to another role, enable a feature flag or count as completed coverage. Missing or inaccessible source remains an explicit planning gap.

Repository indexing is bounded by file, directory, byte and time limits. A truncated inventory supplies partial source context; it does not establish complete coverage of the repository.

When historical image retrieval is enabled, Discovery can request a small retained viewport image alongside a state or observation. It remains historical evidence. Images expire from the model's temporary context and do not extend the original screenshot's retention or supply fresh action coordinates.

Choose **Compare revisions** from the product map to inspect captured differences. Select a before revision, an after revision and one recorded login account or **Anonymous**. Area, search and capture-date filters apply to both sides. Changed states show their before and after evidence; states captured on only one side remain coverage differences until replayed. Comparisons use a bounded sample and show up to 50 evidence cards per category, with a notice when more observations remain. Images follow their original retention policy.

Each accepted labeling pass retains its model, prompt and schema versions and source fingerprint. Relabeling preserves earlier interpretations and keeps the last accepted labels available while new work is pending. A capture's recorded account and browser actor remain attached to that capture even if run settings later change. Older captures without an account snapshot are marked **Account not recorded**.

Matching considers relevant existing states, including older captures on similar routes and layouts. Reusing a state requires a confident match to a supplied candidate. Uncertain matches remain separate states. Changed permissions, selected tabs and responsive layouts retain their distinct evidence.

Click a screen or journey step to select it and keep its details in the sidebar. Use the screen’s expand button or **View Full Screen** to open its capture in the full-screen viewer; press Escape to return to the map.

Select a screen and open **Inspect identity history** to compare accepted model judgments with reviewer decisions. An organization administrator can split that capture into a separate state or review another capture's screenshot and merge the two into its current identity. Corrections require a reason, retain the original evidence and judgments, and survive later labeling. A changed capture identity requires a fresh review before applying a correction. Uncertain identities also appear in **Unexplored** until reviewed.

With Scenario mapping enabled, newly prepared website runs can add captures to the same project map. Captures retain the approved definition, prepared environment revision and saved actor/account bindings. Named actors remain separate evidence scopes; signup executions use separate session scopes so a reused mailbox is not treated as one app user. Runs without a revision pin are not backfilled, and mapping captures does not qualify a journey or change a Scenario's result.

When journey mapping is enabled, **Journeys** collects shared user goals across Discovery and mapping-enabled Scenario runs. Each candidate variant retains one execution's ordered observations, action receipts, account, actor and revision. Interleaved actors keep separate chronological traces. Scenario observations also retain their approved definition and persona snapshots. Open a goal to inspect its screenshot storyboard, action outcomes, prerequisites and missing evidence. Labels in a storyboard preserve their original interpretation even after a screen is relabeled or corrected. Its inspection link opens the current shared state when that state is included in the selected filters. Failed, unchanged and automatic observations retain their own outcomes. Candidates require review and a fresh-session replay before reuse; even a passing source Scenario does not qualify a generated journey.

Selecting a goal on the map opens its recorded branches together, including screens outside the loaded overview page. Dashed alternatives have not been explored. Select an observed branch to inspect its execution, then choose **All Branches** to return to the goal. Path previews remain bounded and disclose when older paths are omitted; they do not establish complete app coverage. Journey interpretation waits for outstanding screen labels so a partially labeled execution does not repeatedly publish fragmentary proposals.

With journey replay preparation enabled, an organization administrator can open **Review Replay Preparation** on a journey variant. Paste a reviewed Scenario file as JSON and give a review reason. For a named-actor file, retain the source journey's actor label. **Check Preparation** refreshes its receipt, and **Review Prepared Run** opens the normal Run plan. The latest receipt stays on the shared journey after a reload, including for readers who cannot prepare another replay.

The API also accepts the reviewed Scenario file, review reason and idempotency key through `POST /api/v1/organizations/{organization_id}/verification/projects/{project_id}/product_map/journey_variants/{variant_id}/replays`. Read the returned request through `GET /api/v1/organizations/{organization_id}/verification/projects/{project_id}/product_map/journey_replays/{replay_id}`. Preparation retains the original journey's terminal condition, revision and account or signup Persona intent. Scenario sources also retain every original actor, step, outcome, fixture, cleanup and ordered dependency handoff. Signup needs a fresh configured inbox. Changed intent or unavailable prerequisites produce a refusal to inspect.

The prepared Run uses the normal plan inspection and approval workflow. Preparing it does not start a browser, save a Scenario or qualify the journey. Retry an unchanged request with the same idempotency key; a different reviewed definition needs a new key.

With journey qualification enabled, a finished replay is checked against the original intended outcome, approved plan and continuous actor path. Qualification reads retained capture and screenshot bytes, independently reviewed outcomes and authored cleanup evidence. It waits for pending labels and refuses missing or incompatible evidence. **Check Journey Qualification** requests the check for an existing prepared replay. Refresh its receipt to inspect the result. Later identity changes, conflicting action receipts or expired evidence make a historical qualification unavailable for reuse without rewriting its original receipt. Each new Run still needs its own approval and result.

When qualified flow scanning is enabled, **New deep scan → Mapped flows** loads flow choices for the selected environment and credential. Compatible shared journeys retain their stable IDs and replay provenance. A new scan checks the current environment revision and retained qualification again; an accepted request can still be recovered after its evidence expires. Multi-actor and fresh-signup journeys remain available for review on the shared map. This one-credential scan list uses compatible single-actor journeys and falls back to the original Discovery report when none qualify. Starting from a particular finished Discovery continues to use that Discovery's own flows and saved credential.

Choose **Show on shared map** on a journey variant to see its ordered flow. Each step uses its exact retained screenshot and label, including repeated visits to the same shared screen. Action arrows connect matching source and destination captures; a dashed ordering line marks a source capture omitted from the storyboard. The selected flow does not depend on the overview’s loaded-screen limit. **Previous** and **Next** select steps and bring small captures into readable view. Click a screen to select it and show its inspector. Choose its expand control or **View Full Screen** to open the screenshot viewer. Use its **Previous** and **Next** controls, zoom, **Actual Size**, and **Fit Screen** to inspect the flow, then press Esc to return to the map. Arrow keys scroll a zoomed image when its image area is focused; elsewhere they move between captures. Inspecting a flow does not qualify it for reuse.

The map loads captured screens first, so you can pan, zoom and inspect their layout while connections load in the background. **Unexplored** becomes available when action evidence has loaded. Loading more states adds the next screen batch before its connections finish. A failed connection load keeps the screens visible and offers **Retry**.

Open **Unexplored** to review observed controls that still need exploration, prerequisites, disambiguation, or outcome evidence. Disabled controls and failed attempts remain visible. An unchanged capture does not prove the user's goal passed. Use area, task search, and capture-date filters to narrow the map. **Inspect captured layout** can outline controls on their exact viewport image; a long-page capture opens separately and does not supply action coordinates.

Connected agents can read a product brief, search states, inspect neighbors and exact observations, retrieve the frontier, plan a candidate path, or compare revisions through the Verify MCP tools. Use `verify_list_product_journeys` to find shared user goals and `verify_read_product_journey` to read their original ordered storyboards with observation and action IDs, prerequisites, gaps and replay receipts. Keep the same revision, credential and time filters when gathering evidence for a question. Cite the returned captures and distinguish observed behavior from unknown outcomes; separate historical variants do not establish one executed flow. Path planning requires one revision and account and always reports that fresh-session replay is required. Revision differences describe observed coverage and interpretation changes; they do not establish a regression.

Map connections require an observed action and a successful retained action receipt. Different tabs, dialogs, and empty or error states can appear separately even when they share a URL. The map shows observed coverage; missing screens and connections remain unexplored. New captures require a mapping-capable browser runner. Older Discovery runs are not automatically backfilled, and screenshots remain subject to their evidence retention policy.

Open an agent in Discovery or Deep Scan to see **Observations** first: pages visited and what each check observed. Open **Evidence** to load the player and evidence files. Select the running browser’s picture in the player and use **Watch Live** if offered. Confirm the picture and current URL before switching to **Diagnostics** to inspect console messages and network requests. Evidence files and a displayed URL alone do not confirm that a live picture has loaded.



Testing an app behind a VPN? [Connect your private network first](/docs/verify/private-networks).

## 
  <span className="docs-step-number">2</span> Run your first test


Open **Scenarios** in your project. A scenario is a saved test, such as “A customer can add an item to their cart.”

Review the tests Discovery created, or write your own. Describe what the user should do and what should happen. Select a test, choose an environment, and run it.

Need to test a signed-in flow? [Follow the login testing guide](/docs/verify/guides/authenticated-journeys).

## 
  <span className="docs-step-number">3</span> See what happened


A **Learned** step reuses actions from an earlier passing run and checks the current page again. **Healed** means a moved control was found again during replay. Expand a marked step to see its actions, checks and source run, or read [how learned steps work](/docs/verify/learned-steps) for examples and diagrams.

Verify checks a website Scenario for clear conflicts with explicit project restrictions before signing in or replaying learned steps. If a step contradicts a written domain restriction or edits an existing record when the project permits changing only records this run creates, correct the instructions before rerunning. Verify keeps the original restrictions and reports the conflict as a run configuration problem. Journeys can follow links to other origins, including customer portals, and switch between their own browser tabs. Application targets identify the app and bind relative checks; they are not a navigation allowlist.

If a result remains unconfirmed and the page contains scrollable evidence, Verify gets one further opportunity to inspect it before finishing. It can scroll an inner panel or editor to match the result to this run's data. If the evidence still cannot confirm the outcome, the result stays unconfirmed.

Open the run to see its result and replay what the browser did. The replay timeline separates timestamped **Events** from duration bars in **Phases**. Select a tick or bar to seek to it. **Skip idle time** is on by default when action timing is available: it jumps over pauses and fast-forwards the middle of long actions, including page navigation waits. Each action’s beginning and result play at your selected speed. Turn it off to watch the full recording at that speed. If a timestamp falls between saved video segments, replay moves to the next saved frame and keeps your play or pause choice. Recorded application cleanup appears on the Phases row, including retries and finalization time.

An unresolved step stays current until its checkpoint passes. When page text cannot be extracted, Verify can review the checkpoint screenshot, including during cleanup. Cleanup has its own limits and stops if it exhausts them or stops making progress. Its result stays separate from the scenario result: successful cleanup does not turn an incomplete test into a pass.

For browser scenarios that check hover changes, Verify can move the pointer without clicking and retain screenshots before and after the move. Captures can also sample an animation already running. These frames help compare changes such as growth and tilt. Missing frames or an unclear comparison leave the outcome unconfirmed; sampled frames do not prove continuous motion.

An unread text check can be confirmed by independent review of that checkpoint's screenshot. The reviewer must be able to read the exact expected phrase in that picture. Hidden text, a different or older picture, and missing evidence leave the check unconfirmed. A definite contradiction remains a failure. The original checks and the review receipt stay in the retained evidence. If generated checks block a step on an incidental condition, Verify reviews the original step against its captured evidence. It preserves the native report and requires fresh review before that step can advance. Such scoped steps are not saved as replay shortcuts. Replay leaves clock values and request, finding or evidence counts to fresh model verification. Those checks are not reused as fixed values from an earlier run; the original expectations and evidence remain intact.

When a browser outcome fails or remains unconfirmed, its evidence can include numbered outlines showing the part of a screenshot the reviewer inspected. The notes beneath the image explain what was wrong or expected there. Open a screenshot and choose **Hide Highlights** to inspect the original pixels. These callouts belong to that saved image; they do not follow the moving recording or represent an automatic pixel diff. Older runs and checks without a visible target may have no highlights.

The scenario picker shows 25 executions per page. Choose a scenario to open its full report, steps, recording, and diagnostics. Links to a specific browser open that execution directly, including on later pages.

Scroll the center pane to read evidence and diagnostics beneath the player. As the player leaves view, it moves into a floating mini-player and playback continues. Click the window’s traffic lights to pop it out manually and smoothly scroll to the content beneath it. Scroll back up to its original place or click the mini-player’s traffic lights to return it to the page. With reduced motion enabled, the content appears immediately. Scenario runs, exploration threads and finding recordings use the same player controls; only one mini-player appears at a time.

Linux desktop recordings preserve the display resolution up to 1920×1080 at 25 fps, with a target video bitrate of 1.5 Mbit/s. Animated previews remain smaller. Quality changes apply to new recordings; existing recordings keep their original resolution and detail.

Open your organization's **Settings → Billing** to manage your subscription and see browser minutes and **Verify Storage** usage against your package allowance. Verify Storage counts retained recordings and evidence over time, until their files are deleted, including expired recordings awaiting cleanup. Organizations using source control or hosting also see a detailed storage breakdown. Existing package revisions keep their storage terms.

Click or drag across the replay timeline to seek, including the space above and below the ruler line. Playback starts as video data arrives. The selected clip loads first, followed by its next segment; the last picture stays visible while a new position loads. Where supported, dragging uses fast keyframe previews; releasing the timeline or selecting a step seeks to the exact timestamp. Use the zoom slider on the right to inspect part of a long recording, and select **Fit** to show the whole recording again. Select a recorded timestamp or step to return to the player at that moment.

Verify automatically retries temporary browser-startup gateway failures up to three launch requests within the startup time limit. Recovery rejoins the same attempt without starting another browser or repeating test actions. Persistent startup failures leave the run incomplete; they do not count as an app failure. Visual review accepts small and resized viewports at their native resolution.

Use **Scenarios → Runs** to browse individual and grouped runs, newest first. Each row shows its trigger and execution date. Pull request runs also show the PR number and title. Search by scenario or PR, or filter by status, trigger, or environment. Your filters stay selected as you browse older pages.

The environment picker searches names, addresses, types, branches, and PR numbers. It lists regular environments first and **Previews** below, with up to 25 matches per group. Keep typing to narrow the results. You can also search archived environments to find historical runs.

The timing pill shows **runtime | browser time** in minutes. Runtime measures how long the scenario took. Browser time adds the time used by all metered browsers, including setup and sign-in: five browsers running for two minutes consume ten browser minutes. Usage appears as unavailable when its records are no longer retained. Open a run to investigate it; its back link returns to the list you came from.

- **Passed:** the tested outcomes worked.
- **Failed:** something did not match the expected result. Open the finding to see the evidence.
- **Blocked or inconclusive:** Verify could not finish or confirm the result. Read the reason, fix the setup if needed, and try again.

Read the cause beside a result to see whether the app, account, prerequisites, scenario instructions or Verify need attention. Short run summaries and pull-request findings omit internal recovery-code labels. A known saved cause takes precedence over contradictory labels in older advisory text.

When no detailed explanation is available, the full report, short summary and PR comment use the same fallback, with specific capacity and time-limit reasons taking precedence over a general interruption message.

When a missing prerequisite or access requirement blocks a run, its summary shows the **Starting conditions used for this run** and how to proceed. Check that the conditions match the selected environment and test account. Supply genuinely required data or access; correct conditions that are inaccurate or unnecessarily strict. Administrators can choose **Edit starting conditions** to open the saved Scenario. Connected runs link to each participating Scenario so you can edit the one that owns the requirement. If no active saved Scenario is available, update the original Scenario file instead. Start a new run after saving; the earlier run keeps its original conditions and result.

If browser request signing becomes unavailable, Verify stops that browser attempt and retains its partial results and evidence. Unfinished outcomes remain unconfirmed, and cleanup is reported separately; retry after the signing service or grant is available again.

A passing run covers the tests it ran. It doesn't mean every part of your app has been tested.

Choose **Open Scenario** in a run’s header to view the selected saved scenario.
In runs with multiple scenarios, select the scenario you want first. Runs from
unsaved scenario files have no saved scenario to open. Organization admins can
choose **Edit** to change its full definition when the scenario and project are
not archived.

Organization admins can choose **Update Scenario** beside the run’s scenario
summary. Edit the steps and outcomes directly, adding or removing rows as needed.
Choose **Review Changes** to compare your draft with the saved scenario.

For AI help, describe what should change, then choose **Suggest Changes** or press
**⌘Enter** on Mac / **Ctrl+Enter** elsewhere. Suggestions include your manual edits.
Review the proposed changes; **Edit Steps** lets you adjust them directly and
**Refine** requests another revision. Nothing is saved until you choose a save action.

**Save** records a new revision. **Save & Run** saves and starts just that
scenario in the displayed environment. The original run keeps its definition and
results. If the scenario changed while you were editing, compare with the latest
version before saving. Closing the form preserves your draft.

## Test pull requests automatically

Once you have tests you trust, connect your repository in **PR Testing**. Choose when tests run and where the preview URL comes from. Verify tests relevant scenarios against the preview and posts the results to your pull request.

[Set up GitHub preview testing](/docs/verify/guides/github-previews) or [connect GitLab](/docs/verify/source-control/gitlab).

## Look for more bugs

Use **Deep Scan** when you want Verify to investigate beyond your saved tests. Give it a goal, such as “Check whether customers can cancel a subscription.”

Deep Scan can consult bundled security and QA skills while it investigates. It selects relevant guidance for the task: `dogfood` for broad functional testing, `exploratory-testing` for deeper hypotheses and state transitions, `break-ui` for realistic worst-case data, `ux-heuristics` for usability and recovery, `webapp-testing` for browser observation, and `security-audit` for security boundaries. To request a skill in your goal, write its name with a dollar sign, such as `Use $break-ui to check long names and empty states`. The agent reads supporting references as needed and tests through the scan's available controls and permissions. Cloudflare's security skill provides review guidance here; a full source-code audit requires source access and independent verification that this scan does not provide.

When sandbox coding is enabled for your organization, browser Deep Scan can also write and run scripts in its disposable VM with normal filesystem and network access. It uses `uv` for Python dependencies, npm/npx for Node packages, and CDP to connect to the scan's existing browser and signed-in session. Deep Scan stays within the assigned app and chooses the actions needed for its investigation, including creating, changing and deleting app state. It has no separate action allowlist or per-action approval step. It uses synthetic test records where practical and reports their final state. Script sources and command output are retained with the tester's report. When native sandbox coding is enabled, Linux desktop Deep Scan can use the same script and file tools in the app’s VM, alongside its GUI tools. Scripts run as the desktop user, and GUI input requires a fresh capture after a script changes state. Native apps do not imply a browser or CDP connection. macOS, Android, and authored desktop scenarios retain their existing controls.

<span id="deep-scan-goals" />
Tell it what it may change and how long to spend. Review the findings and replay the evidence before
deciding what to fix.

Each Deep Scan worker can use up to 2,000 action turns. The run may stop earlier when its goal is complete, work is blocked, or its time or evidence budget runs out. A partial result preserves saved observations and identifies unfinished work.

Multi-worker scans delegate from existing project knowledge without requiring a new application map. Native workers can reuse successful operating recipes for editor modes, command entry, fixtures and foreground input. They check current access and prerequisites before using a recipe from an earlier build.

Scans with at least three testers reserve part of their budget for independent reproduction and matched negative controls. A 25-tester scan reserves five validation slots. These workers investigate the saved candidates on fresh desktops and keep missing controls or unclear intended behavior as coverage gaps. A clean investigation wave can use its remaining slots to explore further.

Workers save observations incrementally. Recoverable native reporting errors pause input while the worker corrects its report on the same desktop. When a finding lacks supporting evidence, the correction identifies the linked check and whether it needs an issue outcome, an acknowledged action receipt, or matching worker attribution. A report correction does not repeat completed application actions. Saved results remain available if the optional written summary fails, with unfinished coverage and cleanup clearly marked. When a stopped worker leaves test fixtures behind, its cleanup notes pass to the current coordinator, including a replacement reviewer. A handoff records responsibility; cleanup remains unverified until the reviewer saves its own receipts.

When live supervision is enabled, the coordinator stays active while its workers investigate. It checks their saved progress, answers requests for help, redirects stalled experiments and can stop a worker while preserving its observations. Workers must save regular progress reports. Repeated activity without substantive progress triggers a check-in and eventually a stop. The coordinator uses one of the scan's concurrent slots; a scan with one slot investigates directly. Cloud passkey accounts use one slot to preserve exclusive credential ownership. An incomplete scan with zero findings does not establish that the application passed its checks.

If a native desktop's control connection fails after bounded recovery, Deep Scan
retires that worker and starts a replacement while time and tester slots remain.
The original worker's reports, findings, steps, and evidence stay attached to the
scan. The replacement receives the same assignment and a report handoff, then
re-establishes app and fixture state on its fresh desktop. Unsaved local changes
are not transferred. Replacement attempts use the existing lifetime tester budget.

For organizations using InferOptimal workers, overlapping Deep Scans share one
permanent inference service. The first scan enables and starts it; the last scan
disables it after its workers finish. The URL and key are reused on the next run.
This integration requires native Responses support and qualified startup
passthrough. Qualify the permanent service with a real screenshot-and-tool
Responses request before use. Provider failures are reported without silently
changing protocols or providers.

Select a tester to watch its live screen above the **Observations**, **Diagnostics**,
and **Evidence** tabs. Changing tabs keeps the player connected. Scrolling it out
of view opens the floating mini-player; its traffic lights return it to full size.

Open **Summary** to read the findings and their cited screenshots without loading
every tester’s activity archive. Choose **Load recording** on a finding to open
its recording and timeline. Each recording loads separately; if one fails, use
**Retry recording** while keeping the rest of the summary open. Copied summaries
include the cited evidence links even before you open a recording.

Describe the user outcome and the state changes you want challenged. For example:
“Using disposable test projects, challenge whether saved edits survive project
switches and restart. Look for lost text, stale files, and actions affecting the
wrong project.” Supply a test account for signed-in workflows and say explicitly
when creating, changing, or deleting test data is allowed.

Deep Scan can report an observed problem as **suspected** before an independent
reproduction. Confidence and severity describe different things: review the
evidence and uncertainty alongside the reported impact. Blocked or unexecuted
work remains untested.

## Keep your project ready

- **Knowledge** holds what Verify has learned about your app. Add any instructions or context it should know.
- <span id="project-environments" />
  **Environments** holds the versions of your app you test, such as staging or a PR preview.
- **Credentials** holds your [test accounts](/docs/verify/credentials).
- **Settings → General** lets you edit the project name, URL slug, website, and icon. **Verifier Guidance** controls terminology, behavior, reporting, and prioritization for new runs; leave a field blank to use its default. Your draft stays available when you switch sections while the page is open. **Billing** and **Organization** link to their organization settings pages.
- **Environments → Messages** is available when Composal enables Messages for your organization. Set the assistant's iMessage number and a configured Composal tester number on its Environment. It may also have a website URL. Then use iMessage steps in your scenarios. Sendblue needs an incoming message to open its reply window; a dedicated Photon line can start the conversation. Review messages and evidence in the scenario's run results.

Nightly Dreaming reviews finished runs and maintains existing knowledge, including
on days with no new runs. It prioritizes changed entries while rotating through
older lessons, preserves your corrections, and limits how many entries it can
archive in one night. This maintenance uses saved evidence; it does not establish
that an old observation is still true in the current app.

When Composal enables independent nightly checks for your organization, a project
can use one additional run per day to check up to three historical claims, with
a five-minute limit and normal usage limits. The check reuses the original
account and environment, using read-only actions. Claims requiring application
writes stay blocked. Dated results identify the specific claims and retained
evidence; blocked or unobserved claims remain unverified. Your authored guidance
is excluded, and a contradiction does not automatically rewrite it.

Scenario lessons apply to that Scenario and persona. General setup notes remain
available across the environment or project you chose. Earlier observations help
Verify navigate; current test evidence still determines each result.

### Explore scanned repositories

Open **Knowledge → Repository Maps** in your project and choose one of its connected repositories. While source is importing, the page shows its current stage, elapsed time, and a loader, and checks progress every five seconds. Storage preparation makes up to 24 attempts, five seconds apart; a terminal failure stops the loader and lets an organization admin choose **Retry Import** when the source can be retried. An organization admin can select **Scan Repository** to send the repository’s default-branch commit to Graphide. Progress updates automatically; the first map takes a few minutes. Viewing a scanned commit reuses its map, and a newer commit gets its own scan.

The map toolbar shows the commit subject, author, date, and comparison branch. For a connected GitHub repository, select the commit link to open it on GitHub. The toolbar reports how many commits the map is behind or ahead of Composal’s synced branch tip, including commits from merged branches. “0 commits behind” means the map matches that synced tip; it does not claim the mirror is current with GitHub. Diverged history shows both counts. If the history is unrelated or the comparison cannot complete within its limits, the toolbar says so instead of showing an estimated count.

Members who can access the project can explore completed maps. Graphide requires a configured server integration and an allowed HTTPS clone endpoint. Map charges may apply. Scanning is explicit; opening Knowledge never starts a scan. **Refresh Map** checks the current state and renews the viewing session. Failed scans and unavailable sessions show an error. Project documents, Memory, and Dreaming remain available in their own Knowledge tabs.

## Connect scenarios across personas

Define dependencies directly in a Scenario’s editor. For example, a submitter
sends a receipt, a processor handles that same receipt in another account, and
the submitter returns to check the result.

1. Edit the receiving Scenario, open **Dependencies**, and choose **Add Dependency**.
2. Choose when it must wait: before starting, or before one of its later steps.
3. Choose the other Scenario and the checkpoint it must complete. Waiting for
   its last step runs the prerequisite first. An earlier checkpoint allows a
   handoff while that Scenario still has work to do.
4. Save the Scenario. Open its **Execution order** tab to inspect the connected
   flow. Choose **Open** beside any Scenario to view it, or **Edit** to change it
   when you have permission. Expand its steps to inspect the instructions.
   **Overview** keeps the Scenario’s own details, steps and run history. Choose
   **Run** as usual; connected Scenarios are included without creating a
   separate workflow. Selecting several connected Scenarios runs them once.

The editor keeps **Goal** and **Acts As** visible across **Steps & outcomes**,
**Dependencies**, and **Settings**. Switching sections preserves your draft;
**Save Scenario** saves all sections together. Validation opens an affected
section and marks any other sections that need attention.

Each wait rule describes when this Scenario pauses and which checkpoint lets it
continue. Choose a Scenario before setting **Resume after**. **Open** and **Edit**
beside the selected Scenario open a new tab, so your draft stays in place. Review
checkpoint numbers after reordering or removing steps; unavailable checkpoints
stay visible until you replace them.

Connected narrative Scenarios using one Persona keep their authored steps in
one browser session. Verify does not insert another sign-in before an authored
login flow. Named actors and Account Verification keep their explicit identity
checks.

For a receipt handoff, make the processor wait before step 1 until the submitter
finishes step 1. Then make the submitter wait before its verification step until
the processor finishes processing. Each Persona retains its own isolated
session while the other acts, so the submitter can resume in the original
account. Scenarios share references to the exact same-run receipt, never account
cookies. Execution order shows the compiled checkpoint sequence. A Scenario that
resumes after another participant acts appears again with a **Continues** label.

For multiple signed-in Personas, open **Account Verification** in the editor
and configure your app’s session endpoint and the JSON paths for user ID and
email. Connected Scenarios can inherit the same verification settings. Use
permitted Environment origins when the handoff crosses applications.

Dependencies currently support Website Scenarios with up to 4 Personas,
20 connected Scenarios and 1,000 executed steps including sign-in. Verify rejects
missing checkpoints, unavailable Scenarios and checkpoint cycles that would
leave participants waiting forever. A two-way handoff is allowed when its
individual steps can still execute in order. Signup journeys with dependencies
or Account Verification need a named actor with an explicit complete
authentication step. Standalone narrative signup without Account Verification
keeps its authored signup flow.

You can also declare these connections in YAML with either the
[v1 schema](/schema/verify/v1/scenario.json) or
[v2 schema](/schema/verify/v2/scenario.json):

```yaml
dependencies:
  - scenario_id: ./process-receipt.yaml
    after_step: 2
    before_step: 2
    name: Processing finished
```

This receiving Scenario waits before its own step 2 until the referenced
Scenario finishes step 2. Count authored steps from 1, excluding inferred
sign-in, outcomes and cleanup. `scenario_id` accepts a returned `scenario_…` ID
from the same Project or a relative file such as `./process-receipt.yaml`.
Paths resolve relative to the referring file and must name a file included in
the same upload or file-run request. Author new linked files together and upload
them in one pass; no preliminary upload for IDs is needed. Saved links use stable
IDs, and download uses filenames for exported dependencies. Upload linked edits
before running their files. Use CLI 1.17.99 or later for filename lint and download.
Omission preserves existing dependencies on upload; `dependencies: []` clears
them. Recheck affected references whenever you reorder steps.

Read the [complete two-file receipt example](/skills/composal-scenario-dependencies.md)
for account verification, creating the connections, running A → B → A, and
checking each Persona's evidence. Scenarios using the same Persona share that
Persona's session. Review the full connected journey when preparing a label
run, because connected members can extend beyond the selected label.

The run stays attached to the Scenario you launched and retains every connected
Scenario’s definition and version. Editing any source or dependency requires
fresh preparation before launch. Saved reruns retain the original graph;
rerunning from latest definitions uses the current connections. A previous
attempt cannot release a new attempt’s wait.

One coordinator executes ready steps in order, retaining the other Persona
sessions and their background activity. Handoffs work with concurrency 1.
Reaching a handoff checkpoint releases the waiting step; every authored outcome
must still pass. Cleanup runs after the connected journey, in reverse Scenario
completion order, and is reported separately. Normal time limits and browser
billing apply.

## Always test changes to specific files

In the Scenario editor, add files, folders or globs under **PR File Triggers**,
one per line. The equivalent YAML field works in both Scenario formats:

```yaml
triggers:
  - ./fe
  - /api/receipts/**
  - '**/*.graphql'
```

`./fe` includes everything in the root `fe` folder. A leading `/` or `./`
anchors at the repository root; bare names such as `README.md` match at any
folder depth. `*` and `?` match within a segment, while `**/` matches zero or more
folders. Dotfiles are included and matching is case-sensitive. Renames check
both paths and deletions count.

A match always adds the Scenario and its dependencies to PR verification,
alongside automatic relevance selection. It forces fresh evidence on every PR
commit and overrides non-product path exclusions. PR Testing still needs a
connected repository, an admitted preview and the Scenario's normal access and
run permissions. Without a match, automatic selection still applies.

Use at most 100 distinct positive patterns of up to 500 characters. Negation,
comments, character classes, backslash escapes and parent traversal (`..`) are
unsupported. Omit `triggers` on upload to keep the saved list; `triggers: []`
clears it. Read the [agent path reference](/skills/composal-scenarios.md#pr-file-triggers)
for the full matching rules.

## Run on events or a schedule

Choose **Automatic Execution → Event Rules and Schedules** in a Scenario.
Configure GitHub PR event types, changed paths, target branches and an optional
condition. Add recurring cron entries with a time zone and the Project
environment they test. The equivalent YAML works in both Scenario formats:

```yaml
on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
    branches: [main, 'release/**']
    paths: ['fe/**', 'api/receipts/**']
  schedule:
    - cron: '0 9 * * 1-5'
      timezone: America/Los_Angeles
      environment: staging
if: ${{ github.event_name == 'schedule' || github.event.pull_request.user.login == 'antal' }}
```

This runs for Antal's matching PRs, at 09:00 on weekdays in Los Angeles, or
through an explicit dispatch. Branch and path filters must both match.
`github.actor` identifies the event sender; the PR author can be a different
person. `contains(github.event.pull_request.labels.*.name, 'qa')` checks a label.
The supported expression subset also includes comparisons, boolean operators,
parentheses, `startsWith` and `endsWith`.

Cron uses five fields, with minute slots at least five minutes apart. UTC is
the default time zone. Each entry requires an existing Project environment
slug or ID, such as `staging`. Required Persona credentials must be configured.
Schedules appear under **Scheduled Runs**, where you can pause or resume them
and open their Scenario to edit the rule. Missed windows catch up once;
overlapping occurrences are skipped. Editing a rule invalidates an old captured
occurrence, and losing administrator authorization pauses the schedule.
Broken dependencies automatically suspend affected timers. Repairing the
dependency resumes those timers while preserving manual pauses. An unavailable
environment affects only its own cron entry.
For a credential suspension, repair the configured credential and choose
**Resume**; you do not need to edit the Scenario again. Managed timer rules
are edited in their source Scenario. Use one cron root per intended connected
journey; its dependencies join that run. Cron on another member creates another
timer and can launch a separate run.

Cron entries keep results in run history and do not configure scheduled email
or Slack reports. Other configured notifications still apply.

Agents can dispatch saved Scenarios on demand without any event declaration:

```bash
com verify dispatch --project receipts --environment staging \
  --scenario <returned-scenario-id> --idempotency-key receipts-dispatch-001 --json
```

Manual dispatch includes connected dependencies and ignores automatic `on`/`if`
rules. Explicit event matches select fresh verification and include dependencies.
They still require normal permissions and an admitted target. With no `on`,
automatic relevance selection and the existing `triggers` path list keep their
behavior. `on: {}` disables automatic selection; ordinary manual runs remain
available. Omit fields on upload to preserve them, or clear both `on` and `if`
with `null` to restore relevance selection. Read the
[full event and cron reference](/skills/composal-scenarios.md#event-rules-and-schedules)
for supported filters, expressions and target rules.

## Prefer your terminal or coding agent?

[Install the CLI](/docs/quickstart) to run tests from your terminal, or [connect your coding agent](/docs/agents). You can also write scenarios as files and keep them in your repository.

<span id="fixtures" />
### Share files across runs with Fixtures

Open **Fixtures** in your project's sidebar to upload, search, download, rename,
or archive the files agents upload during runs. Project administrators manage
files; members can browse and download them. Each file can be up to 25 MiB.

Choose **Edit** to assign a file to any number of personas, credentials and
environments. A new run gets every file assigned to its environment, to the
persona of the Scenario or of any of its actors, and to the credential each one
signs in with, alongside the files the Scenario attaches itself. The Scenario
page lists these under **Inherited Files**. A run can carry up to 100 files
totaling 100 MiB, and two different files with the same name block preparation.

Assignment changes need fresh preparation and approval; approved runs keep the
files they were prepared with. Archiving a file stops new runs inheriting it but
keeps it for Scenarios that attach it and for run history. Uploading the same
file again restores it without its old assignments.

<span id="local-runs" />
See the [scenario reference](/docs/verification) for test files and the [CLI reference](/docs/cli)
for commands, uploads, and local runs.

### Optional cleanup

Use **Cleanup (optional)** in the Scenario editor, or add a `cleanup:` list to its
YAML file. These instructions run after the checks pass or fail and have a
separate result. Leave cleanup empty when none is needed; the agent does not
invent deletion or state restoration. Browser shutdown and recording finalization
still happen automatically. Cleanup can remain incomplete if time or access runs
out.

```yaml
cleanup:
  - Delete the draft created during this run.
```

When updating an uploaded file, omitting `cleanup` preserves saved instructions;
`cleanup: []` clears them. Keep deletion that the Scenario tests in `steps`.

## Testing a desktop, Android or iPhone app?

<span id="desktop" />
<span id="android" />
Choose **Computer use** when creating your project. These tests need a supported desktop image or
Android APK or zipped iOS simulator app instead of a website URL. [Read about the Verify agent and supported
environments](/docs/verify/agent).

### iPhone app builds

Choose **iPhone app**, upload a `.zip` containing one `.app` at its root, and
describe what to test. Build for an Apple Silicon **iOS Simulator**; device IPA
and App Store builds are unsupported. Archives can be up to 500 MiB and cannot
contain symlinks or files outside the app. For example, run
`zip -r -X Composal-simulator.zip Composal.app` from the build products directory.

Each tester installs the checksum-pinned build in a new iPhone simulator on a
disposable Namespace Mac. Create a Scenario with the iPhone interactions and
observable outcomes, select this environment, and choose **Run**. The agent uses
computer use to operate the simulator. iPhone recordings and saved screenshots
capture only the simulated iPhone display, including Safari and the iPhone app
switcher during a journey. The Mac desktop and Simulator toolbar are excluded.
Inspect the recording and each outcome in
the run report. Uploading a build alone does not execute a test. To test another
build, add another environment with its upload. Use test accounts and synthetic
data for actions against a live service. To test sign-in, save an email/password
credential with the app's HTTPS login URL and assign it to the Scenario's persona.
The runner submits that account privately in Safari on the test iPhone before
recording. The Scenario must then complete the app's browser approval and verify
the native account; browser setup alone is not a passing sign-in. MFA and provider
logins are not supported by this iPhone setup. Keep simulator code signing enabled
when building apps that store credentials in Keychain.

### Journey branches

**Product map** opens to **Flows**, with a compact task list beside the selected
flow. Select a name to preview that flow without opening the graph. Search with
**Find a flow** or choose a persona to narrow the list. On a phone, choose a flow
from the list and use **Browse flows** to return. You can close the desktop list
for more preview space and reopen it with **Browse flows**. Each flow shows up to
three key screens from the first part of a retained recording, arranged
top to bottom with numbered headings and arrows between them. Scroll down to follow
the sequence. When the preview omits later screens, **View all screens** opens the
full flow in the map. The list, walkthrough and inspector scroll independently. Use
**All personas** to select whose observed experience to browse, or search for a
task. A missing persona attribution is shown explicitly; it does not establish
which other roles can access that flow.

Select a screenshot to inspect it alongside the flow. The inspector lets you
move between key screens and expand the capture. **Details** contains the complete
recording, intermediate states, observed persona, outcome and replay controls.
On small screens, inspection uses the full workspace. **Back to flows** returns
to your place in the list; **Esc** closes the inspector when it has keyboard focus.
The flow heading names the recording part shown. A failed capture has a **Retry Image** action.
Open **Recording history** in the inspector to browse earlier executions and their
replay controls. **Load earlier variants** continues beyond the recordings retained
in the shared tree. Browser Back restores the previous map tab.
**View map** focuses the flow's recorded path in the graph; the **Map** tab explores
the app's connected views and **Screens** browses captures. Close the **Journeys**
rail or **Screen details** panel with its close button to give the graph more space.
Use the small journey or details button beside the graph to reopen either panel.
Closing a panel keeps the selected flow and screen; selecting another screen opens
its details again. Open **More map options**
for **Areas**, **Unexplored**, **Compare revisions** and inventory counts. The filter
button shows how many additional filters are active.

Select an app view to read its recorded connections one at a time: source view,
action, and destination view. Choose another connection from **Arrive here** or
**Leave this view**; on smaller screens, use the connection picker. Screenshots
represent each view, and each choice retains one recorded connection rather than
combining separate recordings into a journey. Select a preview to inspect its
evidence, use its expand button for the full capture, or **Follow connections**
to explore the neighboring view.

Choose **Show full graph** to inspect all connected views with pan, zoom, and
**Fit**. **Back to connections** returns to the reader. Both presentations use
the graph already loaded. **Show journeys** opens the journey list.
**Back to section** or **Esc** leaves focus and restores the previous map position.

Open a flow to follow one recorded path, with numbered
milestones and its observed result. The expected end condition stays in **Evidence**;
opening a form does not establish that saving succeeded. **All paths** loads the
shared journey tree when you want to compare executions. Separate runs contribute
paths to the same task; their original execution evidence remains separate.
The URL retains the task, path and selected capture. Refresh or return to that link
to restore your place. Filters keep the selection when its evidence is still in
scope; an unavailable path prompts you to change filters or choose another journey.
Concurrent discoveries of the same task share a parent when they publish.
Confirmed duplicate parents are grouped into one card, tree and coverage total;
their original variant evidence and old detail links remain available. Matching
retrieves relevant parents across the scoped project. New interpretations use a stable task key independent of methods and outcomes; legacy fallback matching uses an exact title and goal. Suspected duplicates require review rather than merging on title alone.

Choices must cite visible peer controls on their original source screen.
Back, cancel, recovery, typing and automatic changes remain recorded events;
they do not become extra chooser options. Unsupported retained annotations stay
in the original evidence and are flagged for review, outside choice coverage counts.

The tree counts supported alternatives as **Observed**, **Blocked**, **Needs evidence**,
or **Unexplored**. Use **Show path** to inspect an alternative's recorded variant.
Observed means the retained execution has a matching action receipt; it does not
establish that the complete user goal passed. Replay and qualification remain
separate. Coverage is scoped by the selected revision, account and filters.

The inventory grows as Discovery explores. Counts describe known alternatives,
not a percentage of every possible flow. Older variants without branch annotations
still appear as paths and are explicitly excluded from known-alternative coverage.
App-wide totals include all retained variants, even when a journey tree limits its path preview. Missing receipts remain explicitly unresolved.

Matching rejoin labels mark separate recorded paths that reach the same view in
the same revision. The map keeps each sequence separate; a rejoin label does not
establish a new transition or replay coverage. New captures label temporary loading,
retry and error feedback as states of their parent view when the screen context
supports that identity.

Documentation views under `/docs` and `/documentation` use their observed URL as
the parent page, even when visual labels differ. In-page anchors share a page;
query variants and different origins remain separate. URL grouping does not create
observed navigation or merge screenshot state evidence. The source inventory also
includes eligible Markdown, MDX, sitemap XML and navigation manifests. These are
planning evidence; linked pages still need browser observation.

Mapped Discovery also builds a navigation inventory automatically. It reads
same-origin `robots.txt` sitemap entries, `/sitemap.xml`, nested sitemap indexes,
and links from rendered pages and fetched HTML. Tracking parameters and ordinary
page anchors are deduplicated; meaningful query and hash routes remain distinct.
The shared map's **Unexplored** view lists these destinations and their source.
Discovery receives the same inventory when planning its next steps.

The crawl is bounded to 200 pages and 24 requests per browser attempt, with a
10-second cumulative work budget. Redirects, external origins, credential-bearing
URLs and known action endpoints are excluded. It does not submit forms or execute
fetched scripts. Fetching HTML is planning evidence: a page still needs an actual
browser capture, and a journey still needs recorded actions and outcome evidence.
A limit notice identifies incomplete batches. Crawling is enabled for mapped
Discovery runs; ordinary scenario execution does not enable it.