an identifier that has to survive the rejection

Every support conversation about a platform starts the same way: something went wrong, on some screen, at some point today. Without a shared identifier, the account the customer gives and the account the server keeps cannot be joined, and the conversation becomes archaeology. The interesting part is where the identifier has to sit.

The decision was to mint one at the application boundary, outermost — outside the authentication guards and outside the rate limiter. That placement is the point: a request refused before it reaches any handling logic has still been seen, and those are precisely the requests people ask about. Generated deeper in, every rejection answers without one.

Three details made it real. An identifier arriving from a caller is preserved exactly rather than replaced, so a correlation started upstream survives. The final identifier is echoed on every response, including the shell fallback for unknown paths, which meant re-wrapping failures raised inside the guards so the framework's own error rendering could not answer without it. And each log record binds identifier, business and matched route, so one lookup replaces a search.

The reversal is worth admitting. The first attempt put this at the edge, where it belongs conceptually; the edge component's open build had no such capability, so it was removed and the identifier stayed at the application boundary beside access-log capture.

Cost: one concern wrapped around every scope, re-wrapped on every early rejection.

What it proves: the team places observability where it survives failure, not where it reads best in a diagram.