Meridian Line's crew-report translation tool was logged and registered with a signature declaring a single string input and a single string output. The team now wants to pass a structured request (language code plus report text) instead, without changing the deployed endpoint's contract for existing callers. What must happen?

An MLflow model signature defines the input/output schema the served model enforces, and changing that shape (a single string versus a structured object with a language code and text) is a breaking change to the contract — it requires re-logging the model with the new signature and registering it as a new version, since a registered version's signature is fixed as part of that version's artifact. To avoid breaking existing callers, the new version is typically rolled out behind a new endpoint (or a new version/alias on the same endpoint that old callers aren't pointed at), so string-input callers keep working against the version whose contract they were built for. Signatures are not advisory — Model Serving validates requests against the stored signature and rejects mismatched payloads, which is exactly the enforcement behavior seen earlier when a mismatched signature caused staging failures. Model Serving does not dynamically infer a different schema per request against an already-registered version; the signature is fixed for that version, not re-derived per call. Signatures are part of the logged model artifact for a given version, not a piece of metadata that can be edited in place without creating a new version — there is no in-place signature edit on an existing registered version. Exam framing: this connects signature enforcement (earlier tested as a staging failure) to safe version management when the actual input contract changes.