No-Code Automation for Metadata Enrichment: How Modern Catalogs Stay Current at Scale

Most enterprise data catalogs run from tens of thousands to hundreds of thousands of tables. Manual documentation at that scale isn’t a process problem. It’s a math problem.

This is different from sales contact data enrichment, which fills in records like phone numbers and job titles. It’s also different from generic workflow automation that moves tasks between apps, and from data integration tools that move records between systems. Catalog metadata enrichment is specifically about descriptions, classifications, ownership, lineage links that map data flow between assets, and governance terms: the metadata that determines whether a data asset is discoverable, trustworthy, and usable.

Three automation surfaces work together to make this possible:

• Generation: AI writes initial documentation for tables and columns
  
• Propagation: Descriptions and classification labels flow along lineage to related assets
  
• Sync: Governed metadata moves both ways between the catalog and the platforms where data actually lives
  

DataHub Cloud automates metadata enrichment through AI-generated documentation, lineage-based propagation, and two-way platform sync, a combination that reduces manual documentation effort and keeps catalogs current at enterprise scale.

Why manual metadata broke

The economics never worked.

A single mid-sized analytics warehouse can hold 50,000 tables. Multiply that by columns, and the documentation surface area runs into the millions. The data team responsible for keeping all of that current is doing it alongside pipeline work, governance reviews, quality investigations, and whatever new requests came in this week. Documentation is the task that loses by default.

The visible result is half-empty catalogs

Tables exist. Schemas are ingested. But the descriptions that would tell an analyst what the data means, where it came from, and whether it’s trustworthy are missing or stale. Search returns results that look right and aren’t. Consumers spend the first 10 minutes of every analysis verifying basic facts about the data they’re using.

The less visible result is what happens downstream

• An analyst sees three tables with similar names and picks the wrong one
  
• The dashboard built on top of it produces a number that’s plausible enough to pass review but wrong enough to drive a misallocated budget
  
• A model trained on a stale dataset performs worse in production than in testing, and the team spends two weeks tracing the regression before realizing the upstream source had been deprecated
  

The cost of bad metadata isn’t paid by the data team that didn’t document it. It’s paid by every consumer who trusted the catalog and shouldn’t have. Data accuracy is only as reliable as the metadata that describes it.

This was already a problem before AI agents started consuming catalog metadata directly. Now the cost has gone up. An analyst looking at a half-empty catalog can ask a colleague which column to use. An agent generating SQL from a question can’t. AI-ready metadata is the top context management priority for 2026, cited by 62% of data teams in the State of Context Management Report. The reason is straightforward. Missing documentation used to be inconvenient. With agents in the picture, it’s the difference between an answer and a hallucination.

What “no-code” doesn’t mean

The failure mode for automated enrichment is more subtle than catalog teams expect.

It’s not that the system doesn’t generate descriptions. It’s that the descriptions are generic enough to be useless. A table called orders_fact gets documented as “a fact table containing order data,” which says nothing a reasonably curious analyst couldn’t infer from the name. The catalog fills up. The signal-to-noise ratio drops. And consumers learn to ignore the descriptions because they’ve been burned too many times by the ones that don’t add anything.

What separates useful automation from spam is what the system has access to when it generates output. Description quality is a function of context, not model capability. An automation that sees only a table schema produces generic descriptions. An automation that also sees the lineage relationships, the metadata of related assets, sample values where appropriate, and any existing documentation can produce something useful.

The difference is concrete. Take a column called customer_ltv_usd. A schema-only automation might describe it as “the customer’s lifetime value in US dollars,” which restates the column name. A context-aware automation has access to the upstream transformation that produces the column, the documentation of the source tables it pulls from, and the glossary term defining how the company calculates lifetime value. It can produce something like “Estimated 36-month gross revenue per customer, calculated from order history and adjusted for projected churn. Pulled from dim_customer and refreshed nightly.” That’s a description an analyst, or an agent, can actually use.

Governance is the other half. No-code in this context doesn’t mean ungoverned. The automations route through review and approval workflows. Custom instructions configured by the data team control terminology, tone, and output standards so that generated descriptions match organizational conventions and read like they came from the team that owns the asset. Humans stay in the loop for the assets where precision matters, while the system handles the long tail without forcing anyone to document a table nobody’s queried in six months.

When automation is anchored properly, the outcomes show up in the catalog. Organizations running DataHub Cloud report 153% more data assets with complete metadata, 254% more data assets with assigned data owners, 75% more data sets with mapped lineage, and 42% fewer data quality issues overall, according to IDC’s Business Value Study. The math problem becomes tractable when the automation produces signal instead of noise.

The three surfaces of automated enrichment

Automated enrichment isn’t one feature. It’s a coordinated set of automations operating across the metadata lifecycle.

1. AI-generated documentation

The starting surface. AI documentation generates table and column descriptions using a combination of lineage context, sample values, related metadata, and any existing documentation. Custom instructions let teams enforce terminology and tone, so the descriptions read like they came from the data team that owns the asset rather than from a generic model.

The generation step doesn’t replace human curation. It produces a starting point. Reviewers approve, edit, or reject. For lower-tier assets, the starting point is often the ending point, which is the right outcome for a table that gets queried twice a quarter. For tier 1 assets, the AI-generated description is the first draft that subject matter experts then refine.

2. Documentation and glossary term propagation

Generation handles individual assets. Propagation handles relationships.

When a column is documented in one table, that documentation is often relevant to columns in other tables that descend from it through transformations or share lineage relationships. Manual propagation means re-documenting the same logical concept across every table it appears in. Automated propagation means the documentation flows along column-level lineage and sibling relationships, with the option to backfill across existing assets so the entire historical estate stays consistent.

Glossary term propagation works the same way for classification labels. A column tagged “PII” in one table inherits that classification across the lineage graph, which keeps governance consistent without requiring stewards to manually tag every downstream copy. The mechanics are the same. The payload is different.

For a deeper walkthrough of how AI-generated documentation and propagation work together, see our piece on AI-generated documentation and context propagation.

3. Platform metadata sync

This is where automation closes the loop.

Generation and propagation populate the catalog with rich metadata. Platform metadata sync makes that metadata operational by moving it both ways between the catalog and the systems where data actually lives:

• A tag applied in the catalog reaches the engine
  
• A description written in the catalog appears in the warehouse query interface
  
• A schema change made in the platform flows back into the catalog
  

The catalog stops being a separate place that data teams visit and starts being the control plane for metadata across the data estate.

While DataHub ingests metadata from 100+ connectors across the data estate, two-way platform metadata sync automations are currently available for BigQuery, Google Cloud Knowledge Catalog, Databricks, and Snowflake. Each connector handles a slightly different surface:

• BigQuery sync pushes descriptions and labels back to the warehouse
  
• Snowflake propagates tags through the warehouse’s native classification system
  
• Databricks sync aligns Unity Catalog metadata with what governance teams maintain centrally
  
• Google Cloud Knowledge Catalog sync mirrors metadata into Google’s enterprise catalog layer
  

Two-way sync matters operationally for two reasons:

• First, policy decisions made centrally need to actually reach enforcement points. A column classified as “PII” in the catalog is governance noise unless that classification reaches the systems that grant access. With sync, the classification reaches the platforms where enforcement is configured.
  
• Second, platform-side metadata changes need to flow back into the catalog so the catalog reflects ground truth. A schema change in Snowflake, an updated description in BigQuery, a new tag applied directly in Databricks: all of it surfaces in the catalog automatically, which keeps the catalog from drifting out of alignment with reality.
  

A practical example. A compliance team maintains a “regulated” classification in the catalog, applied across columns containing personally identifiable information.

• Without sync, that classification is a label that lives in one system and is enforced in another, often by an engineer translating the policy into platform-specific rules
  
• With sync, the classification propagates to Snowflake’s tag system and Databricks’ Unity Catalog, where access policies are already configured to respect those tags. A new column added to a regulated table inherits the classification through propagation, and the classification reaches the platform through sync. The compliance team configures policy once. The classification then reaches each platform through sync, where the access policies already configured there apply it across multiple systems that read from the tagged tables.
  

The result is a metadata layer that doesn’t sit alongside the data platforms but operates through them. Documentation written once shows up everywhere it’s useful. Classifications applied centrally enforce locally. The catalog becomes the place metadata is curated and the platform layer becomes where it’s consumed and applied.

The tier-based pattern: where to automate, where to curate

The argument for automation has a corollary that often gets dropped: not every asset deserves the same treatment.

A common failure mode is treating all assets as equal candidates for either full curation or full automation. Full curation doesn’t scale, and full automation produces undifferentiated output. The teams who get this right tier their assets by criticality and apply different documentation standards to each tier.

Pinterest is the clearest published example. Their data team spent years reducing their warehouse from roughly 400,000 tables down to about 100,000, then layered a tiering program on top that classified every remaining table by trust level. Tier 1 covered cross-team production assets with strict documentation requirements and human-in-the-loop validation. Lower tiers had lighter standards and rode automation with sampling-based oversight. They propagated business glossary terms across more than 40% of their columns using join-based lineage, and cut manual documentation work by roughly 70% using AI-generated descriptions held in place by human review on tier 1 assets.

This pattern works because it matches investment to value. Most assets in any catalog are queried infrequently, by a small number of consumers, for one-off analyses. Automation handles them well enough. A small subset of assets are queried constantly, by many consumers, for decisions that matter. Those deserve the curation budget.

Operationally, tier 1 review doesn’t have to mean every change goes through committee. The pattern that works at scale is targeted intervention. Automation produces the first draft. The data steward or domain owner is notified through their existing tools, with automated workflows handling the routing. They edit or approve. The asset’s tier is what determines whether the review step is required or optional, not whether the automation runs at all. Automation runs everywhere. Review concentrates where it matters.

The implementation pattern is straightforward. Define tiers based on usage, criticality, or domain ownership. Apply automation broadly. Set review thresholds for each tier so tier 1 assets always pass through human review while lower tiers pass through automatically. Use the time you save on long-tail documentation to invest in the documentation that actually decides analytical outcomes.

Why this matters for AI agents

The teams automating enrichment now are building the infrastructure their AI workflows will depend on later.

This isn’t a forward-looking claim. It’s already happening. Pinterest‘s analytics agent runs on the metadata foundation that their tiering and automation work produced. Within two months of launch, the agent covered 40% of their analyst population and became the most-used internal tool at the company, with 10x the usage of the next most-used internal agent. The agent works because the catalog underneath it is enriched, governed, and current.

The pattern reverses if you don’t have that foundation. Without enriched metadata, agents return generic answers, hallucinate joins, or produce SQL that runs against the wrong table. The constraint isn’t model quality. It’s whether the system has access to the context required to answer well. Catalog enrichment is what produces that context. Automation is what makes catalog enrichment scalable.

The teams that started this work before agents were on the roadmap are now the ones deploying agents successfully. For everyone else, the metadata work comes first. The roadmap doesn’t get a vote.

The work doesn’t have to wait for an agent rollout to be valuable. The catalog gets better immediately. Discovery improves. Governance becomes consistent. Downstream consumers get descriptions they can trust. The agent readiness comes along for the ride.

FAQs