# Verify overview

Run browser acceptance journeys against a managed environment or an existing URL.

## What Verify does

Verify sends browser agents through user journeys you define, checks the expected outcomes, and keeps a replayable record of what happened. A run uses a **ready environment revision** and an **immutable scenario pack**. The environment says where the app lives and what the agents may access; the pack says which personas, actions, and assertions to run.

An environment can be a Composal-managed shadow or simply an HTTP(S) URL for an app you operate. A repository is optional. Connect one when you want to select journeys from a Change or pull request; a manual or scheduled run can use an environment and scenario pack without any repository.

Verify is for acceptance journeys such as signing in, creating a discussion, replying, searching, and checking access boundaries. A pass means the selected assertions passed in that run. It does not mean every feature of the app was tested.

## Start a run

You need Verify enabled for your organization and administrator access to configure targets or launch runs.

1. Open `/<organization>/verify/runs` and choose **Add Environment**. Select a managed shadow or register an existing URL. Give the URL an accurate label, such as staging or production, and wait for the revision to be **ready**.
2. Prepare a scenario pack for the app. The `com-verifier-setup` skill can turn an agreed UAT plan into a secret-free blueprint and focused scenarios. Review and import the pack, then find it under **Scenario Packs**. Store login values in **Verify → Credentials**, not in the pack.
3. Choose **New Run**. Select **Manual**, the ready environment, and the scenario pack. Choose **Review selection** to see the exact journeys and any blockers. Set the run duration and maximum concurrent agents, then launch it.
4. Open the new run. **Live** shows each agent's current state and browser preview. After it finishes, use **Results**, **Replay**, **Logs**, and **Artifacts** to inspect assertions and evidence.

The run is accepted before a browser agent starts. It may show **Queued** while dispatch and agent capacity are pending. See [how the Verify agent runs](/docs/verify/agent#queue-and-concurrency) for what that state means.

## Choose a trigger

| Trigger | What you provide | Scenario selection |
| --- | --- | --- |
| **Manual** | Ready environment and pack | Every authored scenario. No Change or repository required. |
| **Change** | Change number, optional patchset, repository-backed environment and pack | Journeys selected from the Change diff and scenario ownership. |
| **Pull request** | PR reference and repository-backed pack | Every authored scenario in the current flow. |
| **Time / cron** | Schedule name, cron expression, timezone, ready environment and pack | Every authored scenario at each scheduled time. No Change or repository required. |

Review a Change selection before launching: unknown or incomplete ownership can expand the selected set. Scheduled runs appear on **Runs**, where administrators can pause or resume the schedule. Event, webhook, and CI triggers are not available in this flow yet.

## Read the result

An attempt can fail because an application assertion failed, the browser agent could not complete its journey, or a runner or environment was unavailable. Inspect the failed step, browser events, and artifacts before calling it an app defect. Findings collect reproducible failures; a blocked or inconclusive journey does not count as a pass.

Continue with [the Verify agent](/docs/verify/agent) to understand execution and concurrency, or [scenario and MCP reference](/docs/verification) to configure packs, credentials, and remote tools.