Policy routing, explained.

Every API key is created with a compliance profile: which deployment paths it may route to, what retention terms are acceptable, what regions are permitted. The profile is set at key creation, by the account owner, on the server side. Requests inherit it. There is nothing to remember per call and nothing a calling service can quietly widen.

A request may add restrictions on top of its key's profile. It may never loosen them. If a header asks for something the key's profile forbids, the request is rejected. The strictest layer always wins.

Policy checks run before any tokens reach a model. If the gateway cannot affirmatively resolve a route that satisfies the request's policy, the request fails. It is not routed to a default, and it is not queued for retry against a looser path. An unresolvable request is a rejected request.

Every rejection returns a fixed, documented error code stating which check failed. The same request against the same policy fails the same way every time. You can write tests against our refusals.

The gateway's own logs are designed to record routing metadata: timestamps, key ID, model route, policy decision, token counts, error codes. Not prompt bodies. Not completions. The logging boundary is a design commitment we intend to pin with tests before the endpoint goes live.

The gateway will include a narrow, deterministic reject for a defined class of emergency-related inputs. It returns a fixed error code before inference. That is the whole mechanism. It is a refusal, not a safety feature: PHIGate does not detect emergencies, does not triage, does not escalate, and must never be relied on to respond to one.