Data Quality and Governance in 2026: Metadata, Lineage and Quality Operations

Data Quality and Governance in 2026: Metadata, Lineage and Quality Operations

A review of documented changes from July to September 2026 in tools available to U.S. data teams

Data governance is often described through durable principles: know what a data asset means, assign a responsible owner, test whether it is fit for use, understand where it came from, and resolve problems before they spread. Recent product changes make those responsibilities more visible in day-to-day work. They connect more kinds of metadata, show quality failures as incidents, and make access decisions easier to track. They also expose limits that a governance team must check before it relies on automation.

This review uses dated primary releases from 2 July through 29 September 2026. The releases describe capabilities offered by Google Cloud, Snowflake, Databricks and Microsoft, plus one narrowly applicable U.S. public-sector example. They do not measure how many U.S. organizations use those products or which skills employers request. Some capabilities remain in preview or beta, while others require a particular edition or deployment configuration.

Metadata is becoming a connected work record

On 24 September, Google Cloud made its Knowledge Catalog import of dbt metadata generally available. Its release notes describe import paths for dbt Cloud and dbt Core artifacts, including links that associate dbt lineage and semantic relationships with physical BigQuery tables. An earlier 26 August preview brought technical, semantic, operational, data quality and lineage metadata from dbt Core and MetricFlow artifacts into the same catalog. The practical change is that a steward can inspect more of the path between a model definition and a physical data asset. The responsible next step is to verify whether the imported links match the actual pipeline and to record any sources or transformations the connector did not capture. Google Cloud Knowledge Catalog release notes.

Snowflake addressed a different lineage gap on 21 September. Its generally available lineage preservation can retain object-level and column-level connections across a temporary table or view after that intermediate object is dropped, provided it genuinely bridges an upstream source and downstream table. This can improve impact analysis when a pipeline uses short-lived staging objects. It does not mean every transformation is automatically traceable: the documented bridge condition matters, and the feature requires Enterprise Edition or higher. A lineage review still needs to ask where the graph starts, where it ends, and which steps are missing. Snowflake lineage preservation release note.

These are concrete product changes, not evidence that the industry has solved lineage. They point toward a useful operating discipline: connect business meaning, technical definitions and physical data, then test that connection against a real change or incident before trusting it.

Quality rules are moving into incident operations

On 29 July, Snowflake introduced a data quality monitoring dashboard in public preview for Enterprise Edition accounts. It brings together account-level health, monitored-schema coverage and an incident list for volume anomalies, freshness anomalies and failed expectations. It also offers an AI-assisted investigation entry point. A quality team can use that view to see which assets are monitored and which failures need attention. The release does not establish that a suggested root cause is correct, or that an incident has been resolved simply because it appears in one queue. An owner, severity decision, evidence trail, escalation route and closure check remain necessary. Snowflake data quality dashboard release note.

The definition of the tested population matters as much as the alert. In Snowflake's September 10.32 release, a data metric function association gained the ability to change or clear its row filter without dropping and recreating the association. A null-count rule evaluated on active customer records answers a different question from the same rule evaluated on every historical record. Teams should therefore record the rule, its filter, effective date, threshold and owner when interpreting a quality result. The release documents specific command restrictions, so the general lesson is to govern rule changes, not to assume one SQL method works across platforms. Snowflake 10.32 release notes.

There is also a warning against treating vendor-generated analysis as permanent evidence. Databricks announced rolling deprecation, beginning 18 August and 7 September, of the root_cause_analysis and downstream_impact columns in its data quality monitoring results system table. A workflow that depends on those fields needs a replacement way to document cause and downstream effect. Independent lineage inspection, source checks and a named decision maker are more durable than a single generated field. The rollout timing varies by region. Databricks upcoming changes.

Ownership now reaches the access decision

Google Cloud's 24 September release lets an access group in a Knowledge Catalog data product have a default IAM role, with an override for individual supported assets. Its asset table also displays whether a permission is applied, failed or unsupported. That distinction matters: an approved request and a working entitlement are separate events. A data product owner needs to define the normal role, review exceptions, and follow up when the platform reports a failure or unsupported asset. Google Cloud Knowledge Catalog release notes.

Two earlier Google changes show the direction but are not mature defaults. Data domains, introduced on 7 September in preview, can organize enterprise resources for discovery and curation. Governance workflows for data product access request and review arrived in preview on 24 July. A sensible operating model still has to specify who owns a domain, who can approve access, what evidence an approver sees, how an exception is recorded, and who verifies that the resulting permission works. Preview status means a team should test these steps in its own environment before making a service promise. Google Cloud Knowledge Catalog release notes.

Databricks added tag automations in beta on 7 August. Conditions can add or remove governed tags for such signals as certification, deprecation, sensitivity or missing required tags; saving an automation begins with a dry run. This gives governance staff a way to review the proposed asset set before the rule changes metadata. It also creates a new failure mode: a poor condition can classify many assets incorrectly. Tag ownership, allowed values, false-positive review and reversal procedures therefore matter as much as the automation itself. Databricks August 2026 release notes.

Check feasibility before promising one central view

Microsoft clarified in August that Purview Data Quality requires the Purview account and its data sources to be in the same Azure region. A governance plan that assumes one set of scans can cover every regional source may fail before its first rule runs. The constraint is specific to that product capability, not a new general U.S. requirement. Microsoft Purview changes; Purview Data Quality documentation.

The same feasibility check applies elsewhere: Snowflake's lineage preservation and dashboard specify Enterprise Edition, the dashboard is still a public preview, Google's domains and access workflows are previews, and Databricks tag automation is beta. A governance operating model should record the source system, region, edition, supported asset type and maturity of each proposed control before assigning an owner to deliver it.

A narrowly scoped U.S. example shows why provenance semantics may become more demanding. NIST's September update on an HL7 healthcare draft describes both a simple marker that AI was involved in a FHIR record and a more structured provenance mechanism. The guide is a trial-use draft in a specific sector and is expected to change. It illustrates a question that many data teams can understand—what changed a record, and by whom or by what system?—without creating a general legal or technical obligation for all organizations. NIST project update.

What the releases add up to

Across these sources, the supported direction is toward connected metadata, visible monitoring coverage and incidents, and explicit ownership of access and classification decisions. That is an inference from releases, not a measured rate of U.S. adoption. The recurring practical task is to test a chain of accountability: an asset has a defined meaning and owner; its quality rule states which records it checks; an incident has a traceable investigation and decision; lineage supports impact analysis while its gaps remain visible; and an access approval is verified against the permission actually applied.

The product updates make parts of that chain easier to observe. Their preview labels, edition requirements, regional limits and disappearing result fields show why the human operating model remains essential. The strongest governance work in 2026 is therefore neither a static policy document nor blind reliance on a dashboard. It is the repeatable process of defining, checking, escalating and recording decisions about data that people need to use.

Source and scope note

This article independently reviewed dated primary product and public-sector sources published or updated between 2 July and 29 September 2026. It describes changes relevant to U.S. deployments, but its vendor corpus is not a sample of U.S. employers or organizations. It makes no claim about adoption prevalence, job-demand frequency, vendor superiority or universal compliance duties. Product status and availability should be checked again before implementation.

Continue learning

Develop the capabilities discussed in this article through MTF Institute's Professional Certificate in Data Quality & Data Governance. The programme combines structured theory, guided AI practice and reusable workplace artifacts.