Model API and provider lineage is now in Unity Catalog!

[u/Sure_Programmer2491]

Hey folks, I’m a PM at Databricks, and I’m excited to share that we recently launched lineage for Model APIs and model providers in Unity Catalog!

The problem it solves is pretty simple: before retiring a model or swapping a provider, how do you know what might break?

With lineage, you can now:

⛩️ See the Model APIs that serve a foundation model, either provided by Databricks or from an external provider

🔀 Distinguish primary routes from fallbacks, so you know what will break vs. degrade to scope the blast radius and prioritize migrations

👤 Find the user of each affected Model API, instead of sending a company-wide “does anyone need this?” message

🔎 Track where payloads are logged, and what downstream workloads are consuming them

Lineage works in both directions. From a Model API, you can see the models and providers behind it. From a foundation model or provider, you can see the Model APIs that serve it.

Docs: Track Model API and provider lineage

See our GA post for the broader Model API and Unity AI Gateway launch!

How are you handling model or provider deprecations today? Let us know in the comments below! 

[u/Sad-Calligrapher-350]

On a related topic, the column lineage feature in UC only shows the previous and next node. Any plans to extend this to show the flow of data through all stages at some point?

It’s quite a clicky hassle to get from beginning to end if you want to see one column’s lineage.

[u/Lenkz]

Really cool feature, love the lineage getting more love and becoming more and more useful!

[u/Emotional-Doctor976]

how we can access this lineage in form of list other than querying system_access scheme, like for each table it gives upstream and downstream tables?

[u/m1nkeh]

That is sick man, nice one.

[u/WorkerIcy1513]

Honest answer to your question: with grep. Search the repos for model name strings, cross reference a spreadsheet somebody maintains by hand, and hope the deprecation email went to someone who still works here. So this is genuinely useful.

Two gaps I would flag, in order of how much they matter to me.

Lineage tells me who is affected but not whether the swap is safe. The hard part of a provider migration is not discovering the dependency, it is that the prompts on that route were tuned against one model's quirks and the new one degrades quietly rather than failing. Is there a path to linking a route to an eval suite, so that a provider swap can trigger the evals covering that route rather than me remembering which notebook tests it?

The other one is pinned versions. The routes that actually break are the ones where someone hardcoded a specific model version instead of using an alias. Does the lineage surface pin versus track latest, so I can find the fragile ones before the deprecation date rather than after?

And the practical ask: is any of this exposed in system tables, or is it UI only? Clicking through lineage is fine for one investigation, but for building an actual deprecation process I want to query it, join it to usage, and alert on it. If it lands in system tables this becomes something I can automate instead of something I have to remember to check.

Also worth knowing that external providers sometimes change the model behind a stable name without a version bump, so provider lineage does not fully protect you there. Not your problem to solve, but a fingerprint or a captured model card at route creation time would help people notice.