A data engineer at Meridian Line finishes validating the port-operations copilot chain in a notebook and calls mlflow.log_model(), then wants it available to the deployment team as a governed, versioned asset that Unity Catalog permissions can control. What must they do next?

mlflow.log_model() writes the model as a run artifact — useful for reproducibility, but it isn't a governed asset and it isn't versioned in a way Unity Catalog permissions apply to. The step that creates that is registration: pointing mlflow.register_model (or the UI equivalent) at the logged model's URI with a three-level Unity Catalog name, catalog.schema.model_name. Each registration call against the same name creates a new version, and Unity Catalog's normal table/schema-style grants then govern who can read or serve it. Sharing the artifact URI or a pickle file sidesteps registration entirely — nothing about permissions, versioning, or lineage attaches to a raw artifact copy, and unpickling directly also throws away MLflow's environment/dependency metadata that Model Serving relies on. Granting run access lets someone re-run the logging code, but a run is not a servable, permissioned entity — it is exactly the un-governed state the team is trying to move past. Exam framing: 'log and register to Unity Catalog with MLflow' are two distinct actions in the deployment sequence, and only registration produces the versioned, governable model that a serving endpoint or an alias can point at.