Confidence Gates Before You Merge AI Work
Quick answer: Treat the merge of AI work as a sequence of gates rather than one approval. A static gate confirms the code still compiles and the known checks pass, a contract gate confirms the schemas agree, a dynamic gate confirms the changed path with real requests and a business-flow check, and the final gate is a human decision on anything left open. A change passes only when the evidence it actually has clears the gate, and partial verification stays partial.
Why separate gates beat one checkbox
A single approval hides the difference between distinct kinds of evidence. A build can be green while the contract drifts, a contract can match while the runtime behavior is wrong, and a runtime check can pass on one path while another stays untested. Folding all of that into one checkbox makes a weak change look fully verified.
Separate gates make the evidence explicit. Each one answers a different question, and a reviewer can see exactly which gate a change failed rather than guessing from a single status.
The gates and their pass standards
| Gate | Question | Pass standard |
|---|---|---|
| Static | Does it compile and pass known checks? | Typecheck, lint, build green |
| Contract | Do the schemas and types agree? | No drift against the contract |
| Dynamic | Does the changed path work? | Real requests and a flow check pass |
| Coverage | Is the new branch actually exercised? | A test or request reaches it |
| Human | What remains uncertain? | Open items reviewed and accepted |
The human gate does not re-run the checks. It decides whether the open items are acceptable given the evidence the other gates produced.
Running the gates in order
- Start with the static gate and treat a red build or typecheck as a hard stop.
- Check the contract gate for schema or type drift on the changed operations.
- Send real requests that exercise the changed path and assert the response and side effect.
- Run the business flow so the change is confirmed inside the sequence it really runs.
- Confirm the new branch is actually reached, treating a missing check as unverified.
- At the human gate, list the open items and accept, reject, or send the change back.
Take a change that alters a deletion filter. The static gate passes, the contract gate shows no schema drift, and the dynamic request reveals an archived note is removed, so the gate fails and the change goes back. Once the guard is added, the request and the flow both pass, and the coverage gate confirms the new branch is exercised. The human gate then sees no open items and accepts the merge.
Partial and empty results
The gate model depends on honest states. A check that does not reach the new branch is not a pass, and an empty result is inconclusive rather than a success. Partial verification stays partial, and only fully verified evidence passes, with the verdict determined deterministically and no LLM involved.
An AI-only claim is always a hypothesis and cannot clear the dynamic gate on its own, no matter how confident it reads.
Powerduck classifies the evidence and keeps the gate states visible, so the reviewer sees which checks passed rather than relying on one approval.
When a gate cannot run
A missing gate is not a passed gate. If the project has no contract to check, or the command for a dynamic check is absent, the gate cannot be evaluated and stays unverified rather than defaulting to green. Record which gate could not run and why, then decide whether to add the missing check, run the request manually, or accept the gap with eyes open. The same rule applies when an environment is unavailable: a check that never executed produces no evidence, and treating it as a pass hides the exact risk the gate model exists to surface. Keep the blocked gate visible in the record so the human decision reflects the real coverage rather than an imagined complete set.
Honest limits
Passing every gate still bounds the change to the paths that were exercised, and edge cases outside the requests remain open. Dynamic loading and external consumers can stay outside the coverage, and the model can raise false suspicions or miss defects.
Keep the open items visible at the human gate rather than assuming the gates prove every behavior.
Frequently asked questions
How many gates does a change need? Static, contract, dynamic, and coverage, followed by a human decision, and each has its own pass standard.
What happens to an empty test result? It is inconclusive and cannot clear the gate unless the check actually exercised the change.
Does the human gate repeat the checks? No, it reviews what remains uncertain and accepts, rejects, or sends the change back.
The bottom line
Do not merge AI work on one checkbox. Run it through static, contract, dynamic, and coverage gates, then make a human decision on the open items, and keep partial or empty results honest rather than promoting them. Each gate answers a different question, and an AI-only hypothesis cannot clear a dynamic gate. Even a clean set of gates is bounded to the paths that were run. The evidence, not the approval, is what makes the merge confident. Read more in the API scenario testing guide.