Who approved this test?

The problem

AI can write a Playwright test. That stopped being hard about two years ago — your developers are probably already doing it in GitHub Copilot or Claude Code.

Here is what is still hard: nobody can tell you where a test came from.

Open your regression suite and pick a spec at random. Which requirement does it cover? Which version of that requirement — before or after the acceptance criteria changed in March? Did a person read it before it merged, or did it get rubber-stamped inside a forty-file pull request on a Friday afternoon?

For most teams the honest answer is a shrug, a stale spreadsheet, or a week of archaeology.

That was survivable when the only people asking were your own team. It is not survivable now, because the people asking have changed.

• A customer's security team sends a questionnaire asking how test coverage is verified.
• An auditor asks you to show, for one release, the requirement, the tests, and the sign-off.
• Under CPS 234 standards (APRA), control effectiveness must be tested through a systematic program — and "systematic" means you can produce the record.
• A board that has just worked out how much AI is in the SDLC asks who is checking its work.

And the more tests your team generates with AI, the worse this gets. Volume without provenance is not coverage. It is a liability with a green tick on it.

What the platform does

It closes the loop between the requirement and the merged test, and it keeps the receipt.

Point it at a Jira project and a Git repository. It pulls requirements, scores them for ambiguity and testability, drafts test cases grounded in your team's own approved patterns, and turns approved cases into Playwright specs, page objects and flows that honour your existing layer rules. Then it opens a pull request.

Every artifact stops at a human first. Every artifact carries its lineage.

How it works

1. Pull and version the requirement

   Each Jira change becomes a new version, so a test is always tied to the exact wording it was written against.

2. Critique it

   Ambiguity and testability scoring, with concrete rewrites. Most bad tests are bad requirements wearing a costume.

3. Draft the test cases

   Retrieval runs over your own corpus — previously approved cases, real page objects and fixtures from your repo, crawled app structure, connected Confluence spaces. The output looks like your team wrote it, because it learned from what your team approved.

4. Review

   Cases and generated code land in a diff view. Approve, or reject with feedback that goes straight back to the authoring agent.

5. Publish

   Approved work becomes a branch and a pull request, linked back to the Jira issue. Ordinary Playwright. Your repo.

Everything except the review is run by agents. Ten kinds of work move through a queue that any number of workers can claim from: pull Jira, critique a requirement, draft the cases, crawl the app, diff the map, write the script, typecheck and dry-run it, reconcile coverage, open the pull request. A scheduler keeps the Jira pull running on its own. Shared resources — the test account, your repo's working copy — are held under time-boxed leases, so two runs never collide over the same checkout. Every step streams to a live timeline you can watch.

You orchestrate none of it. There is no pipeline to babysit and nothing to kick off by hand. The one thing the agents will not do is step 4: the system emits an event called ladder.escalated_to_human, because handing work back to a person is a designed outcome, not a failure.

The orchestration runs the whole pipeline and stops at the approval. That is the only place it stops.

It onboards like a new hire — and it doesn't leave

Most AI-generated tests are wrong for one reason: the model has never seen the application. It guesses at selectors, invents page objects that do not exist, and writes flows nobody on your team would write.

So before it writes anything, the platform learns the app — the same way a person would.

It starts where onboarding always starts: with access. Give it a test account on your staging environment — the same one you would hand a new starter on their first morning — and it signs in and goes exploring. It walks the application from wherever the login lands, following links from screen to screen under the page and depth limits you set. Read-only by default: it looks, it does not touch, unless you explicitly allow-list a write path.

What it takes away is a map. Every page is reduced to a stable identity that survives volatile URL segments, given an accessibility fingerprint of its structure, and joined to the pages it leads to by edges labelled with whatever you clicked to get there. Cosmetic churn does not move the fingerprint. Structural change does.

That is roughly what a new engineer does in their first fortnight — clicking through the app, working out that "checkout" is really four screens, learning that your team puts waits in the flow layer and never in the spec. The difference is what happens next. A new starter keeps it in their head. The platform records all of it in the project's knowledge base, alongside the page objects, flows and fixtures already in your repo, the acceptance criteria from Jira, your connected Confluence spaces, and every test case your team has approved.

That is the whole difference. In most teams, application knowledge lives in people. When the engineer who understood the payments flow resigns, the knowledge resigns with them, and their replacement rediscovers it at full price. Here it is a project asset that only accumulates: every crawl, every approved case, every rejection with feedback deposits into the same corpus. Re-crawl after a release and the new map diffs against the last one — new page, removed page, changed structure, new route — so the platform notices the screen your regression suite has not heard about yet.

The people change. What the project knows about the application does not.

Three things that make it different

Who it is for

Engineering and quality leaders at teams of roughly 25 to 250 engineers who use Jira, run Playwright — or are migrating to it — and answer to somebody: a regulator, an auditor, an enterprise customer's procurement process, or a board.

If you have two QA engineers covering forty developers and a security questionnaire sitting in your inbox, this was built for you.

What it is not

• Not a replacement for your QA team. The opposite — a human reviewer is structurally required. What changes is that your QA engineers stop writing boilerplate and start owning coverage, review and quality strategy.
• Not a record-and-replay tool. No proprietary runner, no vendor cloud your tests execute in, no self-healing black box.
• Not mobile or native app testing. Playwright, web, today.
• Not autonomous. By design. Anything that merges test code without a human is solving a different problem than the one we care about.

Where your data goes

Isolation is layered, and it is the database that holds the line — not the application.

Every domain query goes through a single seam that pins the connection to one organisation and one project. Underneath it, Postgres row-level security enforces the boundary in the database itself: a forgotten WHERE clause returns nothing rather than somebody else's data. The test suite proves that rather than asserting it — a deliberately unfiltered SELECT still returns only one org's rows, and a guard fails the entire suite if the test role could bypass RLS, so it cannot pass for the wrong reason.

Above that sits a storage tier. By default, organisations share a schema and are held apart by row-level security. Enterprise organisations get their own dedicated tenant schema — tenant_<slug> — where their tables are physically separate from every other customer's. The schema definition is byte-identical in both modes, so moving up a tier is one transactional data migration rather than a different code path. It also makes removal a single operation: drop the schema and that customer's data is gone, all of it.

Credentials are encrypted per organisation with AES-256-GCM. Enterprise deployments pin their own region and bring their own model API keys, so the contract with the model provider is yours.

Try it yourself

Nothing is generated until you ask. Nothing merges until you approve. The crawl is read-only unless you allow-list a write path. When it earns its place on one project, add the next one.