Meridian Line's data scientist logs the port-operations copilot chain with mlflow.log_model(), but does not pass a conda_env, pip_requirements, or extra_pip_requirements argument, relying on MLflow's automatic dependency inference. When the model is deployed to a serving endpoint weeks later, it fails to start with an import error for a library the chain actually depends on. What most likely went wrong?

When dependencies aren't pinned explicitly, MLflow's automatic inference records what it can detect as importable in the current session at logging time — which is a best-effort snapshot, not a guaranteed-complete or version-pinned dependency list. A library imported conditionally, imported deep inside a helper module, or simply present in the notebook environment but not correctly captured by inference can be missing or mismatched by the time the endpoint tries to build its serving environment, producing exactly this kind of import failure; later environment drift can also make the recorded inference insufficient. The fix is to explicitly pass pip_requirements or conda_env with the real, pinned dependency list at logging time rather than relying on inference. The claim that Model Serving endpoints cannot install any Python packages at all is false: Model Serving endpoints do install the Python packages recorded with the logged model automatically, so this does not describe a much more manual process than the platform actually requires. The claim that MLflow automatically re-logged the chain when the endpoint started is also false: the artifact and its recorded environment are fixed at logging time and do not change on their own. The claim that Unity Catalog strips all dependency metadata from a registered model as part of registration is false as well: the registered model version carries forward the same logged artifact, environment file included. Exam framing: 'a correct signature and dependencies' under MLflow logging explicitly includes accurate, pinned requirements, not just an inferred best guess.