The Warden
Bring every verifier. The Warden decides if the proof is enough.
Your test-management systems, CI, scanners and authorized agents keep doing their jobs. The Warden evaluates their evidence independently of whoever produced it, against a verification contract, and records one decision for the exact build, with a reason a developer can act on and a history that is never rewritten.
Evidence for any other build does not count toward this decision.
- Run 8841 announced. No evidence yet for build 4821.
The Warden is still verifying.
- Complete automated test run for this build
- Evidence is current (under 24 hours)
Run 8841 announced. No evidence yet for build 4821.
- No decision recorded yet.
Build. A change arrives as an exact commit and build: 9f3c2a1, build 4821. CI announces run 8841. An announcement is never evidence.
Read this scene as text
- Build. A change arrives as an exact commit and build: 9f3c2a1, build 4821. CI announces run 8841. An announcement is never evidence.
- Evidence. The test run reports in. It becomes a receipt attributed to its producer (ci, github-actions, run 8841) and tied to this exact build.
- Contract. The Warden evaluates the receipts against Contract v1: a complete, current test run for this build. A passing scanner report is recorded, but it cannot satisfy that requirement.
- Held. One required test failed, so the decision is HELD with a readable reason and the next action. Policy decides; no tool score can override it.
- Fresh proof. A fix lands as commit c41e8d7, build 4822. Only fresh evidence for that exact build counts, and the HELD decision stays on record.
- Cleared. The new run passes under the same policy, so build 4822 is CLEARED. Decision 1 is preserved beside decision 2, never rewritten.
What The Warden does
An independent authority above your tools.
A green result from Xray, AIO Tests, CI or an AI agent is evidence. It is not independent release authorization.
- Evaluates evidence independently from its producers.
- Binds verification to an exact repository, commit, build, run and environment.
- Records immutable evidence receipts.
- Produces deterministic verification decisions.
- Preserves the original HELD decision after a corrected build becomes CLEARED.
- Prevents coding agents from granting their own clearance.
- Gives actionable reasons for missing, failed, conflicting and stale evidence.
- Supplies traceable quality decisions to Jira and supported developer workflows.
The workflow
From many producers to one decision.
The intended integrated flow. Every delivery channel is labelled with its own verified availability.
- Evidence producers
- Existing test-management systems
- CI
- Scanners
- Authorized agents
- Evidence ingestion and provenance validation
Each result is tied to an exact repository, commit, build, run and environment, and stored as an immutable receipt.
- Verification Contract and deterministic Warden policy
The contract says what must be proven. A pinned policy interprets the evidence. No model decides.
- The Warden records one decisionHELDNEEDS APPROVALCLEARED
- Where the decision is delivered
- Jira quality record
Changes workspace with decision, reasons and history.
Marketplace V1 — publicly listed - GitHub Check and job summary
Actionable HELD feedback on the pull request.
Developer preview — live acceptance pending - Audit evidence
Immutable receipts and append-only decisions.
Proven in development - Authorized workflow feedback
Developer API, CLI and MCP reads for people and agents.
Developer preview — live acceptance pending
How it decides
Evidence in. Policy applied. Decision recorded.
No model, no opaque score. Observations are normalised into attributable receipts, the Verification Contract defines what must be proven, and the pinned Verification Policy deterministically interprets the evidence.
- 01
Watch the change
A Change Set is identified by repository and commit — never by title matching. Delivery context (PR, build, environment) accumulates against it.
- 02
Understand required proof
The applicable Verification Contract states the required evidence class, freshness and whether a human must approve.
- 03
Collect evidence
CI, test runners, scanners, code reviewers and agents submit receipts tied to the exact repository, commit, build and environment they verify.
- 04
Apply deterministic policy
The pinned policy version evaluates the evidence snapshot. Exact retries return the identical decision.
- 05
Explain the decision
Fixed reason codes and next actions. The decision, contract, policy and engine version are all recorded and replayable.
Bring every verifier
Keep the tools you have. Add the authority they lack.
A control plane does not replace your verifiers. It is the single place that knows what a change must prove and whether the proof that arrived is enough.
What can send evidence today
Any CI job that can emit a complete JUnit XML report (Playwright and Cypress both have JUnit reporters), a SARIF 2.1.0 report from a scanner such as Semgrep, or a bounded JSON envelope of 1 to 20 observations. Delivery is over the Forge App REST API with OAuth 2.0 (3LO) and app-defined scopes.
What the default contract requires
A complete, current-build automated CI test run, no older than 24 hours, with no failed, error or skipped observations. Scanner and reviewer passes are recorded as evidence but cannot satisfy that requirement on their own, and agent observations cannot stand in for the CI run.
Connector status
Read-only connectors for AIO Tests, Xray, Zephyr Scale, TestRail and Azure DevOps exist in source and are under acceptance. None is live, and until independent attribution is in place a provider’s result is recorded as asserted by CI. Recorded manual executions are not yet inputs to Warden decisions, and customer-authored contracts are not yet available.
The status of each provider is on Integrations. Read-only integrations for AIO Tests, Xray, Zephyr Scale, TestRail and Azure DevOps are being completed and verified for TestWarden’s independent governance workflow. Early-access integration testing is available by arrangement, subject to readiness. Want one system instead? TestWarden also includes native Jira test management and a Migration Center. Submission details are in the documentation.
States
Five states. Never colour alone.
Warden states are a deterministic projection of persisted Quality Decisions. Missing or invalid decisions cannot clear.
- CLEARED
Required proof is satisfied under policy.
No action required.
A CI run was announced for this exact build and its evidence is still arriving within the allowed window.
No action required. An announcement is never evidence.
- HELD
A deterministic blocking condition exists: failed, stale, missing, conflicting or overdue evidence, or an open blocking defect.
Resolve the failing evidence or submit evidence for the current build.
- NEEDS APPROVAL
The applicable contract requires human approval or judgment. Agents cannot bypass it.
A human decision is required. The default contract requires none, and customers cannot yet author contracts that do.
- INCOMPLETE
TestWarden cannot honestly evaluate the change yet — context, contract, policy or source configuration is missing.
Missing configuration never becomes CLEARED.
Reason codes
- evidence_satisfied
- Required proof for the exact current build is present and passing.
- evidence_failed
- A required observation failed or errored.
- only_stale_evidence
- The only evidence available is older than the contract allows (24 hours in the default contract).
- no_matching_evidence
- No evidence for the exact current build satisfies the contract. Evidence for an earlier build does not count.
- conflicting_evidence
- Evidence for the same build disagrees. Conflicts are never resolved by overwriting; the change is held.
- open_blocking_defect
- A blocking defect is recorded as open for the change.
- missing_required_approval
- The contract requires a human approval that has not been recorded for this exact build.
- verification_run_in_progress
- A CI run was announced for this exact build and its window is still open.
- verification_run_overdue
- An announced run did not deliver evidence inside its window.
- no_conclusive_evidence
- The evidence present does not allow a conclusive decision.
- no_active_contract
- No active Verification Contract or pinned policy could be resolved; the change is INCOMPLETE, never CLEARED.
- authoritative_defect_context_unavailable
- Defect status could not be established, so the decision fails closed.
- evidence_set_truncated
- The evidence set exceeded safe bounds; the decision fails closed.
Authority boundaries
- A provider's own pass, approval, score or quality-gate result is evidence. It is never, by itself, authorization.
- No endpoint edits policy, grants approval or accepts a caller-selected Warden state. Payloads that try are rejected.
- Only the CI integration can announce a verification run; agents are never given CI credentials. Agents can submit evidence but cannot announce, approve or clear.
- History is never rewritten. Fresh evidence produces a new decision that supersedes — and preserves — the previous one.
The permanent chain
Every decision is explainable end to end.
Intent, Change Set, Verification Contract, Verification Receipts, Quality Decision, Observed Outcome and Quality Memory form one machine-readable chain.
- 01
Intent / Spec
The reason for the change and the definition of done — a Jira issue or spec reference.
- 02
Change Set
The canonical object for an implementation delta: repository, commit, build, environment.
- 03
Verification Contract
What must be proven for this class of change. Versioned. Never edited in place.
- 04
Verification Receipts
Immutable, attributable claims from CI, test runners, scanners, code reviewers and agents.
- 05
Quality Decision
The Warden applies the pinned policy and records an explainable, append-only decision.
- 06
Observed Outcome
The reserved stage for what happened afterwards, recorded against the same chain. Direction: outcome recording is not part of the launch version.
- 07
Quality Memory
The accumulated, tenant-isolated history every future change can be judged against.
Agents
Your agents can build the software. They should not certify themselves.
The agent may fix the software. The Warden decides whether the fix is sufficiently proven.
- Coding agentwrites the changeprovider.type: agent
- Changerepo · commit · buildchange_set
- TestsCI runs the suitejunit · sarif
- Evidenceimmutable receiptsverification_receipt
Agents can submit evidence. They cannot announce runs, select a state, grant approval or clear a change.
- reason
- evidence_failed
- next
- resolve_failing_evidence
- policy
- v4 · deterministic · replayable
- agent authority
- evidence only · cannot clear
The agent may fix the software. The Warden decides whether the fix is sufficiently proven — and the original HELD decision stays in history.
Agents submit evidence like any other producer, through the same API and under the same policy. A repaired change needs fresh independent evidence before The Warden can grant clearance. In the developer pilot, an agent can also read obligations and decisions over MCP, and optional AI can explain a decision with citations. None of it can clear, hold or approve a change. See the developer workflow. How this differs from Harness, SonarQube and JFrog AppTrust: independent release governance compared.
Quality Memory and governed AI
History today. Intelligence in development.
Quality Memory is the immutable record The Warden already keeps. Verification Intelligence and a Quality Agent are the approved direction, and none of them decides.
Quality Memory
A tenant-isolated history of tests, software changes, verification receipts, failures, decisions and observed outcomes, with provenance that authorized quality analysis can cite.
- Proven in development
Immutable receipts and append-only decisions, per Jira site
Expanded historical ingestion, retrieval and intelligence over that history
Nothing is pooled across customers, and nothing is trained on your data.
- Proven in development
Verification Intelligence
Advisory analyses grounded in your own evidence: coverage gaps, changed-code test impact, flaky-test and failure patterns, release risk and evidence-grounded recommendations.
Advisory analyses implemented in source. None is released, and none has a real model result accepted.
Advice only. It informs people and policy, and it can never clear, hold or approve a change.
Quality Agent
Designed to investigate quality problems, recommend test maintenance or repairs and take part in workflows that an administrator has explicitly authorized.
Proposal and approval workflow in source. The runtime is deliberately blocked until authorized write and verification adapters exist.
The agent never certifies its own work. A repaired change needs fresh independent evidence before The Warden can grant clearance.
How AI is governed
- Administrator opt-in with recorded consent, and per-capability switches.
- AI features read only evidence the signed-in user is already authorized to see.
- Tenant isolation: each Jira site’s history stays in that site’s own scope.
- Spending budgets and caps. Non-administrators do not see budget detail.
- Source provenance: output must cite real references, or no AI text is shown.
- Deterministic decision authority: policy owns CLEARED, HELD and NEEDS APPROVAL.
What is available to try
Optional AI explanation of a Warden decision, with citations: Developer preview — live acceptance pending. The Marketplace V1 version submitted for approval ships no AI and declares no external egress. The capabilities above are the approved development direction, not features you can switch on today. Details in AI and data handling.
Built for accountable teams
Defensible decisions, with the trail to prove them.
- Tenant-isolated and Forge-hosted. Data stays on Atlassian-hosted infrastructure in your Jira site's own scope. See Security for scopes and architecture.
- Append-only decisions. Receipts are immutable. A later CLEARED never erases an earlier HELD, and each decision records its contract, policy and engine version.
- Quality Memory. That history is your team's own record of changes, evidence and decisions, isolated to your Jira site. Optional AI explanation can cite it; nothing is pooled across customers, and no model takes part in a Warden decision.
Now available on Atlassian Marketplace
Proof before progress.
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.