TL;DR. On August 18, Google Cloud published a working Governance Agent that propagates column descriptions, business glossary mappings, policy tags, and data quality trust scores downstream through BigQuery's column-level lineage. It is a free, open-source demonstration built on Knowledge Catalog, not a GA product, and the fine print matters: the column-level lineage API it depends on still requires allowlisting. But the direction is unambiguous. Automated enrichment through lineage is exactly the capability standalone catalog vendors sell as "active metadata", and the warehouse vendor just showed it as a lab project on top of free platform APIs. The deeper shift is epistemic: propagated metadata is a third kind of catalog entry, derived from other metadata rather than from systems or people, and it makes provenance labels, confidence thresholds, and review workflow the load-bearing parts of governance rather than the tagging itself.
On August 18, 2026, Google Cloud published a blog post titled "Governance on Autopilot" describing a Governance Agent that watches BigQuery through Knowledge Catalog and pushes governance metadata downstream through column-level lineage. Document transactions.customer_id once, and every view that joins, filters, or reshapes it can inherit a description, a policy tag, and a trust score without a steward touching it. The problem it targets is real and quantified by anyone who has run a catalog: a documented gold table feeds forty downstream views, and the documentation stops at the first join. Governance metadata has always been written at one node of the graph and consumed at all of them.
Two things make this more than another vendor blog post. First, the code is public: an open-source project in Google's dataplex-labs repository that anyone with a BigQuery estate can run today. Second, what it automates is not some adjacent convenience. Lineage-driven metadata enrichment is the specific capability the standalone catalog category has been selling under the name "active metadata". When the warehouse vendor demonstrates it as a free lab project on its own platform APIs, the standalone version stops being a differentiator and starts being a baseline.
What the agent actually does
The mechanics reward a close read, because the design is more careful than the "autopilot" headline suggests.
Description propagation is transformation-aware. When a downstream column is a straight pull of an upstream one, the agent inherits the upstream description. When the SQL applies a SUM, a CASE WHEN, or a COALESCE, it reads the transformation and rewrites the description to say what the column now is, rather than copying a label that is no longer true. Glossary mapping works by semantic similarity against a controlled business glossary, and it can ground itself in unstructured documents: feed it the PDF or markdown spec where a term is actually defined, and it maps columns to definitions instead of guessing from column names.
Policy tags, the piece with compliance consequences, get the most conservative treatment. The agent only proposes a sensitivity tag where the source is explicitly marked, it distinguishes a sensitive value passing through unchanged from one that has been aggregated away, and it does not infer PII from column names at all. Trust scores are derived from upstream data quality and profiling results already in Knowledge Catalog, with credit given when a transformation demonstrably improves quality, deduplication or null handling, so a cleaned view can score above its messy source.
Everything runs through two signals of very different standing. The primary signal is the Data Lineage API: recorded pipeline jobs, explicit SQL, high confidence. The secondary signal is Gemini-driven inference from Knowledge Catalog's documentation insights, filling gaps where no clean lineage trail exists. The project tags every propagated entry with which signal produced it, applies a confidence threshold before anything is written, and routes low-confidence cases to an explicit "I don't know" rather than a guess. Stewards get a preview-and-approve dashboard; platform teams get a CLI (scan, apply, policy-propagate) that slots into nightly jobs or CI.
The fine print
Now the caveats, because coverage of this release has mostly skipped them.
This is a demonstration, not a product. The repository says so directly: it is "only a demonstration and is not part of official product", with an instruction to review everything before using it in your environment. It is a Python project you deploy yourself, not a checkbox in the BigQuery console. And the dependency chain has a gate in it: the column-level lineage API it builds on is a preview feature that, per the project's own requirements, needs allowlisting through your Google Cloud account team. The one customer number in the post, an estimated 75 percent reduction in cataloguing effort from VodafoneThree's datahub team, is a company estimate quoted by Google, not an independent measurement.
None of that undercuts the significance; it locates it. Google did not ship active metadata as a product this week. Google showed that the ingredients, column-level lineage, a metadata store, and a language model, are all sitting in the platform already, and that wiring them into automated governance is a lab project rather than a company. That demonstration does its damage to the category regardless of whether this particular repo ever graduates to GA.
A third kind of metadata
Catalog entries have historically come in two kinds. Derived metadata is computed from systems: schemas, lineage edges, profiling stats. Doubt it, and you can recompute it. Declared metadata is written by people: descriptions, ownership, glossary definitions. Doubt it, and you can ask the person. When we examined OpenMetadata's rebrand to a context layer, the trust question was about a third kind arriving from the agent-memory side: testimony written by agents at runtime. The Governance Agent mints a different third kind: metadata derived from other metadata.
A propagated description is not an observation of the downstream column. It is an inference: this column descends from that one, the transformation preserves meaning, therefore the description transfers. Every hop in the lineage chain adds an assumption, and the project's own limitations section names where the assumptions fail, renamed columns and unusual joins. A propagated trust score is stranger still: a number derived from upstream quality checks, inherited through transformations the checks never saw. If the upstream description is wrong, propagation replicates the error across the estate at machine speed, with each copy carrying the confident tone of documentation. Manual cataloguing never had this failure mode. It had gaps, which are visible; propagation has wrong entries, which are not.
There is also a staleness problem, and it is structural. A propagated entry is true about the moment of propagation. When the upstream description is corrected, or the pipeline SQL changes, every downstream copy is stale until a re-scan notices, and nothing about the copy says so. We keep meeting this shape of problem: an approval that was valid at evaluation time and stale by commit time, a memory that was true when written. The general rule is that any claim detached from its source needs an expiry mechanism, and metadata that writes itself needs one most of all.
Propagated metadata is an inference chained through lineage. The provenance label, from recorded lineage or from AI inference, is the only thing telling a consumer which claims to trust.
To its credit, the project treats this seriously. The from-lineage versus inferred label on every entry, the confidence gate, the preference for "I don't know", and the human preview are precisely the right controls. But notice what that concedes: the hard part of automated governance is not generating the metadata. It is the provenance and review machinery around it. When we read the Apache Ossie semantic-layer spec, the conclusion was that definitions travel and trust does not. Propagation is the same gap in motion. The description travels down the lineage graph; whether the trust should travel with it is exactly the question the confidence threshold is quietly deciding on every hop.
What this leaves for catalogs
The standalone catalog vendors, Atlan, DataHub, Secoda, Collibra, have spent the last several years converging on active metadata as the pitch: the catalog is not a wiki, it is automation that keeps metadata current. Atlan's own flagship guide now subtitles active metadata as the "context layer for AI". That framing was defensible while the warehouse vendors treated metadata as a static sidecar. It is much less defensible when the warehouse ships column-level lineage natively, wires Gemini into the catalog it bundles, and publishes the propagation logic as open source.
What a warehouse-native agent cannot do is also visible in the repo's requirements list: it sees one estate. The propagation runs on BigQuery lineage; the moment meaning crosses into Postgres, Snowflake, a SaaS app, or a spreadsheet, the autopilot ends. Cross-engine lineage, connectors, and a neutral home for definitions remain the standalone catalog's ground. So does everything downstream of description: verification workflow, policy enforcement, and being the place where a human accountable for the data says "this is correct", which no confidence threshold replaces.
But that is a narrower moat than "we keep your metadata fresh", and the timing is uncomfortable. The category is simultaneously renaming itself toward AI, because agents are becoming the highest-volume consumers of metadata, and agents raise the stakes on exactly the weakness propagation introduces. A human steward reading a propagated description might notice it smells wrong. An agent planning a query against it will not. An agent-facing metadata layer has to answer not just "what does this column mean" but "who says so, derived how, verified when", the distinction between derived context and testimony that a unified graph erases by default. Auto-generated, auto-propagated entries make that provenance question more urgent, not less, precisely because they scale the volume of plausible-looking claims.
The honest read on Google's project is that it commoditizes the generation of governance metadata while demonstrating, in its own architecture, that generation was never the valuable part. The value concentrated where the project put its safety rails: knowing where each claim came from, how much to trust it, and when it stopped being true.
Where Datapace sits
Datapace's framing for this territory is that catalogs describe and Datapace governs, and this release sharpens rather than threatens it. Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, kept distinct from what was merely inferred, with the workload evidence beside it (cost, performance, usage and freshness, lineage) and a policy gate over what an agent may do and access, served over MCP. Propagation of the kind Google demonstrated is a natural producer of inferred entries in such a graph; the layer that tracks which entries were validated, by whom, and whether they still hold is the part no autopilot supplies. If you are deciding what your agents should be allowed to believe about your data, book a call.
Sources
- Google Cloud, "Governance on Autopilot: Automate Data Governance with Lineage", August 18, 2026.
- GoogleCloudPlatform, dataplex-labs, governance-agent project (README, requirements, CLI reference, demonstration disclaimer).
- Google Cloud, Knowledge Catalog product page (formerly Dataplex).
- Atlan, "Active Metadata: The Complete 2026 Guide".