Great insights as always!
Unversioned prompts edited on the fly in dashboards are definitely a nightmare for debugging production regressions.
Your point on fallback routing is crucial—switching providers mid-flight can completely break downstream schemas or token budgets if not validated properly. Combining strict output validation (like Pydantic/Zod schemas) with structured outputs is essential to turn those silent fallback drift errors into explicit, catchable failures. Thanks for adding this context!
Putting prompt versioning and user input is also data next to each other is the right instinct, because those two sections carry most of the operational risk in this list. Unversioned prompts are the reason nobody can explain a behaviour change: the model is pinned, the code is in git, and the one artifact that actually determines the output was edited in a dashboard by someone in a hurry. On fallback routing I would add a caution - a fallback to a different provider is not a transparent substitution, since output shape, refusal behaviour and token accounting all shift, so anything downstream that parses the response needs to survive the swap. That is where structured output plus validation earns its place: the validator is what turns a silent degradation into a caught error.