Data-grounded test automation
The toast said Saved.The numberwas wrong.
A passing UI test proves the screen looked right. VerifyBeyond reconciles it against the row your database actually holds — inside the same test. Any divergence fails the run.Prove the data behind the screen.
Drag the dial on the panel
The break
A green check proves the pixels.
Not the record.
A test that asserts on a toast proves the toast. The eight rows below are what that gap costs — and what closing it looks like.
click Save assert toast == "Saved"
Looks right. Proves nothing about the data.
click Save
assert toast == "Saved"
db policies WHERE id = {{extract.id}}Same run. Now it tells the truth.
The data checkpoint
Author-time is agentic.
Runtime is frozen.
Inside one functional test, a DB checkpoint reads the real row your flow just created and compares it to the screen. The AI proposes the query; runtime executes a frozen, parameterized, read-only query with no model in the loop.
D-01Which row+
A value extracted during the flow — the id of the record this run just created — becomes the row-identity key. The checkpoint verifies that exact row, not “a” row.
extract.policyId → WHERE id = {{extract.policyId}}D-02Sources & transports+
SQL (PostgreSQL, MySQL) and API / OData, read either directly or through the customer-hosted connector.
D-03Eventual consistency+
When the write lands a beat after the click, the read-only check polls with backoff before it decides — so async and microservice backends don’t flake.
D-04Schema drift+
Re-introspect and diff against the stored snapshot, so a dropped, renamed or retyped column a checkpoint depends on surfaces as a functional risk — not a silent runtime error.
policies.premium numeric kept policies.status text renamed → state (−) policies.agent_id int → uuid retyped (~)
D-05Never rewrites the answer+
Self-healing may relocate a drifted element. It will never rewrite an assertion’s expected value — the discipline that keeps the data verdict trustworthy.
D-06Opt-in · off by defaultWrite verification & seeding+
A separate, isolated writable identity — never the read credentials — can seed the exact scenario a test needs and verify the UI wrote the right values, then auto-tear-down.
The connector · data residency
Your credentials never leave
your network.
The connector runs inside your network, holds the credentials locally, and dials outbound — nothing dials in. VerifyBeyond stores only a routing id, and every query is read-only by four independent layers.
Data-correctness monitoring
The same test, on a schedule,
against production.
The same test becomes a production monitor: scheduled runs execute the data checkpoints and alert on a screen-versus-database mismatch — not just uptime.
Discovery & onboarding
Hand it a URL.
Get back the map.
Point VerifyBeyond at an application. It crawls it — authenticated logins included — describes every flow in plain English, correlates each flow’s real XHR/fetch calls to your schema, and proposes a read-only DB checkpoint per flow. Then it can generate runnable tests, checkpoints already inside.
Authoring — the on-ramp
Describe the flow in English.
Run it pre-validated.
Describe the flow in plain English. VerifyBeyond drives the draft against your live app in a real browser before you ever run it, promotes the selector that actually worked, and demotes the guess to a fallback. You never run an untested test.
“log in as a sales rep and open the dashboard”
- Login field#login
- Navigationguessed route
- Dashboard loadfixed 3s wait
- Login field#usernamefallback #loginresolved on the live DOM
- Navigationstate advanced — logged infallback guessed routereal app state advanced
- Dashboard loadwait → url '/dashboard'fallback fixed 3s waittiming gated on the real URL
Quality advisories
flaky test · degrading performance · fragile selectors · missing assertions · timing sensitivity · data dependency
each with severity · evidence · recommendation
AI test-data generation
valid · boundary · edge-case · user-type
covers every field; suggests which hardcoded values become parameterizable
Self-healing, with vision fallback
Relocates the element,
never the answer.
Self-healing is table stakes. The discipline is not: when a selector breaks at runtime VerifyBeyond sends a screenshot and the surrounding DOM to the AI, re-routes to a stable anchor, keeps the run going, and saves the fix — but it will never rewrite an assertion’s expected value.
Vision fallback · opt-in · cost-governed
When no selector can be found, an optional vision tier points at the element by sight on the screenshot. It is cost-governed and off unless enabled.
Reaches canvas, legacy and thick-client UIs where a stable selector may not exist.
Verdicts you can trust
Every outcome carries a severity.
Every step outcome combines with a criticality to produce a run status — which is exactly what makes a fuzzy check safe to adopt.
Failure diagnosis
- root cause
- insert to policies did not commit
- failing step
- DB Validate · premium
- suggested fix
- check the save handler’s transaction
- confidence
- high
- category
- data_layer
The DB write failed — a real bug, not a flake.
AI Assert
For dynamic UI where an exact assertion is brittle, a step carries a natural-language criterion and an LLM judges the live page — wrapped in the severity model so a fuzzy verdict warns rather than breaks.
Natural-language criterion defaults to soft
“the confirmation clearly states the order was placed and shows an order number”
Execution engine
Seventeen action types,
real Chromium.
Tests run in real Chromium via Playwright — genuine clicks, form fills, navigation and network activity, not HTTP stubs. Three of the seventeen read or write your data.
Assertions
targets visible · hidden · text · value · url · attribute · count
operators equals · contains · matches · greaterThan · lessThan
Templating
{{fieldName}} parameterized test data
{{credential.template.field}} encrypted stored credential
{{extract.key}} a value captured earlier — incl. a seeded row’s id
{{collab.key}} data passed from an earlier test
Change detection
Every passing run
sets a baseline.
Later runs compare against it and flag screenshot and DOM drift — structure, content and attributes — each rated by severity. Built-in visual regression, no extra tooling.
- lowScreenshotPixels changed in the header region
- mediumDOM structureTwo elements added to the form
- mediumDOM contentPrimary button label changed
- lowDOM attributeClass renamed on the call-to-action
Collaborated workflows
Chain tests. Pass data forward.
Create a record in one test, verify it in another — the entity id threads between them. Choose what happens when a step fails.
Signals vs proof
Scattered signals.
One reconciled record.
A run throws off a dozen loose signals — a toast, a row, an API call, a log line. On its own each proves nothing. VerifyBeyond reconciles them into a single record that says what actually happened to the data.
- screen == db.policies row
- premium 1,248.00 · matches
- api 201 · row landed
- evidence · immutable
Reports & the evidence trail
Ten report types.
One auditable trail.
Ten report types, each with an AI-written narrative, exportable to DOCX / XLSX / PDF with tokenized share links — plus a per-run evidence trail that records how every step was verified.
Verify AI-written code
A coding agent that can
check its own data.
A standalone MCP server lets a coding agent verify real data while it writes code, through the same read-only guard as the product.
A standalone MCP server lets a coding agent — Claude Code, Cursor — verify real data while it writes code. It holds only a scoped, read-only API key; every check runs through the same read-only guard as the product, and for on-prem sources it is answered inside the customer network by the connector.
Governed verification loop
- coding agentdiscovers sources · reads schema · runs a check
- MCP serverscoped, read-only API key
- read-only guardthe same guard as the product
- your datadirect — or in-network via the connector
Scale & structure
Organized from the app
down to a single step.
A clean hierarchy, multi-tenant by design, with environments and named data sets at every level.
Trust & governance
Security and transparency
are the foundation.
Built for teams that answer to auditors — isolation, access control, and a complete trail, stated as guarantees rather than badges.
Multi-tenancy
Full isolation via PostgreSQL row-level security, on a non-superuser app role
Access control
Four roles — Admin, Manager, Tester, Viewer — enforced on API and UI
Encrypted credentials
At rest, with automatic masking as •••••• — never written to logs
Audit log
A full, immutable trail of tenant activity
Rate limiting
Per-tenant AI limits with complete token and usage accounting
Platform administration
Tenant management with suspend enforcement
Real-time updates
Runs and results stream live over WebSockets
Under the hood
Colophon.
- AI engine
- Anthropic Claude
- Browser
- Playwright / Chromium
- Data adapters
- PostgreSQL · MySQL · API/OData
- Transports
- Direct · customer-hosted connector
- MCP server
- Standalone service
- Web
- React + Vite
- API
- Node.js + Express
- Workers
- BullMQ on Redis
- Database
- PostgreSQL (row-level security)
- Realtime
- Socket.IO
- Deployment
- Docker · cloud-hosted
How it works
From a sentence
to proof.
Ten steps, end to end. Watch it — or click through — from a line of plain English to a record you can hand an auditor.
“create a policy for a new client and confirm the premium saved”
From a sentence to a test that proves the data.
No trial, no credit card, no sign-up — a conversation, and access when you’re ready.
Request access