Classification is fully algorithmic

Classification is fully algorithmic: a change is scored Green, Yellow or Red by the evaluation system rather than by whoever happened to open it, and the same change always lands in the same class. If every quality gate passes and nothing trips a Yellow or Red condition, the change is Green - not because a human agreed, but because the criteria say so.

This area owns the verdict, not what is done with it. Whether Green means straight to production, or into a queue, or onto a release train is a Merge & Deploy question, and it can change without anything here changing. What this level asserts is narrower and harder: that the classification itself is a function of the change, computed the same way every time, by something that can be inspected and argued with.

This is L4 (Governed) - a significant psychological and organisational step beyond L3. At L3 the AI review agent is an advisor: its comments inform human judgement, and humans make the final call. At L4 the algorithm makes the call for Green changes, and human engineers are not in the loop for routine ones.

Reproducibility is what separates this from a well-automated L3. A classification that varies run to run is not a policy, it is a mood: the same diff scored Green on Tuesday and Yellow on Wednesday tells an author nothing they can act on, and quietly reintroduces the reviewer lottery that automation was meant to end. This is the specific place where a language-model reviewer needs constraining. An LLM asked for an open-ended opinion will produce a different one each time. An LLM asked to evaluate named criteria, whose output is reduced to a small set of structured findings, and whose findings are then mapped to a class by explicit rules, is reproducible enough to be a gate. The determinism lives in the rules; the model supplies evidence for them.

The algorithmic decision is grounded in a question: what does human approval add for a change that has already passed every quality check? If the tests are comprehensive, the lint enforces architecture, the AI agent found no issues, and the diff is within safe parameters - what is a reviewer adding by clicking "Approve"? In most cases nothing except elapsed time and cognitive overhead. The approval is a ritual, not a judgement.

Algorithmic classification eliminates that ritual for the cases where it provides no value. Human judgement continues to be spent on Yellow changes (those that genuinely require it) and Red ones (those with blocking issues). What changes is that routine work - the clear majority of day-to-day commits - no longer waits for a person to reach the same conclusion the criteria already reached.

The prerequisites are significant: a trustworthy Green evaluation (high confidence that Green means safe), comprehensive tests, a complete lint configuration, and a well-calibrated AI review agent. Teams that hand the verdict to an algorithm before these foundations are in place will introduce incidents and retreat. Teams that build the foundations first find the handover unremarkable.

The impact compounds with volume. For a team submitting 50 changes per day where 60% classify as Green:

• 30 changes per day no longer wait for a human verdict - each was waiting an average of 3-4 hours. That is 90-120 hours of wait time eliminated daily.
• The verdict becomes something an author can predict - a deterministic classifier can be run before the change is even opened, so authors stop discovering the bar after the fact and start writing to it
• Developer flow is preserved - code submitted in the evening (when human reviewers aren't working) merges overnight. Developers return in the morning to a merged change, not a waiting PR.
• Reviewer capacity is recovered - the 20 changes a day that still require human judgement get better attention than when reviewers were handling 50; the quality of human review for Yellow and Red goes up.
• Disagreement moves to the criteria - when the class is reproducible, an argument about a verdict becomes an argument about a rule, which is a durable, reviewable artefact rather than a conversation on one pull request
• What happens next becomes a policy choice - once the class is trustworthy and stable, Merge & Deploy can decide independently how fast each class flows, without renegotiating what the classes mean.

For teams accustomed to human review as the quality gate, the psychological barrier is real. "What if something slips through?" is a legitimate concern. The answer is that the same evaluation which caught it before the reviewer looked catches it now. If the gate was working - which you verified at L3 - it continues working at L4. The difference is that there is no human in the loop for Green changes, and there was no meaningful human contribution to those changes anyway.

1. Verify your Green criteria are conservative and trustworthy - Before the classification governs anything, audit 60 days of historical changes. What proportion would have scored Green under your criteria? Randomly sample 20 of them and review manually. If you find issues in more than 1-2%, tighten the criteria before proceeding.
2. Test the classifier for reproducibility, not just accuracy - Score the same change several times, on different runners, at different times of day. Any variation is a defect, and it usually traces to one of three things: a model asked for a free-form opinion, a flaky check feeding the classifier, or a criterion that reads mutable state such as the current contents of main. Fix all three before trusting the class.
3. Publish the class as a status the rest of the system can read - The classifier emits its verdict as a check with a stable name, so branch protection, dashboards and downstream automation all consult the same value. Keep the emission separate from any action taken on it: this area's job ends at declaring the class.
4. Establish a monitoring policy - For the first 90 days of auto-merge, have someone review the "auto-merged last 24h" list each morning. Are any auto-merged PRs creating follow-up issues? This monitoring establishes confidence and catches any gaps in the Green criteria.
5. Create an override mechanism - Allow authors (or reviewers) to mark a PR "requires review" even if it would score Green. Some changes feel important to have a human review even if they meet all technical criteria. The override should be easy to use without penalty.
6. Track the post-merge defect rate by class - Class becomes a new dimension in your defect attribution data. Are Green changes more or less likely to introduce bugs than the ones a human looked at? This is how you find out whether the classes mean what you think they mean, and it is the evidence that lets you tighten or relax them deliberately rather than after an incident.

Letting the classifier govern before it is proven. The most common failure mode: teams skip the validation step, wire the class into the merge path, and within weeks have an incident caused by a change their existing gates never caught. This destroys confidence in the whole system, usually for a couple of years. The 30-day dry run is not optional.

A classifier that disagrees with itself. If the same diff can score Green on one run and Yellow on the next, the class is not a verdict and cannot be the basis of a policy. Non-determinism most often enters through an unconstrained language model, a flaky test feeding the gate, or a criterion evaluated against whatever main happened to contain at the time. Treat a disagreement between two runs on the same input as a bug of the same severity as a false Green.

Defining Green too loosely under pressure. "Our Green rate is only 30% - if we loosen the criteria, we could get 60%+ auto-merging." The right response to a low Green rate is to fix the underlying quality issues, not to lower the bar. A looser Green definition with more incidents is worse than a strict one with a lower auto-merge rate.

Not communicating the change to the team. If developers are not told that Green changes are decided by algorithm, they will be confused when they return to find one resolved without any human approval. Announce it, explain the criteria, publish them where people can read them, and make it clear how to opt out with an override.

Hiding the reasoning behind the class. A verdict nobody can interrogate is a verdict nobody will accept, and the first surprising Red will produce a demand to disable the whole thing. Every classification should say which criteria it evaluated and which one moved it out of Green, in language the author can act on without asking anybody.

Losing the ability to revert. Auto-merged PRs ship to main the same as any other PR. Ensure your deployment and rollback processes are healthy before enabling auto-merge. If a bad auto-merge reaches production, you need to be able to revert it quickly. Trunk-based development with feature flags is the ideal complement to auto-merge.