A blocking L4 gate (coverage / secret / CVE / lint / build / test failure) may be bypassed only when the override-check job confirms all 3 conditions:

The policy enables override (override.enabled: true).
The person who triggered the run is in override.authorized_users — a list of GitHub usernames in the project's vfa-policy.yml (case-insensitive, @ optional). The trigger is github.triggering_actor (push, PR update, or Re-run). The core default is an empty list → nobody can override until the project lists people.
Reason ≥ 10 chars, taken from the PR body.

authorized_users is read from vfa-policy.yml on the PR's base branch, not from the PR — a PR cannot add its own author. Adding / removing people needs a separate reviewed PR, like any policy change.

When eligible: every gate still runs in warn-only mode, and the security-gates status check (the final verdict job) is always green — even when the checks job fails on a step no gate covers (setup, scanner install, …). If a gate was actually bypassed: the checks job writes one line to override-audit.log (ts / actor / reason / repo / pr / layer / bypassed gates), uploaded as the override-audit artifact, and telemetry records status=warn. A failure outside the gates is audited by the security-gates job as "bypassed": ["checks:failure"]. Clean runs write no audit entry. Step-by-step: 40-procedures/l4-override.md.
> ⚠️ Remaining gaps (pending COE / Dev Director): an authorized user who pushes or re-runs overrides right away — there is no separate per-PR confirmation (label…); the "reason" is the whole PR body (an existing PR template already passes 10 chars); the audit log is only a run artifact (expires with retention), with no central store; layer is still read from the PR's vfa-policy.yml — consumer repos need CODEOWNERS on that file, or a PR can lower its own layer to L3.

Current list (30-registry/gate-policy.yml):

enabled: true
authorized_users: []
require_reason: true