What Does a Green Check Actually Prove?

A rushed change passes local checks, merges, and produces an image that fails its health check after release. The team restores service. Then someone asks a simple question: did production receive the image the pipeline tested? Nobody can answer.

That scenario opens Chapter 4, and it captures a common gap. The pipeline had checks. What it lacked was checks whose meaning anyone could state.

A Gate Is a Decision, Not a Color

Run python3 -m unittest discover on your laptop and you've proved something about one local moment. Make the same command a required pull request check and it can enforce a decision for one commit.

The difference is binding. A pipeline ties a command to an event, a revision, a permission set, an identity, and a recorded result. Exit status is what turns policy into enforcement.

That has an uncomfortable consequence. A scanner that reports a finding but exits successfully is informative, not blocking. So read the command's failure semantics, not only the green badge.

Three Layers Must Line Up

Chapter 9 makes the same point about security checks. A consequential check has three layers:

• the scanner produces evidence and a meaningful exit status;
• the workflow exposes that status as a named check for one revision;
• repository policy requires that exact name where merging is controlled.

Break any layer and the gate changes character. A hidden scanner failure is advisory. An optional green job is bypassable. A required name that's no longer emitted stops every merge.

Names deserve more suspicion than they usually get. A renamed job can detach from protection, and an unexpected source can reuse a trusted label. That's why the book's delivery workflow expects exactly one completed, successful check from the expected application for each protected name on the dispatched commit. That's stricter than asking whether any check with that name looks green.

Ask What the Gate Claims

"The scan passed" is too vague to defend. Useful evidence names the source commit, the rule or advisory, the scanner configuration, and the artifact identity. For an image, prefer its immutable digest over a movable tag such as latest.

Chapter 4 turns this into a Gate-to-Claim Review, six questions you can apply to any workflow:

1. What starts the gate?
2. What identity is judged?
3. What evidence is produced?
4. What authority is granted?
5. Who may override it?
6. How is failure recovered?

Each question has a refusal condition. For example, a mutable name standing in for identity, or a log message treated as enforcement. If you can't fill one row, the workflow has an unanswered control question. Apply the review to a human-written diff and to an AI assistant's critique of that diff alike.

A Green Build Can Still Be Refused

Green evidence is real evidence, for the claim it covers. Suppose a pull request's quality, image, and security checks are all green. That supports merging the tested commit. It does not permit delivery from a lab branch, create an independent production approver, or prove an arbitrary rollback digest was ever accepted.

Each of those later decisions has its own boundary, and each should refuse on its own. The green build stays useful. It just doesn't answer questions it was never asked.

Make the Gate Say No

The most practical habit in both chapters is deliberate failure. A gate you've never seen fail is a gate you're trusting on faith.

In Chapter 4 the safest instructive failure is a bad health path. On a fresh, unmerged branch, you replace /health with /health-does-not-exist in the CI workflow's image job and open a pull request. The quality job should still pass, because the source hasn't changed. The image job should fail, and the pull request must stay unmergeable. Then you restore the workflow with a forward revert commit, not a rewritten history, because the failed run is evidence that the gate can say no.

Chapter 9 does the same for secret detection, using the companion's invented fixture on a disposable branch. The Secrets check should fail and name the fixture file without printing credential material. Even the cleanup carries a stated limit: the passing rerun proves the fixture is absent from that branch's reachable history, not from logs, caches, forks, or another ref.

Write Down What It Doesn't Prove

Both chapters end with the same discipline. Chapter 9's platform log entry records that five named checks are enforced, then says they do not establish that the application or supply chain has no vulnerabilities beyond one enforced revision.

That's the real answer to the title question. A green check proves what its command tested, for the identity it judged, under the policy that required it. Everything else is still open, and saying so is part of the job.

Go Deeper

Chapter 4 builds CI, delivery, and rollback workflows that block a failing merge and promote one verified image digest through independent approval. Chapter 9 audits and enforces five security checks under a written disposition policy. The workflows and safe failure fixtures are in the companion repository at https://github.com/netbiz-ai/ai-native-devops-companion.