Think of a bank vault with four keyholders. No single person can open it, not even the manager, and the door does not care how senior you are or how sure you sound. It counts keys. If three turn and one does not, the door stays shut and everybody goes home.
That is how we now review code before it goes anywhere near a live system. Not a tired colleague saying "looks fine" at five o'clock. A machine that asks four separate reviewers, from four different suppliers, to read the change independently, then refuses to let anyone push the code until enough of them have signed it.
Why a meeting was not enough
Most of the code we ship now is written by software agents. They are fast, they are tireless, and they are very confident. A confident author is exactly the wrong person to ask whether their own work is safe. So the first rule of the gate is that the author never sits on the panel. A reviewer who wrote the change, or who shares a login with the one who did, is not a reviewer. The machine checks that too.
The second rule is that one reviewer is never enough, however good. In one round this month a fresh adjudicator re-read the evidence from scratch and found three defects that all four reviewers had walked past. Different reviewers miss different things. The value is in the disagreement.
The third rule is the strange one. The gate is physical. If a change has no signed record from the panel, the push command fails. Not "warns". Fails. A warning becomes wallpaper within a week.
A gate you can talk your way past is a suggestion. A gate that counts keys is a gate.
What happened when we were polite to it
Twice in July we tried to help the gate along. Once, somebody passed a setting on the command line that a runbook said was correct. The runbook was two days stale, the live setting had changed on a ruling that morning, and the override quietly dropped one reviewer from the panel. The result was a failed round and an afternoon lost. The lesson we wrote down: the machine's live settings are the truth, and a document is only a claim about the truth on the day it was written.
The other time, the reviewers came back split. The temptation was to average the opinions. We did not. One adjudicator with no stake in the code read both sides, checked the evidence, and ruled. Averaging reviewers is a meeting again, with more people in it.
What it costs, honestly
A panel round takes real time and real money, and a busy day queues several. We accept that. The alternative is a person reading every change from a fleet that never sleeps, and that person will be us, at midnight, saying "looks fine". We stay until it works. Part of that is refusing to trust ourselves at five o'clock.
For the technical reader
The panel runs four review lanes on every diff, each a different model from a different vendor, with a quorum floor before any verdict counts. The lanes run with their tools locked down, because a reviewer that can read your filesystem or run a shell while reading an untrusted diff is an actuator, not a reviewer. We proved that the hard way: one lane's lockdown flag turned out to be a silent no-op, and the injection test had only passed because the model declined the bait. Model virtue is not a security control, so the self-test now includes a positive control that must trip, or the run reports inconclusive rather than green.
A passing round mints a signed manifest bound to the exact diff. A pre-push hook, both in the repo and globally on the machine, refuses any push without one. Adjudication is done by a fresh seat that was not an author or a reviewer, and its record is checked on disk before anything merges. Posture flags come from the host's own config, never from the command line. Every one of those rules exists because we broke it once.