QE has become very good at measuring activity. Release Confidence asks a harder question: does the available evidence justify putting this change in front of customers?

QE measures almost everything except the thing leadership actually needs

Quality organizations track automation coverage, pass percentage, defect counts, escaped defects, test execution progress, performance thresholds, code coverage and release velocity. These metrics are useful because they describe parts of the assurance system.

But when an executive asks, “Are we ready to release?”, none of those metrics answers the question.

The real question is one of confidence.

A green dashboard is not the same thing as a defensible release decision.

Why pass percentage is a weak proxy

Imagine two releases. Both report 96% test pass rates.

In the first release, the failures are low-impact visual scenarios with strong alternative coverage. The changed components have good historical stability, production telemetry is normal and the highest-value journeys have been exercised thoroughly.

In the second release, the failures touch a critical integration, the changed service has caused incidents before, regression coverage around the dependency is thin and a recent infrastructure change introduced uncertainty.

The same 96% means something completely different.

That is why a release metric without context can create false comfort.

Release Confidence is not another vanity score

I do not think Release Confidence should become a new percentage that teams chase. If it becomes “87% confidence” with no explanation, we have simply created another dashboard number.

A useful confidence position needs at least four properties:

Evidence-backed

The position must be grounded in observable signals rather than subjective optimism.

Risk-aware

Not all failures, changes or gaps deserve equal weight. Business consequence matters.

Explainable

A human should be able to ask why the confidence position changed and receive a traceable answer.

Actionable

The model should identify what evidence would materially improve the decision.

A confidence position should answer “why”

Consider a release assessment that says:

Confidence position: Moderate.

Why?

  • Critical customer journeys have strong functional regression evidence.
  • One high-change service has lower-than-normal targeted coverage.
  • A historically unstable dependency has shown elevated latency.
  • No unresolved critical defects remain.
  • AI evaluation coverage for a changed recommendation path is incomplete.

Now the release conversation changes. The team can debate the evidence rather than someone's intuition.

Confidence should be dynamic, not ceremonial

Today, release readiness is often assessed late: a meeting, a checklist, a sign-off. Quality Intelligence creates the possibility of a continuously updated confidence position.

A new code change can lower confidence. A targeted regression can restore it. A production-like performance run can change the risk picture. A newly discovered incident pattern can alter the weighting. A completed AI evaluation can close an evidence gap.

The release decision becomes the result of a living evidence model rather than a static gate.

What should influence Release Confidence?

The exact model will vary by system, but I would start with six evidence families.

1. Change risk

What changed, how much changed, and how connected is the affected area?

2. Test evidence

What was validated, with what depth, and how relevant is the validation to the change?

3. Defect and incident history

Where has the system failed before, and do the current changes intersect those patterns?

4. Runtime evidence

What are telemetry, performance and resilience signals saying under realistic conditions?

5. Business criticality

Which journeys or capabilities carry disproportionate customer, financial or regulatory consequence?

6. AI evaluation evidence

Where intelligent components are involved, do we have evidence across correctness, robustness, safety, relevance and drift?

Confidence must include evidence gaps

One of the most important outputs of a confidence model is not what it knows. It is what it does not know.

Traditional reporting tends to reward completion. A confidence system should explicitly represent uncertainty.

If a high-risk dependency has not been exercised, say so. If performance evidence is stale, say so. If a model evaluation does not cover a new scenario class, say so.

Unknown risk should not silently be treated as safety.

The most useful question is: what would change the decision?

This is where Release Confidence becomes operational.

If the position is Moderate, what is the smallest additional piece of evidence that could move it to Strong? A targeted integration test? A production-like load run? A model robustness evaluation? A review of one dependency?

Quality Intelligence should help teams spend assurance effort where it has the highest information value.

From quality reporting to decision engineering

Release Confidence reframes the purpose of QE. The objective is no longer to maximize testing activity. It is to improve the quality of the release decision.

That makes quality evidence useful beyond the testing organization. Engineering leaders can see where uncertainty remains. Product leaders can understand business exposure. Risk owners can see what evidence supports the recommendation.

And quality teams can finally answer the question they have always been asked:

Do we have enough evidence to release?

The metric QE forgot may not be a metric at all

Release Confidence should ultimately be treated as a position, not merely a number: a structured conclusion backed by traceable evidence, known uncertainty and an explanation of what matters next.

That is more difficult than calculating a pass percentage.

It is also far more valuable.