Missing Evidence Cannot Pass a Release

Evidence is missing when the required check has no usable result for the change you're about to ship. That includes a test that never started, a monitoring query that couldn't reach its service, and a successful result attached to an earlier build. Keep those conditions visible. None tells you whether the current change passed.

In his account of building a release control plane, paddo describes recording an unavailable replay check as not run. His production health watch also reports findings without yet stopping releases. Those are useful distinctions: a missing check and an observation without blocking authority should both be visible to the person deciding what ships.

Gunner Technology's position is that the release mechanism must preserve those distinctions through the final decision. An agent can summarize an absent result. It cannot replace the result. If the summary turns an empty field into reassurance, the approval screen is making a stronger claim than the underlying record supports.

The gate should compare required evidence with actual results before it considers approval. Define the requirements before the builder starts: which checks apply, which artifact they must inspect, and what makes their results current. An artifact is the exact packaged version being released. A passing check on a different package does not clear this one.

Give each check a separate state for passed, failed, not run and unavailable. Record a reason when a check does not apply, and keep that decision separate from passing it. Require the result to identify its artifact, environment and check version. Let the gate reject mismatches without asking a model to decide whether they probably matter.

Our post on checks that miss the changed surface asks whether everything received inspection. This is the next question: did that inspection produce evidence the release can actually use? A complete list of check names is only the beginning. The gate needs their results, and it needs to know what those results describe.

Keep the release blocked when it needs evidence from the unavailable service. Record the outage as a problem with verification, without declaring the product broken or safe. Retry only as often and as long as your recovery policy allows, preserve the last attempt's details, and escalate when the factory cannot restore the check.

Consider a hypothetical permissions change waiting on an access test. The test environment is unreachable. The builder reports that the patch is small and the same pattern worked before. Neither observation answers whether an unauthorized user can reach the protected action in this build. The release still needs that answer, or an explicit decision to accept its absence.

Keep unrelated work moving only where its own requirements allow it. A failure in a shared checker should not silently remove that checker from every release. Hold the releases that depend on the unavailable check, show which work is waiting, and repair the checking service as factory infrastructure. Deleting a requirement to drain the queue changes the standard everyone thought they were buying.

A person with explicit authority over the consequence can approve an exception when policy permits it. The person should see the missing evidence, the reason it is missing, the affected change and the proposed limits. Their approval accepts a named uncertainty. It must not rewrite the check's history as a pass.

Limit an exception to the release and conditions it actually covers. Give it an expiry, a responsible owner and a required follow-up. Keep it out of the builder's credentials, and prevent another agent from granting it on the builder's behalf. The software controlling release should use the recorded decision rather than infer permission from a chat message saying the work is urgent.

Recovery belongs in that decision too. As we explain in Rollback Is a Factory Capability, a way back needs rehearsal and evidence. If recovery itself is untested, say so beside the exception. A rollback plan cannot compensate for missing release proof when nobody has established that the plan works.

Before trusting the gate, deliberately withhold a required result in a safe environment. Try an old result, a result for a different artifact and an unavailable checker. The release should stop for the stated reason. Then restore valid evidence and verify that the intended approval path works. That tests the decision machinery as well as the product.

Start with a release route in a repository you own. People choose the evidence they require and judge whether the finished work is right. Agents can gather the results, repair failed attempts and assemble the approval record. The factory should carry that repetitive work without letting the worker negotiate away the standard.

The useful question at approval time is whether the required evidence exists for this release. Make the answer inspectable. If it doesn't exist, the factory should stop and ask for the decision it cannot make. Silence from a broken checker is an operating problem to fix, never permission to ship.