After registering a new version of the port-operations copilot, the Model Serving endpoint fails to load it with an error about an unexpected input field type. What is the most likely cause, and what should the engineer check first?

An MLflow model signature declares the expected schema (field names and types) for a model's inputs and outputs, and it is enforced when the model is served. An 'unexpected input field type' error is the classic symptom of a mismatch between what the signature declares and what the endpoint is actually being sent (or between what the new version's chain code expects versus what the previous version accepted), so the first diagnostic step is comparing the logged signature to the actual request payload and to any application code that constructs requests. Deleting a Vector Search index would cause a retrieval failure inside the chain's execution, not an input-schema-level rejection at the serving boundary, and it doesn't 'always' produce any single error class. Renaming a Unity Catalog alias changes which version the alias points to, not the input type a given model version expects — aliasing and signatures are unrelated concerns. Scale-to-zero governs whether idle compute is released and has no bearing on input validation or field types whatsoever. For the exam, remember that signature mismatches are diagnosed by comparing the logged model signature to the actual caller payload, not by looking at retrieval, aliasing, or capacity settings.