Stiekema StudioNederlands

Case sheet

Cataloom

A read-only tool for SQL Server, Azure SQL and Power BI that shows where a table or view comes from, which procedures, models and reports depend on it, and what a change touches. The links come from the actual view and procedure code, not from a language model; the output is a folder of standalone HTML files.

View the live site (opens in a new tab)

XBAS Business Intelligence B.V. · KVK 89736478 · Almere NL · Case cataloom

The documentation of Cataloom on the public WideWorldImporters sample database: on the left the object list with a search field, on the right, under the heading "AI-generated documentation from the actual view and procedure logic", a procedure with a description derived from the procedure code and a collapsible SQL definition, and below it a table with its description and its columns with type, key and nullability.
Plate · Cataloom

Summary

Cataloom is a self-built product for the Microsoft data stack. It reads, read-only, the catalogue and the code of views and procedures in SQL Server or Azure SQL, and through the Scanner API the semantic models and reports in Power BI. From that it builds one chain: the source table, the procedures and views that read or fill it, the model that leans on it and the reports above that, wherever the link can be shown. That makes it possible to see per object where it comes from and what depends on a change. Lineage and relations are mined deterministically from the code; the language model only adds the business descriptions and invents no links. Alongside that runs an audit on the SQL side and the Power BI link, from orphaned references to models that read an object that no longer exists, and from the second run a change report shows what has changed since the previous measurement and which Power BI models that touches.

The brief

Anyone who wants to change a table or field in a warehouse wants to know beforehand which ETL logic, models and reports hang on it; anyone building a report wants to know where a figure comes from and what logic sits on it. That answer is spread across procedure code, views and Power BI, and Microsoft Purview serves the question only as a heavy enterprise platform. Cataloom takes the connections from the code itself, so the AI only puts them into words and invents no evidence.

What I built

  • A read-only collection layer for SQL Server and Azure SQL: live through a login with db_datareader and VIEW DEFINITION, or without a connection through a readable PowerShell script that only runs SELECT statements on the system catalogue and writes a zip
  • Deterministic lineage from the T-SQL with sqlglot: which views and procedures read a table and which procedures write to it, supplemented with declared foreign keys and join mining from the same code
  • A Power BI layer through the Scanner API: per semantic model which table or view it reads, with an explicit match strength between server and database name, and the chain object, model, report in the same lineage viewer
  • An audit registry with deterministic checks on the SQL side and four on the Power BI link, such as a model that reads an object that no longer exists or reads straight from the staging layer
  • A change report per run based on content hashes (new, changed, renamed, gone) with the Power BI models a vanished source touches, and a cache per AI outcome so that a repeat run costs next to no model calls
  • An optional AI layer with a bring-your-own Azure OpenAI key, which writes a business description per object and produces a compact context file for LLM sessions; without AI, lineage, audit and change report work in full

In detail

  • Provenance and impact in one chain: from source table through views and procedures to Power BI model and report, as far as the link can be shown; a link that is only established at database level is not shown as a table relation
  • Links from code, not from a language model: lineage and relations are mined deterministically, and the language model only writes the descriptions
  • Ongoing rather than a snapshot: every run compares against the previous one, and on a real database the second run cost 1 fresh model call instead of 109
  • Read-only, with the data flows named per route: the language model gets schema and code, and on a live connection a few aggregated signals (counts, date ranges, status values), never whole rows. In your own environment the AI steps go to your own Azure OpenAI resource; for the free audit the metadata comes to me, through the script's zip or through a read-only login

Outcome

Live since August 2026 at cataloom.io: a Dutch-first product site with a click-through demo of the actual report on the public WideWorldImporters sample database, and a free audit on one database as the entry point. At one organisation the Power BI layer showed that 107 semantic models and 156 reports hung on a single database, and that thirteen models read an object that no longer existed. The code is covered by a pytest suite of over 1,800 tests. Lineage works at object level today: provenance per field and a task-oriented impact view are the next step, alongside market validation, since there is no paying customer yet.

Back to the work