The second check a money screen pays for
Most routes wait once at the front door. Routes that touch money wait twice, because a venue may have held that action back from a role. That hop is deliberate.
We have been taking round trips out of routes for a week, one screen at a time, and the test that proves each one counts how many times the route waits on the database with nothing else in flight. The front door is one wait: the session and the venue are read together. A well-shaped route is the door plus one wave, two steps. So when the payouts route came back at three after its fix, with everything else at two, the first question was what we had missed.
The third step is a read of the venue's permission classes, and it is not ours to remove.
What a venue can hold back
A food hall has roles: the hall's owner, a kitchen's owner, a manager, the person on the till. Those decide most of what a screen shows. But a venue can go further and hold specific actions back from a role: refunds, discounts, voiding a sale, seeing the payouts. That list lives in a small table per venue, and it is only the exceptions somebody asked to control, which is why it is nearly always empty.
The gate reads that table for a request only when the route is one of the guarded ones, which are the routes that move or show money. For every other request it reads nothing extra. So a guarded route genuinely costs one more round trip than an unguarded one, on purpose, every time, for every account including the owner's.
Why it stays
It would be easy to cache. It would also be wrong in the way that matters most. The point of the list is that a manager who could see the payouts this morning cannot see them this afternoon if the owner decided so at lunch, and a cached answer is a window in which that decision has not happened yet. A refund is not something you want a stale permission to allow once.
So the test pins the payouts route at three and says why in the assertion message, and it goes further: it checks that the third step is the permission read and not something else that happens to cost a hop. A test that said "three" and nothing more would pass if the permission read vanished and a wasted read took its place.
Our speed rule is that any screen over three hundred milliseconds gets made faster. The rule does not say every route must be the same depth. A money screen in this product is one hop dearer than a menu screen, from every distance, and the board should expect that. The job on a money route is the same as on any other: find the waits that are keyed on an answer already in hand and run them together. The one wait that is keyed on a decision somebody might have made a minute ago stays where it is.