What a Data Catalog Entry Actually Contains

A catalog entry is a layered record, not a simple index card.

The old library card catalog is a useful starting point, because it shows how far the bar has moved. A card held a title, an author, and a Dewey Decimal number. Enterprise data asks questions a card was never built to answer: who owns this, can it be trusted today, is access permitted, is it actually correct.

The W3C's Data Catalog Vocabulary, version 3, published 22 August 2024, defines a catalog as "a curated collection of metadata about resources." Two words in that sentence carry the weight. Curated means someone chose what goes in and keeps it accurate. Metadata about resources means the catalog holds descriptions of assets, never the assets themselves. A catalog entry is a claim about a piece of data, and like any claim, it can be thin or it can be substantiated.

That distinction is the whole argument of this piece. A catalog with no one tending the metadata underneath it behaves like a wiki page written on launch day and never touched again. The common failure isn't a catalog missing tables; it's a catalog full of entries that carry structure and nothing else, connected to hundreds of sources, serving almost no one, because the entries behind those connections carry no meaning, no ownership, and no signal anyone can trust.

What metadata a catalog entry holds, organized as five distinct strata

Catalog metadata isn't one thing. It spans five distinct layers, each doing a different job for discovery, governance, and trust, and each one fails in its own particular way when it's missing.

Technical metadata covers table names, schemas, column definitions, data types, and the structural relationships between them. It's what lets a system track lineage, compare schemas, and run impact analysis when something upstream changes.

Business metadata covers definitions, descriptions, domain ownership, steward assignments, and usage guidance.

Operational metadata covers refresh frequency, last-update timestamps, usage patterns, query statistics, and performance indicators. It tells a user whether an asset is current and whether it's actually being relied on.

Governance metadata covers sensitivity classifications, access restrictions, retention rules, and compliance indicators. It embeds risk and policy directly into the record.

Quality metadata covers accuracy, completeness, timeliness, and consistency metrics, along with validation rules and anomaly detection results. It answers the question none of the other four strata can: is this specific asset fit for this specific use, right now.

These five layers depend on each other. Each of the next five sections takes one stratum and shows what it holds, why it exists, and what breaks when it's absent.

Technical metadata: the structural skeleton every entry starts with

Technical metadata is the floor every entry is built on. It tells a system what an asset is and where it lives, which is necessary information, but by itself it says nothing about whether anyone should use the asset or what it's for.

It includes table names, schemas, column definitions, data types, and the relationships that connect assets to each other. Without technical metadata, engineers lose the ability to safely modify a pipeline or trace a data issue to its root, and that failure appears immediately in a broken report or a pipeline nobody can diagnose.

Technical metadata is also the stratum automated tools handle best. That makes the technical layer easier to fill than any other. It does not make the other four layers any less necessary.

Business metadata: where technical structure becomes human meaning

Automated harvesting fills schemas fast. It does not fill in what those schemas mean, and that gap is where most catalogs quietly fail.

Business metadata holds the definitions and descriptions that turn a technical name into something usable: domain ownership and steward assignments that say who's accountable for an asset's accuracy, usage guidance that says how an asset should and shouldn't be used, and glossary links that tie a term like "Customer Lifetime Value" to one shared definition across every team that touches it.

Take a column named "acct_st." A technical entry reports it as a string field with a handful of possible values. Nothing in that record tells an analyst what the field represents, who maintains it, or whether it's safe to build a report on. Now give that same column a business entry: "Customer Account Status," owned by the finance team, with a note on which downstream reports depend on it. The underlying data hasn't changed. What changed is whether a person outside the team that built it can use it correctly on the first try.

This is where metrics like "churn rate" or "active customer" quietly diverge across an organization. Business metadata is the fix, and it's also the stratum that resists automation hardest: no connector can write a definition or assign an owner. Someone has to do that work and keep doing it; social catalog features like tagging, comments, and popularity indicators exist for this reason. They're a workaround for knowledge that otherwise lives in a handful of people's heads and disappears the day those people leave.

Operational metadata: the freshness and usage signals that tell you whether to trust an asset today

Business metadata answers what an asset means. Operational metadata answers a separate question: is it alive right now.

Freshness requirements aren't fixed, they depend entirely on the use case. A table refreshed nightly is perfectly fine for a weekly business review and already too stale for an agent making a decision in real time. Operational metadata is what makes that distinction visible in the entry itself, instead of something a user has to find out by asking around.

Usage statistics do double duty here. The real danger of missing operational metadata is quieter than a deprecated table still in heavy use: an asset that was reliable two years ago and has since been abandoned looks, on the page, exactly like one being actively maintained. Someone finds out the difference only after they've already built something on the wrong one.

Governance metadata: the stratum where policy and permission live inside the asset record

Governance metadata is what makes a catalog function as a control point. Without it, an entry describes an asset and does nothing to govern who can reach it or what they're allowed to do once they do.

This layer carries sensitivity classifications that flag PII, confidential data, or anything subject to GDPR, HIPAA, or CCPA. It carries retention rules dictating how long data should be kept and what triggers its removal, and compliance indicators tying the asset to the regulatory frameworks that govern it.

A marketing analyst pulling customer records should see immediately, right there in the entry, that a field is classified as sensitive and restricted from external sharing. Policy embedded directly in the record a user is already looking at does.

There's a sharper version of this problem: sensitivity isn't always a property of a single field. A table with no PII on its own can become sensitive the instant it's joined to another table, and a governance stratum that only evaluates fields in isolation misses that combinatorial risk. Google Cloud's Knowledge Catalog shows one approach to making governance operational rather than theoretical: its data products support configuring a default IAM role across an access group, automatically applied to every packaged asset with the option to override it for individual assets, and as of September 24, 2026 the assets table shows the permission state of each one as Applied, Failed, or Unsupported. Business glossaries, classification rules, and policy frameworks are usually managed in separate systems from technical metadata. Bringing them into the same record, tagged with regulatory requirements and sensitivity classifications, is what lets compliance become part of everyday work instead of a separate review step bolted on afterward.

Quality metadata: the signals that tell a consumer whether the asset is fit for their specific use

An asset can be structurally sound, clearly described, operationally current, and properly governed, and still be unfit for the job if nobody has measured whether it's actually correct. Quality metadata closes that last gap.

Every asset a catalog holds should carry a quality score, an access policy, a sensitivity tag, and compliance context before any AI system is allowed near it. Quality metadata is a precondition for safe use, not a report generated after the fact. It also changes how the governance layer reads: a sensitivity classification on a low-quality asset isn't one risk, it's two stacked on top of each other, sensitive and unreliable at once, a combination governance metadata alone has no way to flag. Knowledge Catalog's dbt metadata import, generally available as of September 24, 2026, pulls data quality metadata from dbt Core artifacts alongside technical, semantic, operational, and lineage metadata, which shows where this is heading: quality signals increasingly come from pipeline tooling automatically.

That automation doesn't make the stratum easier to maintain. Quality metadata demands continuous measurement against the live data, not just a description of it written once. A quality score calculated six months ago and never refreshed is worse than having no score at all, because it hands a user false confidence instead of an honest gap.

Why the five strata together change what AI systems can do with enterprise data

An entry that carries all five strata is the interface an AI agent uses to find, understand, and act on enterprise data without a person checking its work at every step.

Consider that "acct_st" column again, this time from an agent's perspective. Agents query at a volume and speed no human review process can keep up with, so permissions and quality checks have to be enforced inside the catalog entry itself, not applied as a downstream check after the data's already been pulled.

There's a semantic piece sitting on top of all five strata that matters just as much. The catalog entry establishes what data exists and who's responsible for it. A semantic layer built above that entry defines how a metric like revenue or MRR gets calculated, the same way, every time it's calculated. Knowledge Catalog's dbt metadata import brings technical, semantic (via MetricFlow), operational, quality, and lineage metadata together from dbt Core artifacts into one record, a concrete case of all five strata being sourced and maintained together.

Most commercial catalog vendors now ship a first-party MCP, or Model Context Protocol, server, so connecting an agent to a catalog is no longer the hard part. The real differentiator is whether the entries on the other end of that connection are rich enough to give the agent a usable answer, rather than a pile of metadata it has to sort through on its own. Depth beats breadth, and the five strata are what depth actually consists of.

What a weak entry looks like in practice

The most common failure in a real catalog is entries that exist with only the technical stratum filled in, giving an organization the confidence of a complete inventory without any of the trust that makes an inventory worth having.

Automated harvesting is fast enough to create that illusion on its own. Schemas appear, tables get counted, and a project gets declared finished before any business, operational, governance, or quality metadata has been added to a single entry. The fix is assigning the job of saying what each asset means to an actual person, and then measuring documented assets.

A sequencing problem underneath this is that budget cycles rarely account for work that pays off only much later. Building catalog depth is an investment that pays off months or years after it's made, and organizations under pressure to show AI results quickly tend to skip the enrichment work that would have made those results trustworthy. Governance in particular needs someone to make a policy decision, not just transcribe one that already exists elsewhere, and classification, retention, and access rules all need owners the same way business descriptions do. Those owners are usually the people with the least spare time in the organization. This gap tends to persist long after the technical layer looks finished.

How to read an entry's stratum coverage as a signal of catalog maturity

Stratum coverage is the most direct signal available for what a catalog can safely be used for. An entry with only a technical stratum is fit for schema browsing and nothing more, certainly not for AI consumption or governed data sharing.

Reading coverage this way gives a clear maturity scale. Add governance metadata and access, sensitivity, and compliance become built into the record itself, making the catalog a genuine control point. With all five strata present and actively maintained, an entry is ready for AI: an agent or pipeline can find it, understand it, confirm it's current, verify it's authorized, and check that it clears a quality threshold before it acts on anything.

Track the share of entries carrying all five strata, not the count of connected sources. The real test for any single entry is simple: can an AI agent, or a new analyst with zero prior context, find this asset, understand what it means, confirm it's current, know who owns it, verify they're allowed to use it, and check whether it's accurate enough for the job in front of them? If any one of those questions can't be answered from the entry itself, a stratum is missing, and that gap is becoming a publication gate. The five strata are the conditions a piece of data has to meet before anyone, human or machine, can trust it enough to act on it.