A policy needs a fact captured at the server edge and an operation identity that only routing produces — where should it decide?

## The constraint that decides the shape Everything here follows from one asymmetry. **A hook sees only what has already been computed when it runs.** Transport facts exist from the first byte; operation identity exists only after routing; bound arguments exist only after dispatch. So: - A fact observed **early** can be carried **inward**, by writing it into the per-request state the framework threads through the exchange. - A fact that only exists **later** can never be made visible **outward**. No mechanism moves it backwards in time. Therefore the decision point has a floor: it must sit **at or below the altitude of the latest fact it consumes**. Everything else in the design is a trade-off around that fixed point. ## The candidate shapes 1. **Capture outward, decide inward.** The outermost element stamps connection facts into per-request state; the handler-aware element reads them alongside the operation identity and decides. This is the default, and the only one that works when the policy genuinely needs both. 2. **Decide at the pipeline altitude, after matching.** If the route template is precise enough — the policy needs "which operation", not "which arguments" — the decision can sit in the chain once matching has happened. Cheaper than going all the way in, and it still refuses before the body is parsed and bound. 3. **Two-stage: coarse guard outward, precise decision inward.** A cheap, conservative check at the edge rejects what is obviously disallowed under any operation; the precise check runs deeper. This bounds the work an unauthorized caller can provoke without pretending the edge knows more than it does. 4. **Push the decision into each handler.** Maximum context, zero uniformity — the check is now opt-in per handler and the next handler someone writes will forget it. Reasonable only when the policy is genuinely per-operation logic rather than a cross-cutting rule. ## How to choose between them | Consideration | Pulls the decision outward | Pulls the decision inward | |---|---|---| | Cost of work done before refusing | Refuse before parsing, binding, and any handler work | Accepts that cost in exchange for precision | | Precision available | Only transport and raw text facts | Operation identity and converted arguments | | Coverage | Sees refused and unmatched traffic too | Sees only requests that reached a handler | | Uniformity | One place, applies by construction | Applies only where the attachment point applies | | Portability across frameworks | Depends least on framework internals | Depends most on the handler model | | Blast radius of a mistake | Wrong refusal affects everything | Wrong refusal is scoped to the operation | ## The failure modes to design against - **Fail-open on a broken split.** If the capture half is removed, renamed, or simply not registered on some path, the deciding half reads an absent value. It must treat "fact missing" as a refusal, not as a permissive default. Write the test that removes the capture and asserts a refusal. - **Two sources of truth for the same fact.** Once a transport fact is copied into per-request state, something deeper may also try to derive it — for example from a forwarded header. Pick one derivation, do it once, at the altitude that can validate it. - **A decision that outruns its coverage.** A policy that must hold for *every* request cannot live only at an altitude another stage decides the coverage of. - **Silent divergence between the coarse and precise checks.** In the two-stage shape, the outer guard and the inner decision encode overlapping rules; when one is updated and the other is not, the system's behaviour is whichever is stricter, which is rarely what anyone reasoned about. ## What to say out loud in an interview Name the constraint first, then the shape, then the cost you accepted. A strong answer sounds like: "the decision has to run where the operation is known, so the transport facts get captured outward and read inward; I keep a cheap conservative guard at the edge so an unauthorized caller cannot make us parse a large body; and the deciding half fails closed if the captured fact is absent, with a test that proves it." A weak answer picks an altitude by habit and never mentions that one of the two facts cannot be seen there. ## Frameworks differ here Frameworks vary in how much of this is handed to you: some carry a rich per-request context that any altitude can read and write, others give you a plain attribute map, and others expect the value to be threaded explicitly through the call. The capability changes the ergonomics of the split, not the constraint behind it — the order in which facts come into existence is a property of request processing, not of any one framework.