How the gates work
An unevaluated commit is not a passing one. Here is every gate, and when it fires.
Twenty-five gates, eight pillars, three environment tiers. A gate that does not apply to your repository never fires — and every verdict is bound to a commit and to the hash of the contract that was in force when it ran. All three tiers are drawn below.
the rules, per tier
loading gate matrix…
required of every repository required only when your profile turns it on optional — reported, never holds
every gate
| Gate | Pillar | What it checks | dev | staging | prod |
|---|
A repository's declared compliance tier adds gates on top of whichever environment it is going to:
The contract is hashed
A verdict stores the sha of the
repo-profile.yaml it ran against. Without that, two reports on the same commit look identical even when one was evaluated against an edited contract.
A gate that does not apply, does not fire
A static site with nothing deployed is not blocked on a Kubernetes network policy. Conditional gates carry their own predicate — deploy_target == kubernetes — and are simply absent otherwise.
Deny by default
Every path that is not an explicit allow refuses. A pipeline deploy with no repository bound to it has no evidence that could justify running unattended, so it does not — a person with a session still can.