What is a verification control plane?

A verification control plane is the layer above your test runners, CI systems, scanners, test-management tools and AI agents that decides, for one exact software change, whether the combined evidence is sufficient. Those tools stay where they are and keep doing what they do. They become evidence producers. The control plane is the decision authority: it holds the rules, checks that each piece of evidence really belongs to the change, and returns a recorded verdict that a pipeline can gate on.

If that sounds like an unusually strong claim to make about a category of product, consider the problem it answers. A modern pipeline emits many signals: unit tests, end-to-end suites, static analysis, dependency scans, an AI reviewer, a manual QA sign-off, perhaps results in Xray or AIO Tests. Each has its own status. The merge rule is usually a list of required checks, and a list of checks is not a decision. It cannot say that the scan was for the wrong commit, that the test run covered a subset, or that the green status came from the party with the strongest incentive to be green.

The diagram above is the whole idea. Left to right: actors (agents and humans) make a change; evidence producers (GitHub CI, security tools, Xray, AIO Tests) report on it; each submission is stored as an attributable receipt; a versioned contract and policy state what must be proven; an independent Warden evaluates and returns HELD, CLEARED or NEEDS APPROVAL; and Quality Memory keeps the record. The dark layers hold decision authority. Everything to their left can only submit. The scenario beneath the diagram uses a simplified policy over invented inputs so you can see what happens when, for example, every tool passes except the one that was required.

Where the term comes from

The term is borrowed from infrastructure. In networking and in orchestration systems such as Kubernetes, the data plane does the work, while the control plane holds desired state and makes decisions about it (Kubernetes components is a good tour of the idea). The analogy transfers cleanly to software delivery. The data plane is everything that produces observations: tests run, scanners scan, reviewers review. The control plane holds the rules and the verdict. Separating them has the same benefit it has in infrastructure: you can change, add or replace a producer without touching the policy, and you can change the policy without rewriting every pipeline.

The analogy also warns you what not to build. A control plane that executes work becomes a second CI system and inherits all of CI’s maintenance burden. One that merely aggregates statuses is a dashboard. The value is in the narrow, hard part in the middle: intake, identity, obligations, decision, enforcement and record.

Six duties of a verification control plane

Each duty exists because of a specific failure. Without intake in neutral formats you end up writing an adapter per tool and the policy bends to whichever tool is easiest to read. Without identity, evidence can be replayed or attributed to the wrong build. Without stated obligations, “enough” is decided after the result is known, which is an opinion with extra steps. Without a deterministic decision, two people can read the same evidence and disagree. Without enforcement, the verdict is advice. Without a record, you cannot learn from your own history, and an auditor has nothing to examine.

Producers and authority: the line that matters

The single most important property of a control plane is that producers cannot decide. This is not a stylistic preference. It is the old separation of duties principle applied to software evidence, and it is the same reason a developer does not approve their own production change. In TestWarden the line is enforced in several concrete ways.

• Only CI holds submission tokens. Every submission names a provider type (ci, agent, scanner, code_reviewer or visual_agent), a name, a source system and a run ID. The provider type is asserted by the caller, so the real boundary is who holds the token. Coding agents hold none, and agent evidence reaches The Warden only through a pipeline.
• Kinds of evidence satisfy different obligations. A scanner pass is recorded, and it cannot satisfy the test-run obligation. Agent evidence cannot satisfy the requirement for a CI run.
• An external green is evidence, never CLEARED. Another tool’s status, approval or score is stored as an observation. Only deterministic policy produces CLEARED.
• No caller supplies a state. The API rejects submissions that include a state or progressionAllowed field. No endpoint, CLI command, MCP tool, CI step or AI feature grants approval.

Why this matters more in the era of AI-generated code

Every previous generation of tooling assumed that code arrives at a rate people can review. Coding agents break that assumption. Atlassian’s own AI SDLC playbook describes coding becoming less synchronous and single-threaded, with planning, review, maintenance, context and measurement growing in importance. When agents open many changes a day, the cost of producing a change falls and the cost of knowing whether it is safe does not. Faster code production raises, rather than lowers, the demand for fast, well-grounded verification decisions.

There is an empirical reason for caution, too. The DORA research programme reported in its 2024 findings that higher AI adoption was associated with worse software delivery throughput and stability, alongside perceived productivity gains. Read the report for the effect sizes and caveats, since the relationship is correlational and the practices that accompany adoption matter. The practical reading is that producing code more quickly is not the same as shipping safely more quickly, and that the gap is a verification problem.

A control plane addresses the gap in three ways. It does not slow agents down, because producers keep producing. It does not rely on reading every diff, because the rule is mechanical. And it keeps the people who must make exception calls looking at exactly the changes the policy could not clear, with the reasons attached. For a deeper treatment of the agent case, read why coding agents should not certify their own changes and how to verify AI-generated code before merge.

Alignment with software supply-chain practice

The control-plane idea sits comfortably beside broader supply-chain work. NIST’s Secure Software Development Framework (SP 800-218) asks organisations to verify that software meets security requirements and to retain evidence, and frameworks such as SLSA and in-toto focus on attestations about how artifacts were built. These are complementary. Provenance tells you how an artifact was produced; a verification control plane answers whether the evidence about a particular change is sufficient under your policy. TestWarden does not claim any certification or compliance with these frameworks. It records attributable evidence and decisions that you can use as input to such efforts.

What a control plane is not

• Not a CI system. It does not run your builds. CI keeps the tokens and submits evidence.
• Not a test runner or scanner. Playwright, Cypress, Semgrep, SonarQube and similar tools are compatible when they emit JUnit XML or SARIF. There are no first-party adapters for named tools. As of the October 2026 engineering acceptance, read-only collectors for AIO Tests, Xray, Zephyr Scale, TestRail and Azure DevOps exist in source and pass offline contract tests, but live vendor certification is pending and none is live. See Integrations.
• Not a policy-as-code engine yet. Only the default contract is in use today. Customer-authored contracts are not available.
• Not a dashboard of badges. A green or a score from another tool is evidence. It is never the same thing as CLEARED.
• Not an oracle. A control plane can tell you that the evidence is complete, attributable and fresh. It cannot tell you that your tests are good. That residual risk is why the verdict is always shown with its reasons.

A first-hand example of a decision

Concretely: CI builds commit a1b2c3d of acme/billing as build 1042 for staging. Early in the job it announces a run, so the state is VERIFYING. The test job finishes and CI submits a JUnit report in which two tests failed. A scanner submits a clean SARIF report. The Warden’s decision is HELD, reason evidence_failed, next action resolve_failing_evidence, naming the failing tests, up to ten in report order. The scanner’s clean report remains on file as evidence. It simply does not outweigh a failing test run. warden-gate exits non-zero.

The developer pushes a fix as commit e4f5a6b, CI builds 1043, submits a complete passing report, and the Warden returns a new decision, CLEARED, for the new build. The earlier HELD decision is untouched. Running the gate against 1042 still fails. That sequence is walked through step by step in a green check is not proof, and the rules that make it work are described in verification contracts and exact-build evidence.

Following one submission through the layers

It is easier to trust an architecture when you can trace a single piece of evidence through it. Take the JUnit report from the example above. CI produces it, which is the first layer: an evidence producer doing its own job. CI then submits it to the Warden’s intake with the repository, commit, build and environment, authenticated with a token that CI holds and the author does not. Intake validates the shape and size of the submission and stores it as a receipt, recording who produced it, from which source system and run, and what observations it contained.

The second layer, the contract and policy, tells the Warden what the receipt would have to show: a complete, current-build automated test run, fresh enough, with nothing failed, errored or skipped. The Warden’s evaluation compares the set of receipts for that exact target with those obligations. The output is a decision with a state, reason codes and a next action, and it is appended to the history. The pipeline’s gate reads that decision. At no point did the producer choose its own verdict, and at no point did the policy depend on which producer happened to be easiest to parse. That is the practical meaning of “the control plane is independent”.

Where intelligence fits, and where it does not

TestWarden’s broader architecture includes advisory intelligence: change and CI intelligence, impacted-test selection, test-gap, failure and release-risk intelligence, maintenance suggestions and a governed Quality Agent. They read the same tenant-scoped history as the decision layer and cite their sources. They live beside the control plane, not inside it. A recommendation that a test is worth running does not change a state, and a model’s summary of a failure is never an input to clearance. The authority stays deterministic, and the intelligence stays accountable to facts it can cite. Those capabilities are implemented in source and under acceptance, not claimed as customer-live, and they are covered in Quality Memory and the AI data handling documentation.

How control planes fail, and what to demand

A control plane is a single point of judgment, so its failure modes deserve as much scrutiny as the failures it prevents. Four are worth naming, along with what you should expect a serious implementation to do about each.

• Becoming the bottleneck. If every change waits on a slow decision, teams route around it. The answer is a decision that is cheap to compute, deterministic and available as soon as evidence arrives, plus clear states such as VERIFYING so waiting is visible rather than mysterious.
• Policy drift. Rules that change silently erode trust. Each decision should record the contract version it was made under, so history stays interpretable when contracts change.
• False confidence. A tidy CLEARED can be read as “bug free”. It means the required evidence was present, attributable and passing under the contract. Insist that the product states what its verdict does not cover.
• Credential sprawl. If many parties hold submission tokens, the producer-versus-authority line blurs. Keep submission authority narrow, rotate it and make revocation retain the history.

There is a fifth, subtler failure: treating the control plane as the place where quality happens. Quality happens in design, review, test design and operations. The control plane makes sure the evidence about that work is honest and sufficient. It cannot compensate for tests that assert nothing, and an organisation that buys one expecting it to do so will be disappointed. Used for its actual job, it is the part of the system that stops you from lying to yourself about what you have shown.

An adoption path that keeps your tools

Request limits to plan around: 256 KiB per request, 1 to 20 observations per submission, a gzip-base64 JUnit wrapper up to 2 MiB raw, and 8 KiB of metadata. Retries should cover transient errors only. See CI evidence for the contract in full and the developer overview for the formats and client options.

Access follows Jira roles. Reads need a current Jira role (tester or higher) and a repository grant. Write authority for evidence is installation-wide for a site admin who holds the write scope. History is kept per installation. There is no cross-customer pooling.

How to evaluate any control plane, including this one

On the last point, here is where TestWarden stands. The default contract, five decision states, JUnit and SARIF intake, the gate script and append-only history are the demonstrated core. Customer-authored contracts, live vendor certification of the five test-management collectors and the broader AI intelligence capabilities are in source or ahead of us, and are described that way on Proof and in the product documentation. AI features, where enabled, are advisory: they can explain a result, and they never set or override a decision.

Frequently asked questions

To see it in practice, read how The Warden evaluates evidence, look at Proof for what has actually been demonstrated, compare the architecture with test management in test management versus release governance, or see the release governance comparison. When you are ready to try one repository, talk to us or see pricing and the evaluation terms.