Trace the lineage
Select any node to read its recorded detail. Drill up to remove sibling noise; drill down to follow every branch produced from that item.
What it does
The holy grail of testing
One-click AI-automated test frameworks for every test imaginable.
Give it your requirements. It architects the test framework, designs the tests, writes the automation code, runs it against your system and files the defects. Every check traces back to the requirement that justified it, across UI, API, database, migration, system-integration and end-to-end testing.
Thirty years of enterprise testing practice, encoded into proprietary orchestration algorithms designed to drive coverage gaps toward zero.
Recorded archetype runs: API component testing · AI guardrails & prompt-injection resistance · all 68 archetypes
Read from your specification, never from your code. Every test that follows keeps the id of the requirement it proves.
GrailTest AI
SRC: PIPELINE
The film
GrailTest AI
SRC: RECORDED RUNS
The agents
Autonomous agents run the testing: analysing requirements, generating automation scripts, executing checks and raising defects. They learn from iteration feedback—using failures and coverage gaps to improve the next candidate.
A breakthrough in testing visibility: inspect the score, the evidence and the path taken. The observability layer connects recorded actions, feedback, retries and acceptance decisions to generated code and execution results.
GrailTest AI
SRC: PIPELINE
The frameworks
Most teams already test with open-source frameworks: Selenium, Playwright, Pact, Karate, Cypress and many more. GrailTest AI writes the automation for you and traces every check back to the requirement it proves.
The recorded runs on this demo were generated and executed as Playwright suites. Generating directly into the other frameworks shown here is planned.
Generated and run on the demo todayRuns locally, boundedPlanned
GrailTest AI
SRC: PIPELINE, LIBRARY
The audit trail
Every decision the orchestrator makes is recorded with the rule it applied and the measurements it applied that rule to — so a reviewer can check why an iteration was kept or thrown away rather than take a sentence's word for it, and each record links back to the decision it followed from. Open a stage to inspect its scoring components, weights and measured outcomes, and follow the iteration ledger to see what improved and what was rejected. Duplicate-defect checks help keep repeated findings from inflating the result.
Bring existing software into a measurable improvement loop through brownfield analysis and configurable target adapters. Inspect generated Playwright tests, expose coverage gaps and use the evidence to guide improvements to an existing suite.
Agent adapters are available for Claude Code, OpenAI via Codex CLI, and local Ollama models. Local execution depends on model size and hardware capacity; provider access depends on your configured account and entitlements.
Enterprise integrations, planned. MCP connections to Jira, Confluence, SharePoint and other knowledge bases; validation of Amazon Bedrock deployments and Apple Silicon configurations; and deeper integration with existing test frameworks. These integrations are not demonstrated in this recorded release.
GrailTest AI
SRC: DECISION LOG
Mutation
<=<
Coverage tells you a line ran. It does not tell you anything would have failed if that line were wrong. GrailTest measures the difference: it changes the implementation one edit at a time — a <= becomes <, an equality flips, a boundary shifts by one — and reruns the generated suite against each change.
A change the suite catches is a test doing its job. A change nothing notices is a blind spot, stated as a measured fact rather than an opinion. Only tests that passed against the unmutated build count as catches, so a suite carrying a single pre-existing false alarm cannot report a perfect result against code it never touches.
In the recorded run you can explore below, 1,323 behavioural changes were injected and 291 were caught. Read that number with its scope: this demo orchestrates one requirement. BR-500 has 25 generated checks, and mutation was scoped to the four files that requirement touches — files which also implement payees, cut-offs, cancellation and the rest of the bank. Most of the 1,032 undetected mutations therefore sit in behaviour no check in this run was ever written to exercise. They are unattempted, not undetectable: orchestrating the remaining requirements puts them under test, and the next round records which of them are then detected.
Every mutation is listed individually in the run — file, line, mutator and replacement, one row each, filterable — so the claim is inspectable rather than a headline. Each survivor is handed back to the test-writing stage as an objective carrying its requirement but never the file, line or edit, so the next suite has to reason its way to a test from the specification rather than pattern-match the answer.
A reviewer can classify a survivor as equivalent or out of scope with written evidence. That closes the objective and is reported as an adjusted score beside the raw one — it never rewrites the measurement, because a score a team can talk upwards is not a measurement.
GrailTest AI
SRC: RUN BR-500
The finished run
Move through the pipeline, inspect the generated files, and isolate a lineage in the 2D or 3D traceability map. Every visible item comes from the recorded banking test run.
Compact enough to copy into a review, precise enough to retrace in the map.
BR-500 payment ≤ $10,000
│
└── SC-500-001 inclusive boundary
└── EC-500-001 exactly $10,000
└── TD-500-001 reset + submit
└── CHECK-500-001 ✓ PASS
Select any node to read its recorded detail. Drill up to remove sibling noise; drill down to follow every branch produced from that item.
Open scenarios, edge cases, test data and the recorded execution index. Passing, failing and voided attempts remain visible with their reasons.
Use the live Meridian Bank sample below: a UK Faster Payments portal with accounts, payees, cut-offs, OTP and payment limits.
GrailTest AI
SRC: RUN BR-500
The system under test
The actual system under test
Meridian Bank is the working payments application behind this demonstration. Sign in, inspect accounts and payees, or follow a payment flow—the generated TypeScript, execution results and defects shown above were produced against this system.
This bank is only a sample. Point GrailTest at another system, its requirements and available interfaces, and it can produce automation test scripts and end-to-end traceability for that system’s own stack and testing archetype.
alice@meridian.test
Passw0rd!
GrailTest AI
SRC: MERIDIAN BANK
What comes next
Join the waitlist for product updates and early-access invitations. We will only use your address to contact you about GrailTest.
GrailTest AI
SRC: —