Unity Catalog Model Versions: LoggedModels, UI Registration and Aliases

1.MLflow 3 logging conventions that registration depends on

Registering a model in Unity Catalog means giving MLflow a reference to a logged model, so how you log affects how you register. MLflow 3 kept experiments, runs, parameters, tags, and metrics the way they were, but it made models first-class objects. Moving from 2.x is mostly straightforward, but a few changes show up directly in registration code. In MLflow 3, log_model() takes name instead of artifact_path. It no longer needs an active run. It stores artifacts under the model rather than the run, and it returns a URI of the form models:/<model_id>. Databricks recommends loading the model with that returned URI.

mlflow.pyfunc.log_model(
    name="model",
    python_model=python_model,
    ...
)

Compatibility only goes one way. MLflow 3 clients can load runs, models, and traces logged with 2.x, but models logged with MLflow 3 may not load in older 2.x clients. If a downstream job still pins an older client, upgrade it before you register MLflow 3 models it needs to read.

Sources1

2.Registering a GenAI chain as a LoggedModel

MLflow 3 introduced the LoggedModel: a log_model() call creates an object with a unique ID that links the model to its metadata, parameters, metrics, and code. For AI applications, a LoggedModel can capture a git commit or a set of parameters, which can then be linked to traces and evaluation metrics. A LangChain chain is logged with the langchain flavor's log_model(). In the example below, the generation parameters and prompt template are recorded on the LoggedModel, and the input example gives MLflow what it needs to infer a signature.

model_info = mlflow.langchain.log_model(
  lc_model=chain,
  name="basic_chain",
  params={
    "temperature": 0.1,
    "max_tokens": 2000,
    "prompt_template": str(prompt)
  },
  model_type="agent",
  input_example={"messages": "What is MLflow?"},
)

Registration works the same way for other model types. The Qwen3-4B fine-tuning tutorial logs its model and tokenizer with mlflow.transformers.log_model, setting task="llm/v1/chat" and passing registered_model_name=full_model_name, where the name is built from catalog, schema, and model variables. That single call logs the model to MLflow and registers it in Unity Catalog. The tutorial notes that this gives you governance, automatic versioning, and a path to model serving endpoints.

Registering a LoggedModel also makes its data visible in Unity Catalog. The model version page in Catalog Explorer shows its parameters, metrics, and traces across workspaces, endpoints, and experiments. By contrast, the Models tab on an experiment page compares logged models within that one experiment, which helps you choose which ones to register.

Sources234

3.Registering from the UI, and marking deployment with aliases

You can also register without writing code. On the experiment run page, click Register model in the upper-right corner. In the dialog, choose Unity Catalog, pick a destination model from the dropdown, and click Register. Registration can take a while, so check progress by opening the destination model in Unity Catalog and refreshing it.

A model version's catalog, schema, and registered model describe its environment and governance. For example, privileges might be set so that only admins can delete from prod. To record which version is actually in use, you use an alias: a named, mutable pointer to one version, such as Champion. Workloads refer to the alias, and promoting a new version just means pointing the alias at it. Setting or changing an alias requires owning the registered model, plus USE SCHEMA and USE CATALOG.

from mlflow import MlflowClient
client = MlflowClient()

# create "Champion" alias for version 1 of model "prod.ml_team.iris_model"
client.set_registered_model_alias("prod.ml_team.iris_model", "Champion", 1)

# reassign the "Champion" alias to version 2
client.set_registered_model_alias("prod.ml_team.iris_model", "Champion", 2)

To load a version by alias, use the models:/<name>@<alias> URI. This needs EXECUTE on the registered model, plus USE SCHEMA and USE CATALOG. A job that loads @Champion picks up whatever version the alias points to the next time it runs, so the job doesn't need to change when you promote a new version.

import mlflow.pyfunc
model_version_uri = "models:/prod.ml_team.iris_model@Champion"
champion_version = mlflow.pyfunc.load_model(model_version_uri)
champion_version.predict(test_x)

Sources5

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Registering a version under a catalog named prod means that version is now serving production traffic.Why is that wrong?

   The catalog and schema express environment and governance. Which version is deployed is tracked with model aliases such as Champion.

   Covered in Registering from the UI, and marking deployment with aliases

2. 2.In MLflow 3 you should keep building runs:/<run_id>/<artifact_path> URIs and passing artifact_path to log_model().Why is that wrong?

   MLflow 3 uses name= (artifact_path is deprecated) and returns a models:/<model_id> URI, which Databricks recommends using for loading and registering the model.

   Covered in MLflow 3 logging conventions that registration depends on

Practise it for real

Log a model with an input example, register it to Unity Catalog in the same call, and load it back through an alias.

1. 1.In a notebook on Dedicated access mode compute, run %pip install --upgrade "mlflow-skinny[databricks]" and then dbutils.library.restartPython().

   Why: Models in Unity Catalog and inferred signatures need a recent MLflow client and Unity Catalog-capable compute.

   You should see: Python restarts with the upgraded MLflow client.

2. 2.If your workspace's default catalog is not in Unity Catalog, run mlflow.set_registry_uri("databricks-uc").

   Why: Otherwise the client may register to the legacy workspace model registry.

   You should see: No output. Later registrations go to Unity Catalog.

3. 3.Call your flavor's log_model() with name, input_example, and registered_model_name set to a three-level name in a schema where you have CREATE MODEL.

   Why: The input example lets MLflow infer the signature that Unity Catalog requires, and registered_model_name registers the model in the same call.

   You should see: Version 1 of the registered model appears in Catalog Explorer, possibly after a refresh.

4. 4.Run MlflowClient().set_registered_model_alias("<catalog>.<schema>.<model>", "Champion", 1).

   Why: The alias, not the catalog name, records which version is deployed.

   You should see: The Champion alias shows on version 1 in Catalog Explorer.

5. 5.Load mlflow.pyfunc.load_model("models:/<catalog>.<schema>.<model>@Champion") and call predict on your input example.

   Why: This confirms that consumers can resolve the model through the alias.

   You should see: A prediction is returned from the version that currently holds Champion.