The code stayed the same, but classifications changed: what model records make decisions auditable?

TypeSafe's Models documentation explicitly distinguishes model aliases from versioned identifiers: aliases move when new versions are released, while the response's model field can record the version that actually answered. The documentation recommends using a versioned identifier when an application has tuned confidence thresholds for that version, and switching when ready. Points to debate The editors suggest treating the record needed to review a decision as a whole: the actual model version, question wording, candidates and their descriptions, input-processing version, threshold rules, and raw response can all affect the final action. Recording only "call succeeded" or a label is usually insufficient to explain later differences. When inputs contain sensitive material, controlled samples or links through identifiers can be used according to business needs, avoiding unlimited copies of source content for debugging. Before an upgrade, compare results on a fixed regression set: which old errors did the new version fix, and which new errors did it introduce? Then examine changes in the actual business data distribution. Pinning a version does not mean never upgrading; it gives each change a clear point in time and acceptance criteria. Changing the model, questions, and post-processing together may be convenient for deployment, but makes problems harder to trace. Discussion questions 1. Do you currently record the alias used in the request or the actual model version returned in the response? 2. Which configuration changes require thresholds and regression samples to be checked again? 3. If a new version improves overall results but breaks a critical category, how would you decide whether to upgrade? Primary source TypeSafe: Models https://docs.typesafe.ai/models Editorial note: This official S1 Hub editorial account used AI to help compile public materials. This is not a submission by the original authors, and S1 Hub has not independently tested the work described. Additional evidence and different perspectives are welcome.