Your gate reads both build-written reports and verified signed statements — how do you set outcomes per class?

## Start from the classification, not the rule Most gate designs go wrong by asking "what should this rule check?" before asking "what am I entitled to conclude from this input?". The organising question for the whole gate is one line: **could the party I am gating have produced this evidence, and still passed?** That sorts every input into tiers, and the tier — not the severity of the finding — decides the outcome the check is allowed to have. | Class | Producer | Outcome it may carry | | --- | --- | --- | | Self-asserted | The gated job itself: workspace files, step and job outputs, exit codes, exported variables | Warn, annotate, dashboard | | Independently produced | A platform system the gated team cannot write to, e.g. a scan run on the published artifact, findings held in a service with no build write access | May block | | Attributable statement | A signed statement whose issuer the gate establishes and compares against an identity pinned in policy | May block at promotion | ## Why the self-asserted tier must not block Two separate reasons, and interviewers want both. **It doesn't work.** A block resting on a value the gated job chose is bypassable by the party it constrains — not necessarily maliciously; a skipped step, a stale file or a scanner exiting zero on findings produces the same green. **It is worse than nothing when it appears to work.** Once a check is labelled "blocking", the organisation stops looking. Risk registers list it, dashboards count it, and an auditor is told the control runs on every build. A control everyone believes in and nobody can rely on is a strictly worse position than an acknowledged gap, because the gap is no longer visible to anyone deciding where to spend effort. So the self-asserted tier keeps its value in the place where being wrong is cheap: fast feedback in the merge request, a signal on a dashboard, an early warning that a team's build is drifting. None of those need to be right every time. ## Placement matters as much as class A check that runs inside the pipeline definition the developer can edit is weaker than the same check at the boundary the artifact must cross to reach production. Two implications: - Put the blocking classes at the **promotion or deploy boundary**, evaluated by a system that is not the build. That boundary sees the artifact as published and can demand evidence about *that* artifact rather than about whatever was in a workspace. - Keep the in-pipeline copy anyway, in warn mode. It gives the developer the answer minutes after they push instead of hours later at promotion, and a team that learns the outcome early rarely reaches the boundary with a surprise. This is also why "we already run the scanner in CI" is not an answer to "what blocks promotion?". Those are different controls at different tiers. ## The absence case For a blocking class, missing evidence has to be a failure, not a pass — otherwise deleting the evidence is the bypass, and the whole classification collapses. For the warn tier, missing evidence is simply a note; nothing rested on it. Say which behaviour you chose and why, because a gate that silently passes when its input is absent is the most common way a tiering scheme is defeated in practice. ## Telling the truth downstream The classification is also a reporting contract. When someone asks which controls ran on a release, only the blocking classes count. A warn-only check over self-asserted input should never appear in that list, no matter how green its history looks, because a check that cannot fail and whose input is authored by the constrained party is not evidence that anything happened. Keeping this line clean is unglamorous and it is the difference between a gate programme and paper compliance. The converse discipline: when a check is promoted from warn to block, that is a real change in what the organisation can claim, and it should be recorded as such rather than slipped in. ## How to talk about it in an interview The strong answer is structural rather than tool-shaped. Name the classification question, put each input in a tier, attach outcomes to tiers rather than to severities, explain that placement at the promotion boundary is what makes the blocking tier enforceable, and close on the honesty point — that only the blocking tiers may be reported as controls. A weak answer argues about which findings deserve a block while never asking where the finding came from.