How Gate reasons.
The part you only need if you disagree.
Everything here sits behind a finding on the Gate page. It is separated because a reader deciding whether to try the product should not have to read the methodology first, and a reader who wants the methodology should not have to extract it from a sales page.
// § 02 · a finding you can argue with
Not an assertion. A world.
Saying a job sits outside your gate is a statement about a graph. Every finding also carries a counterexample: one result per job, in which that job fails and the gate still reports success. It reads in ten seconds and you can disagree with it.
Each world is constructed and then checked, by evaluating your gate's own condition under it. If your gate would go red, nothing is emitted. A tool that can always produce a counterexample is producing decoration.
And a check on the instrument itself.
A clean report is the least informative thing an assurance tool can give you. It looks identical to a tool that is broken, misconfigured or pointed at the wrong file. So the review injects faults into your workflow, one at a time, and reports whether each was caught: remove a job from the gate's needs, absorb its failure step, weaken its comparison, blind it entirely. Then it applies changes that should raise nothing and checks that nothing is raised.
You get a sentence like on this workflow, 6 of 6 injected faults were detected and 3 of 3 harmless changes produced no false gap. It is a measurement on your file, not a claim about the analyser in general.
// § 05 · what the platform actually does
Some of this is not documented.
A skipped job satisfies a required check. A step marked continue-on-error reports success to needs while the jobs API reports failure. A merge queue delivers merge_group, so a gate conditioned on the pull request event does not run there at all. Whether that reads as a pass or blocks the queue depends on how the check is required, which is a repository setting we cannot see from outside, so the report says the gate is absent from the queue rather than asserting the outcome.
And one I had to test for myself: a later check run of the same name supersedes an earlier one in the combined status, so an app holding checks: write can clear a failing check of that name. GitHub can bind a required check to an expected app, which narrows this; where that binding is set, and we usually cannot see whether it is, the route closes. Nine such findings are published as executable checks and rerun against production on request. When one stops holding, it stops being shown.
The reasoning is checkable, which is the point.
None of the above asks you to take our word for it. The semantics register states every claim we make about GitHub Actions, each with the evidence that established it. The proof index lists everything you can run against us without asking.