Every change at Data & Business Solutions passes two gates before it ships, and both of them test the person signing for it, not the code. The code has its own tests and its own review. The gates ask whether the person approving the plan, and later the diff, can say what it does, why it is built that way and what breaks it, whether a person or an AI agent wrote it. This is how that gate was built, who runs it, and what is still open.
Principal Consultant
The consultant set the rule in June 2026: no passive acceptance. A plan is not approved, and a diff is not released, until the person signing for it can stand behind it. The working name was vet. It became own before the gate shipped, because the point is ownership, not a score for following along. The verdicts kept their old words: vetted, gaps, not cleared.
The consultant also decided that the gate tests the signer and nothing else. The challenge step that already existed pressure-tests the work. The gate asks whether the signer understands the work. Those are two different checks, and the second one is the one that was missing.
The record includes the misses. On October 11 the consultant took the drill on the deferral rule itself, left the gates out of the description of the loop, and had the bar for a deferral wrong. The verdict was gaps. The text was right and the answer was wrong, so the text stayed and the answer was retaken the next week, and that pass came back vetted.
What a client gets from this seat is a signer who can explain every change in their system, in their own words, before it goes in.
Business Analyst
Nothing is owned without a written intent. Before the gate asks a single question, there has to be a ticket or a project document that says what is being built and why. No intent is an automatic gap, and the gate does not clear until one exists. The intent then becomes the yardstick: anything in the plan the document does not mention is scope creep, and anything the document promises that the plan does not deliver is unmet.
The analyst also chose what the questions aim at. About 450 past code reviews were read for the defects that kept returning, and four families came back again and again: an error that is swallowed, a permission check that is missing, a test that always passes, and a shortcut comment that shipped anyway. The question bank is built around those four.
The analyst's own step runs first. The plan is challenged on its value, its cost and its alternatives, including doing nothing. Then the consultant owns it.
PMO
The PMO put the gate into the delivery loop twice: once before a plan is approved, and once before a diff leaves its branch. A study guide for the piece of work is written first, every time, and saved where the project records live. Then the signer chooses: take the questions now, or defer them.
A deferral is owed, not waived. It comes due at the end of the calendar day or when the working session ends, whichever is first. Critical findings, blocking findings from the challenge, and anything hard to reverse or touching production data, money, security or secrets get no deferral and no skip. Work the PMO has flagged as major can be deferred but never skipped.
Every deferral and every skip goes in a ledger, one row per gate, with the date, the session, the work item, where the study guide is, and the state: waiting, owed, done with its verdict, or skipped with the signer's reason in the signer's words. A row that came back gaps or not cleared carries a no-skip mark. An overdue row stops that session's next merge. Since October 14 a session is held only by the rows it wrote, so an overdue gate on one project cannot stop an emergency fix on another.
On October 13 the PMO capped a run at three questions, with up to three more on any gap, after drills of 5, 6, 8 and 17 pieces in two days. Anything the three questions do not reach is listed as not drilled. On October 23 the rule for that list was set: a routine piece left undrilled still lets the gate clear. A risky one keeps the row owed until it is drilled or skipped in the signer's words.
Since October 22 every unit of work also carries a checks table, one row per acceptance criterion, with a verdict and the evidence that earned it. A row with no evidence is never marked pass.
Developer
The developer meets the gate at two points in the loop. On a plan, after the challenge and before approval. On a diff, after the simplify pass and before the pull request opens.
On a plan the gate quizzes. It asks one question at a time, waits, and is not allowed to answer the question itself, because answering it would hand over the ownership instead of making the signer earn it. On a diff the default is a teach-back: the signer explains the change cold, and the gate probes only the holes, because a leading question is easier to fake than a cold explanation.
The first question on any chunk of a diff is who wrote it. If the developer wrote it, the next question is why this way. If an agent wrote it, the developer explains it as if they had written it. A run covers at most three chunks or groups of chunks, the riskiest first, and the report names what was not drilled. A vetted verdict covers what was drilled, and only that.
Code Reviewer
The reviewer works in a separate session with none of the builder's context, and its findings decide what the gate may do. A Critical that the change introduced, or a blocking finding from the challenge, closes the door on a deferral: the code gate runs on the fixed head before the merge, and the ledger row is marked as no longer open to deferral or skip. If such a finding is raised after a deferral was already granted, the deferral ends.
The reviewer, not the builder, says when a finding is closed. The builder's reply to a finding does not close it. The reviewer's verdict on the new head does.
The four defect families the gate asks about came out of the reviewer's own corpus. The gate is the reviewer's history turned into questions.
QA
The end-to-end step runs on the exact commit that will merge, and it runs as it applies. Code, scripts, hooks and settings all have something to run, and a skill or rules file counts as code here. A document that no session and no script acts on gets no end-to-end step. The call is stated in the pull request, in one line with the reason, and the reviewer's approval has to confirm it.
A test that was skipped or not run is a stop, not a note. QA never writes to production and never deploys. Where no real run was possible at all, the step has not passed, and the merge waits.
The gate and the suite are not substitutes. The drill checks the signer. The suite checks the code. One cannot stand in for the other.
Still open
The gate's skill does not yet read or write the ledger by itself. The PMO keeps it by hand. The word major has no written definition, so the session says when it thinks a piece is major and asks each time. The defaults around the three-question cap are the session's choices, not the consultant's decisions, and the record says which is which. And once, in the week of June 29, a gate was closed by saying "I own it" with no drill run. The note says so. It does not pretend the drill cleared.