A vessel maintenance log Delta table is used to build a maintenance-triage agent's retrieval index, and that index feeds a registered MLflow model serving the agent. A data engineer proposes changing the maintenance log table's schema. Before making the change, how should they determine what downstream vector indexes and models would be affected?

Unity Catalog automatically captures lineage as data flows through Databricks, table to table, table to vector index, and model to the tables or functions it depends on, which makes the lineage graph the authoritative way to answer 'what downstream artifacts depend on this table.' Tracing the table forward through that graph surfaces every vector index built from it and every registered model that consumes those indexes or the table directly, without relying on anyone's memory or documentation being current. Searching the file browser for notebooks that mention the table's name is unreliable, since a Delta Sync index is not necessarily built through a notebook that references the table by name in visible code, and this misses anything provisioned through configuration rather than explicit code. Asking teams informally depends entirely on institutional knowledge staying accurate and everyone actually responding, which is exactly the kind of manual process governance tooling exists to replace. Assuming additive schema changes are always safe ignores that a vector index or downstream job might depend on positional column order, a specific data type, or expect a fixed set of columns for metadata filtering, so 'only column removal is risky' is a false narrowing of the actual risk surface. Exam framing: Unity Catalog lineage is the mechanism for understanding impact before changing a governed data asset.