Pull request routing and approval solve a task usually handled by people manually: who should review this and can it be accepted without discussion. The system assigns reviewers by code ownership and change history and can itself approve low-risk changes by configured criteria. The boundary is worth fixing at once: this is not a full code review but routing with a limited right to wave through the obvious. The two are easy to confuse, because on the surface the outcome is the same - the pull request receives an approval.
The decision rests on several signals: findings from automated review, results of the security check, a risk score and policy files in the repository itself. It is the last of these that makes the mechanism suitable for large teams - the policy lies next to the code, is versioned with it and goes through ordinary review rather than living in settings only two people know about. Changing the rules becomes an ordinary change: it is visible in the history, it can be argued about in comments and it can be reverted.
The policy lookup is strict. For every changed file the system looks for a file with an exact name in its directory and up the tree; the nearest one wins. A different case, a backup or a similar spelling are ignored - and that is an important detail: a policy named almost correctly does not apply and does not say so. The mistake shows up not as a message but as silence: the rules you believed were in force simply take no part in the decision. Top-level routing lives in a separate directory as a list with products, boundaries and policies.
The most interesting part of the mechanism is protection against self-weakening. If a pull request changes the approval or routing policy itself, the system does not apply the new version to that same change: the base-branch version is used or a human is required. Otherwise one line in a policy would be enough to allow yourself everything else - and that would be the shortest path around any requirement. And where specificity is ambiguous, the stricter instruction applies, the same principle as with denials in permissions: doubt is resolved toward restriction.
Hence the practical recommendation about the ceiling for automatic approval. It is kept low, and protected areas where a human is always required are declared explicitly: authorization, payments, infrastructure, data migrations and the policy files themselves. Everything else can be loosened gradually as statistics accumulate, but not the other way round - starting with broad automatic approval and narrowing it after incidents costs more and takes longer, because by then the team has grown used to the absence of review.
The quality of routing depends entirely on the quality of ownership data. The system looks at who owns the code and who changed it, and in a healthy repository that is enough. But history ages: people leave, components are handed over, and there are files touched over a year by twenty people for one line each. In such places routing starts assigning formally correct but useless reviewers - the ones who once fixed the indentation. The cure is not in the agent's settings but in what it always was: explicit owners for directories and an honest map of responsibility that somebody maintains.
The approval ceiling needs feedback, otherwise it stays guesswork. What is worth measuring is not the number of automatic approvals but their consequences: how many such changes were later reverted, fixed straight afterwards or examined in an incident. That share is the honest calibration of the threshold. If it stays near zero for several months, the threshold can be raised carefully. If it grows, it is lowered without waiting for a discussion, because every mistaken automatic approval costs more than one skipped review: it also convinces the team that there is no point in looking.
There is also an organizational side that settings cannot solve. Automatic approval removes routine from people but shifts responsibility onto criteria: the quality of review is now determined by how precisely you described what counts as low risk. That is work that has to be done and maintained, and it is not a one-off, because the composition of a repository changes: new directories appear that no policy covers yet.
The engineering conclusion is simple: routing is useful where the team is large and code ownership is blurred. It saves not so much the review as the search for who should review - and that search is the main delay in the life of a pull request. Automatic approval is a separate decision with its own ceiling, introduced after routing already works predictably.
The typical failures are predictable. Naming a policy file almost correctly and not understanding why it does not apply. Setting a high ceiling for automatic approval at the start. Not declaring protected areas and getting automatic agreement where a human is needed. Not looking at the consequences of automatic approvals and leaving the threshold without feedback. And treating routing as a replacement for code review.
The automatic approval ceiling
[ ] a low risk threshold rather than a convenient one
[ ] review and security findings count as signals
[ ] protected areas always require a human:
authorization, payments, infrastructure, data migrations, policy files
[ ] a policy change does not weaken the requirements of that same pull request