QueryAdmission

The one admission pipeline of an aggregate's queries: it turns what a caller submitted into the AdmittedQuery a QueryBackend may execute, in the fixed order of the design (§5.4):

1. the entry is accepted by the entry policy and the submitted query plus the caller's scope fit the entry's budget; once the schema is known, an authenticated scope is required when the policy says so;

2. the QueryFilters rewrite the query, in order;

3. the caller's scope, the route's selection (an operation constraint, such as the aggregate id of a load route, not caller scope) and every QueryPolicy restriction are appended, after all rewrites, so no filter can see the selection or remove any of them;

4. the model's default scope is appended, judged on the query steps 1 and 2 produced: a snapshot query already carrying any deletion scope, a policy's included, keeps it;

5. to 6. the operation finishes the query (a cursor's unique tie-breaker sort), then it is validated, normalized and resolved (Trusted).

The caller's entry, scope and route selection are read once, from the subscriber context of the admission. Every rejection is an error signal of the returned publisher.

admitRecord runs step 0 (without a budget), 2 and 3 for a record read without a backend query (a state point read).

Code that drives a backend directly and owns governance itself (backend conformance tests, tools, benchmarks) admits through Trusted instead, whose name says it skips steps 0 to 3.