ComposalVerify
Verify overview
Run browser acceptance journeys against a managed environment or an existing URL.
On this page
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.
- Open
/<organization>/verify/runsand 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. - Prepare a scenario pack for the app. The
com-verifier-setupskill 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. - 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.
- 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 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 to understand execution and concurrency, or scenario and MCP reference to configure packs, credentials, and remote tools.