Verify reference

For the short, three-step introduction, start with Get started with 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. 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.

1 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. 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.

2 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.

3 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 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 or connect 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.

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.
• Environments holds the versions of your app you test, such as staging or a PR preview.
• Credentials holds your test accounts.
• 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 or v2 schema:

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 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:

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 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:

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:

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 for supported filters, expressions and target rules.

Prefer your terminal or coding agent?

Install the CLI to run tests from your terminal, or connect your coding agent. You can also write scenarios as files and keep them in your repository.

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.

See the scenario reference for test files and the CLI reference 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.

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?

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.

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.