A request enters. A request leaves. Everything between is structure or decoration.
What you're looking at
Three vertical lanes. The first lane contains the guards — parse, validate, authorize. The second contains a routing decision and the execution block, which is the only element that does work. The third lane formats, logs, and sends the response. Two arrows cross lanes: one black from entry to transform, one blue from execution to exit. A red arrow drops from the routing diamond straight down — the rejection path that bypasses execution entirely.
Why I drew it this way
Most pipeline diagrams show every step at equal weight, as if parsing and executing were peers. They are not. Execution is the single load-bearing element; I gave it a heavier stroke and the only accent color. Everything else is preparation or cleanup. The rejection arrow falls vertically because rejection is gravity — it requires no energy, no decision after the initial fork. The accepted path moves horizontally because it must be pushed through each stage.
What it argues
The structure argues that most of your pipeline is not your pipeline. It is the frame around the one thing that matters. If you removed Parse, Validate, Authorize, Format, Log, and Respond, you would have a function call. The architecture exists because we do not trust the caller or the network or ourselves. The diagram shows this: the blue stroke is surrounded by black infrastructure.
What I left out
No error-handling boxes, no retry logic, no middleware stack. Those are real, but they are variations on the same theme: more guards, more formatting. Adding them would obscure the argument. A request pipeline has one moment of creation (Execute) and ten moments of suspicion. I drew the suspicion.