A decision nobody can explain cannot be improved, trusted or defended. The routing trace exists so that every choice the router makes can be read back by a person: an engineer asking why a cheap model got a hard question, a finance lead asking why the bill moved, an auditor asking which provider could have seen a record. It is produced for every request, in the response's metadata and in the request log, and it is the raw material the learning loop and the savings ledger are built from.
Reading a trace goes top to bottom. The signals come first - the actions, domains, complexity, language and sensitivity the router extracted - because a wrong reading of the request explains most surprising decisions. Then the candidates: each target with the score every strategy gave it, its estimated cost at this request's length, and whether a hard constraint removed it and which. Then the rules that fired, with their weight and whether they pinned. Then the winner, the runner-up and the confidence - how clearly the winner won, not how likely the answer is right.
After the call the trace grows: the provider's latency and token counts, the real cost, any fallback with the error that caused it, and, when the application reports it, the outcome - success, a quality score, a correction. That last field is what turns a log into learning: the learners update the chosen target's quality estimate for this kind of request, and the next similar request's trace shows the moved score.
Traces are also what the trace does not hold. By default it stores no prompt and no answer - the signals are enough to explain the decision - and the audit trail that chains the entries by hash makes an altered record detectable. Where a workspace needs the text, a policy switches the request log on with its own retention. The playground renders the full trace for any request, which is the fastest way to learn to read one.
