AI software verification
You do not have to replace your test runners, scanners or coding agents. Keep them and add The Warden: each verifier submits evidence for the exact build, and a deterministic policy decides whether their combined proof is enough. AI may help explain a decision; it never makes one.
Evidence for any other build does not count toward this decision.
The Warden is still verifying.
Run 8841 announced. No evidence yet for build 4821.
Build. A change arrives as an exact commit and build: 9f3c2a1, build 4821. CI announces run 8841. An announcement is never evidence.
The problem
A coding agent that writes the change, writes the tests, runs them and reports success has verified consistency with itself. Letting that loop also declare the change ready makes every other gate negotiable.
Agents can submit evidence. They cannot announce runs, select a state, grant approval or clear a change.
The agent may fix the software. The Warden decides whether the fix is sufficiently proven — and the original HELD decision stays in history.
How it works
Identified by repository, commit, build and environment, never by title matching. The verification target only moves forward; a submission for an older build is history and never clears.
JUnit XML, SARIF 2.1.0 and provider-neutral JSON from CI, runners, scanners, reviewers and agents, each tied to the exact build and stored immutably with a content digest.
A versioned Verification Contract states what must be proven. Today the default contract requires a complete, current-build automated test run no older than 24 hours with no failed, error or skipped observations.
CLEARED, VERIFYING, HELD, NEEDS APPROVAL or INCOMPLETE, with fixed reason codes and next actions. Append-only: fresh evidence for a new build produces a new decision and never rewrites an earlier one.
Keep your tools
TestWarden does not ship first-party adapters for Playwright, Cypress, Semgrep, Sonar or any other named tool. Read-only connectors for test-management platforms are described on Integrations, with their real status. What it accepts is a report format your tool can already produce, delivered from CI over the Forge App REST API. The CI recipes are in the CI evidence docs.
| Source | What you submit | Status |
|---|---|---|
| Playwright, Cypress and other test runners | Emit a complete JUnit XML report from the CI job and submit it. Any failed, error or skipped observation prevents a pass. | Compatible report. Not a Playwright or Cypress adapter. |
| Semgrep and other scanners | Submit a SARIF 2.1.0 report from the scan step. It is recorded as scanner evidence and cannot satisfy the test-run obligation. | Compatible report. Not a Semgrep adapter. |
| AIO Tests, Xray, Zephyr Scale, TestRail and Azure DevOps | Today, a complete JUnit XML report that your CI produces. Read-only connectors that fetch results from these platforms are in source and under acceptance. | Connectors are not live. See Integrations. |
| Anything else | Send a provider-neutral JSON envelope of 1 to 20 observations with a declared producer type, name, source system and run ID. | Compatible format. Not a vendor integration. |
An external tool's green result, approval or score is evidence, never CLEARED. A scanner or reviewer pass cannot satisfy the test obligation. Limits: 256 KiB per request, 1 to 20 observations, and a gzip-base64 JUnit wrapper up to 2 MiB raw.
Policy and AI
The same evidence under the same contract and policy version produces the same decision today and in a year, which is what makes decisions replayable in an audit and safe to enforce at a merge or deploy boundary. The Marketplace version ships no user-facing AI and declares no external egress.
Beyond the Marketplace version, a developer pilot lane adds a Developer API, a PowerShell client, an MCP server with six typed tools and a GitHub Action preview, so a developer or agent can ask what is obligated, why a change is HELD. Approved rerun requests are not available yet: no dispatcher is installed and the service answers 503. Optional AI explanation is admin-enabled, consented, budget-capped and off by default; it never sets or overrides a decision, and the deterministic facts are returned with it off. The developer-preview lane is not included in the publicly listed Marketplace V1; see Developers.
What developers get
A failing JUnit run holds the change with evidence_failed and names up to 10 failing tests in report order. The CI gate script exits 0 only for CLEARED on the exact repository, commit, build and environment, and history is preserved for the next change.
Prefer one system? TestWarden also includes native Jira test management and a Migration Center. Read why coding agents should not certify their own changes, see pricing, or start with the documentation.
From the blog
A working definition of independent software verification, the five duties that must be separated, how it applies when AI agents write the code, and a rubric for judging whether a tool is genuinely independent.
For engineering leaders adopting coding agents: an interactive workflow of self-validation versus independent verification, why agent-written tests are useful but not clearance, and an honest account of what independence cannot catch.
Now available on Atlassian Marketplace
TestWarden is listed on the Atlassian Marketplace for Jira Cloud. Keep your existing test-management and CI tools, and add The Warden's independent verification layer—or use TestWarden's built-in Jira test management. Visit the Marketplace to get started; we're here if you want guided setup or migration help.