Catalog, discovery, observability, governance

Data catalog, data discovery, data observability, data governance. I hear all four most days, usually used as though they’re interchangeable, which they aren’t. Every time it happens I think of the line from The Princess Bride about words not meaning what the speaker thinks they mean.

I have two young kids, so the version that finally stuck for me involves toys.

Catalog is the list of every toy in the house, so my wife knows what we have and roughly where it lives.

Discovery is actually finding one so a kid can play with it.

Observability is knowing whether it still works. If it’s broken, Dad fixes it.

Governance is the rules about who plays with what and how it gets put away. Mom sets those rules. Not Dad.

Metadata is the tag on the toy telling you the name, the brand, and when it was made.

The reason a catalog exists at all is to make discovery cheap. People need to know where data lives, how to get to it, and how to connect to it before they can explore anything.

Picture an analyst starting a new dashboard or a data scientist starting a model. They need the right dataset. Meanwhile the data is moving through layers of transformation, new datasets keep appearing, and dependencies keep multiplying. One upstream change breaks pipelines, dashboards, and reports nobody remembered were connected.

Better discovery isn’t only about helping people find things. It’s what makes governing and categorizing possible at all.

What actually worked

The tempting answer is to track sources by hand, update the catalog manually, and email the company when something changes. That lasts about two weeks.

Here’s what worked instead.

Figure out who owns what downstream. This is the hard part and there’s no tool that does it for you. You have to go ask.

Automate the notification. Schema change alerts go into a dedicated Slack channel. Airflow orchestrates it, and any schema or transformation change made through dbt, wired to the repo, fires a message naming the models that are new, updated, or deleted.

Gate the merge. Downstream owners have to approve before a change can land on the main branch. That single control stops more breakage than the alerting does, because an alert tells you something already happened and an approval stops it happening.

Broken pipelines and dashboards dropped substantially. Tools like DataHub take this further, making discovery something business and technical users can both do, and surfacing downstream dependencies so engineers can warn the affected teams before the change ships rather than after.

---

What changed in 2026

I wrote the above for an audience of humans. An analyst looking for a table, a data engineer trying not to break someone’s dashboard, a stakeholder wondering where a number came from. The catalog served people, and the cost of bad governance was measured in broken dashboards and annoyed colleagues.

That calculation changed when the thing querying the warehouse stopped being a person.

A human hitting an undocumented table with an ambiguous column name at least has the chance to hesitate. Not always taken, as anyone who’s watched a wrong table get wired into a dashboard knows. But the pause exists, and someone occasionally asks. That hesitation is a quality control we never designed and never valued, and it was doing more work than we credited.

A model doesn’t hesitate. Point one at ungoverned data and it will join the wrong table to the wrong table and hand back a confident, well-formatted, entirely plausible answer. Nobody catches it, because a wrong answer and a right answer look identical. There’s no broken dashboard to notice.

So the four words above stopped being vocabulary hygiene and became load bearing.

Catalog is no longer a directory people browse. It’s the context the model needs to know that this table is the one finance uses and that one is a deprecated copy.

Discovery matters less as a human workflow and more as a retrieval problem. The question is no longer whether a person can find the right dataset, it’s whether the system surfaces it and not the four things next to it.

Observability has to extend to the answers, not just the pipelines. Knowing your job ran is table stakes. Knowing whether what the system told someone was correct is a different discipline, and most data teams haven’t built it yet.

Governance turned into the thing that decides whether any of it works. Not the compliance chapter at the end. The prerequisite.

The practical shape of that: put the investment in the unglamorous end first. Governed, trustworthy data, with business context attached so the system has more than schemas to reason about. Then evaluations on what it actually says back, reviewed, fed in, so the loop tightens instead of drifting. Without that you have a demo. With it you have something people will act on without re-checking, which frees the analysts for work that needs a human.

The metaphor still holds, unfortunately. The toys are catalogued and the rules are on the wall. The difference is that something in the house now plays with all of them at once, very fast, and never asks whether it’s allowed.