Google Knowledge Catalog and the Enterprise Context Layer: Which Layer Is Authoritative for BigQuery

---

Google Cloud Knowledge Catalog is authoritative for what Google Cloud can observe and enforce on your BigQuery estate. An enterprise context layer, the category Atlan builds, is authoritative for what your business agreed. Google renamed the product on April 10, 2026, and according to a16z (2025), 37% of enterprises now run five or more models in production.

Four things changed in 2026. Dataplex Universal Catalog became Knowledge Catalog on April 10, legacy Data Catalog reached its June 1 shutdown date, federated support for third-party Iceberg REST catalogs arrived in Preview, and Google shipped four MCP servers that non-Google agents can call, one of which writes. Together they retire the old question, whether your estate is single-cloud or multi-cloud. What decides now is whose agents are asking, and which layer answers when both systems hold the same definition.

Dimension	Google Cloud Knowledge Catalog	Enterprise context layer
What it is	Google’s Gemini-powered context engine inside Google Cloud	A neutral layer holding the definitions the business agreed
Where it is authoritative	What Google Cloud can observe and enforce	What was agreed, approved, and contracted
What it observes automatically	BigQuery, Looker, Spanner, Cloud Storage, Vertex AI	Systems inside and outside any single cloud
Who it enforces for	Principals and policies inside Google Cloud IAM	Named owners and approvers across the estate
Agent interface	Four MCP servers: Knowledge Catalog remote and local, data lineage remote (Preview) and local	Hosted MCP server (GA), API, SQL
Cost model	DCU-hour metering, Standard and Premium tiers	Platform subscription
Best fit	Context Google Cloud produces about its own assets	One definition resolving identically per agent vendor

---

What is the difference between Google Cloud Knowledge Catalog and an enterprise context layer?

What separates the two is authority, not the amount of ground each covers: an agent has to know which system’s answer counts.

The two are easy to conflate: both hold glossary terms, both hold data products, both ship MCP servers, and both use the word context. Several systems of semantics running at once each behave as the definitive one, which is why the distinction between a data catalog and a context layer decides what an agent receives. What the business agreed is the harder half: an agreement reached in a ticket or a review meeting is business context for AI no query engine observes.

The failure mode is quiet. Two agents on two vendors return two numbers for revenue, neither flagged as wrong, and the one that reaches the board deck is the one that got asked first. Only authority would have settled it.

---

What does Google Cloud Knowledge Catalog do on BigQuery today?

Google Cloud Knowledge Catalog is Google’s context engine for a Google Cloud estate, and on BigQuery it reads your tables, views, and query history continuously rather than on request.

Dataplex Universal Catalog has been called Google Knowledge Catalog since April 10, 2026. Google’s own wording is that “the API, client library, CLI, and Identity and Access Management (IAM) names remain unchanged,” and the endpoint is still dataplex.googleapis.com, per Google Cloud’s Knowledge Catalog overview. Say “Google” on first mention: IBM shipped a product called Knowledge Catalog until May 2025, and IBM’s docs still carry the name in places. Its deprecation notice gives legacy Data Catalog, and the Business Glossary on it, a shutdown date of June 1, 2026. Treat that as the start of the move rather than a clean cliff: Google still publishes a two-phase transition guide, a preparatory phase that exposes Data Catalog custom metadata in Knowledge Catalog read-only while “Data Catalog remains the authoritative source,” then an upgrade phase that moves read-write state across (as of September 15, 2026).

Google calls it “an always-on context engine” unifying structured, unstructured, and SaaS data into agent-ready truth, and it ingests automatically from BigQuery, Dataform, Iceberg REST Catalog tables, Vertex AI, Spanner, and Cloud Storage. Looker belongs in a different column: Google’s metadata overview lists Looker (Google Cloud core) instances, dashboards, dashboard elements, Looks, LookML projects, models, Explores, and views as Preview, not general availability, so a BI estate is not yet covered on GA terms (as of September 15, 2026). Gemini Enterprise, previously Google Agentspace, consumes the result directly.

William Anderson, CTO of Bloomberg Media, in Google’s launch post: “By unifying Bloomberg Media’s enterprise metadata and business context through the Knowledge Catalog, we successfully launched our Data Access AI Agent.”

What Knowledge Catalog does natively on Google Cloud

• Business glossary (GA). Terms, definitions, and term-to-column links.
• Data products (GA). BigQuery tables, views, and storage in a semantic wrapper.
• Quality and profiling scans. Column-level results, policy checks, anomaly detection.
• IAM and policy tags. Enforcement where the data physically sits.
• Gemini-derived descriptions. Generated from metadata Google Cloud already holds.
• Semantic search. A hybrid semantic search implementation combining semantic matching, keywords, and structured predicates, alongside the lineage an AI agent needs for Google Cloud jobs. Google’s product page markets it at “sub-second latency,” a vendor claim rather than a published service level; Google’s own search documentation states no latency figure and cautions that “full data retrieval might be limited, as search is optimized for discovery and exploration by returning a limited set of the most relevant results.” The same page adds that results “don’t guarantee full recall” and may omit matching results, the sharper caveat for anyone grounding an agent on it (as of September 16, 2026).

Which capabilities are generally available and which are in Preview

Capability	Status	What it covers
Metadata aggregation	GA	Google Cloud data and AI services
Data products	GA, April 2026	BigQuery assets in a semantic wrapper
Semantic search	GA	Semantic matching, keywords, and structured predicates
Access-control-aware search	GA	Results filtered to the calling principal
Knowledge Catalog MCP servers	No Preview label	Remote (/mcp, /mcp/data-products) and local Toolbox
Looker ingestion	Preview	Looker (Google Cloud core) dashboards, LookML, Explores
Iceberg REST federation	Preview	Databricks Unity, AWS Glue, Snowflake Horizon
SaaS context federation	No documented stage (blog only)	SAP, Salesforce Data360, Workday, Palantir, ServiceNow
BigQuery measures	Preview	Metric definitions against BigQuery tables
Deep multimodal extraction	Preview	Semantics from unstructured assets
Data lineage remote MCP server	Preview, “as is”	Lineage graph queries over MCP

That status column is the most useful line in any evaluation here, and it is Google’s own published position on which classes of context Google Cloud is authoritative for today. What it leaves open is which layer answers when the same definition also exists somewhere Google Cloud does not run.

---

What is an enterprise context layer authoritative for?

An enterprise context layer is the neutral system holding the definition the business agreed, the approval that happened outside any warehouse, the contract attached to it, and the graph an agent traverses to get the same answer whichever vendor is asking.

Its authority comes from a different source. Google Cloud earns authority by running the engine and observing what happens inside it. The neutral layer earns authority by being where cross-system agreement is recorded and approved, a business event rather than a platform event, and a context layer reference architecture sets out how the two sit together.

Agents are why this now matters operationally. Asked what a metric means, an agent needs one resolution, not a per-system answer that is only locally correct. That comes from traversing an agent context graph rather than reading whichever table description sat nearest the query.

What an enterprise context layer holds

• The reconciled metric definition. The version two or more teams argued their way to.
• Approval and ownership state. Who certified this, when, and who is accountable if it is wrong.
• Cross-system lineage. Provenance spanning systems no cloud provider can observe.
• Data contracts. Data contracts for AI stating shape, freshness, and owner.
• The Enterprise Data Graph. The structure resolving one definition per query, so a Gemini agent and a Claude agent answer the same question the same way.

Authority here is a property of neutrality rather than capability, which makes a context layer complementary to a platform-native context engine rather than parallel to one.

---

Where does federation stop and semantic extraction begin?

Federation registers an asset so it can be found and referenced. Semantic extraction produces the descriptions, relationships, and meanings an agent reasons over, and Google documents the difference itself.

Start with what Google shipped, because it is more than most comparisons credit. Google documents Iceberg REST federation for Databricks Unity, AWS Glue Data Catalog, and Snowflake Horizon, all in Preview. Google’s blog adds context federation for SAP, Salesforce Data360, Workday, Palantir and ServiceNow; those five are announcements, not documentation, and carry no launch stage. Keep the two apart when you quote them. Either way, “native means single-cloud” stopped being a true sentence in April 2026.

Then read the caveat Google publishes in the same overview:

“While Knowledge Catalog supports major third-party systems, certain automated semantic extractions might be limited to built-in Google Cloud services.”

That is the decision in one sentence. Our reading of it: a registered asset an agent can see is not yet a described asset an agent can reason over. Federation gets a table into the entry list; extraction produces the column meanings and relationships. Google draws that line itself, and it is the line to quote.

The practical consequence is a division of labor you can write down.

Class of context	Authoritative layer	Why	What breaks if you invert it
BigQuery schema and column semantics	Knowledge Catalog	Google Cloud reads the schema as jobs run	Your neutral record is stale the moment a table changes
Lineage inside Google Cloud	Knowledge Catalog	Emitted by the services that ran the jobs	Lineage is inferred, not observed
IAM and policy enforcement	Knowledge Catalog	Enforcement happens where the data sits	A rule exists on paper and nothing stops the query
Gemini-derived descriptions	Knowledge Catalog	Generated from metadata Google Cloud holds	You hand-write what a service produces
The reconciled metric definition	Enterprise context layer	Reconciliation happened between teams	Each system keeps its own version of one number
Approval and ownership state	Enterprise context layer	Approval is a business event with a named owner	An agent cannot tell an approved definition from a draft
Context beyond Google Cloud’s observation	Enterprise context layer	The record must exist where observation stops	Anything past the boundary is absent, not wrong
One definition per agent vendor	Enterprise context layer	Neutrality is the property being bought	Each agent inherits whatever its own stack holds

Every row states what a layer is authoritative for. That is why a multi-cloud context layer argument built on cloud count has aged badly while the same argument built on context portability has not. What a semantic layer for AI agents has to answer is not where the asset is registered, but whose meaning the agent gets when both systems hold one.

---

Whose agents are asking? Why a BigQuery-only estate is often a multi-vendor agent estate

The old axis was where your data lives. The current axis is how many agent vendors need the same definition to mean the same thing, and those two numbers stopped moving together.

According to a16z’s AI Enterprise 2025 study of 100 enterprise CIOs, 37% of enterprises now run five or more models in production, up from 29% the year before. One warehouse, five model vendors, and the model-agnostic context layer is the part of that stack nobody rebuilds per vendor. The choice between Google ADK, LangGraph, and AutoGen gets made per team, not per company.

Grounding those agents in agreed semantics changes their answers measurably, with a qualifier that matters. According to dbt Labs (2026), on modeled data, semantic-layer grounding took Claude Sonnet 4.6 from 90.0% to 98.2% and GPT-5.3-Codex from 84.1% to 100%. Across all questions in the same benchmark the figures are 64.5% for text-to-SQL and 72.7% with the semantic layer, a different measurement rather than the same one restated. Grounding pays off most once the modeling is done, so the layer and the modeling are one investment.

The same benchmark argues the other side: unaided text-to-SQL nearly doubled between 2023 and 2026, from 32.7% to 64.5%. Models are getting better at this alone, so the claim is narrower than the headline. What improves is the model’s guess, not the enterprise’s agreement about what a number means, and context management across multi-agent systems is an authority problem before it is a retrieval problem.

---

Which layer should serve context to your agents over MCP?

Both layers expose MCP servers, so an agent can reach the context either way. The open question is which layer should answer.

Google ships four, not one. Its MCP overview lists a Knowledge Catalog remote server and a local Toolbox server, plus a data lineage remote server and a data lineage local Toolbox server (as of September 15, 2026). Only the data lineage remote server carries a Preview banner, and it is that page, not the Knowledge Catalog one, that says Pre-GA features are “available ‘as is’ and might have limited support.” The Knowledge Catalog remote server carries no such banner. Do not read that as GA either: Google’s release notes announced remote MCP server support as Preview on May 25, 2026, and no general-availability announcement has followed. The banner came off; the label never went on.

Per Google’s documentation, that server answers on two endpoints, dataplex.googleapis.com/mcp for discovery and dataplex.googleapis.com/mcp/data-products for data products. Authentication is OAuth 2.0 plus IAM with the roles/mcp.toolUser and roles/dataplex.catalogAdmin roles, and the named clients are Gemini CLI, ChatGPT, Claude, and custom applications. Google’s FAQ states that agents “can discover and adaptively use Knowledge Catalog tools through a local or remote MCP server.”

The second endpoint is the one that changes the argument, because it writes. Google’s MCP reference gives /mcp three read tools, search_entries, lookup_context, and lookup_entry, while /mcp/data-products adds create_data_product, update_data_product, create_data_asset, update_data_asset, and update_data_product_aspects. The OAuth scope list includes dataplex.read-write, and Google’s own sample prompts include creating a data product and granting a role on a data asset.

That matters more than the read path did. An agent holding write scope can mint the definition it failed to find, and a definition an agent created is not a definition the business approved. Why MCP matters for AI agents was never that it grants access to something otherwise unreachable. What a protocol standardizes, as an MCP architecture deep dive makes clear, is the shape of the request, not the authority of the response. Atlan’s hosted MCP server is GA and serves ADK and Gemini CLI agents today, so an estate running both has several servers to route between and a write path to scope deliberately.

Make the judgement before you wire the second. Asked what a metric means, Google’s server is authoritative for what Google Cloud extracted, the neutral layer for what was agreed. That is a routing decision, and MCP delivers business context only once someone has decided which server owns which class of question.

---

What happens when both systems define the same business term?

Both systems can hold the same glossary term, data product, and quality signal, and without an explicit precedence rule the divergence is silent. Nothing alerts. The two records simply stop agreeing.

Object both can hold	Held natively in	Precedence rule to set	How drift shows up	What to check
A glossary term	Knowledge Catalog glossary (GA); the context layer’s glossary	The layer holding the approved definition answers; the other points to it	Text diverges after a console edit no crawl collected	Definition text and named owner match, same date
A data product	Knowledge Catalog data products (GA); the context layer’s contract	Google Cloud for packaged assets, the context layer for contract and approver	Assets added in the console with no contract change	Asset list and contract name one owner and scope
A quality signal	Knowledge Catalog quality and profiling scans	Google Cloud produced the measurement, the context layer holds the agreed threshold	A scan passes while the agreed threshold moved	Scan threshold and contract threshold are one number
Asset ownership	IAM principals; the accountable owner in the context layer	IAM for access, the context layer for accountability	The principal is a service account with no human owner	Every certified asset resolves to a named person
A column-level description	Gemini-derived descriptions; Aspect field values written back	Schema authority with Google Cloud, value authority with the context layer	A generated description overwrites an approved one	Which system last wrote the field, and whether it is in scope

One documented constraint settles most of the last row, and it is a mechanic rather than a preference. Atlan’s Aspects Reverse-Sync writes Aspect field values only: Aspect Type schemas are read-only through Atlan and deletion is unsupported. Schema authority therefore sits with Google Cloud by design, and value authority can sit with the neutral layer.

State the scope honestly in the same breath. Atlan’s Knowledge Catalog connector is in beta and BigQuery-only for enrichment; Cloud Storage, Spanner, and AlloyDB are roadmap. Anyone promising parity between a beta connector and a GA platform surface is selling something.

Three ways drift shows up

A term edited in the Google Cloud console does not reach the neutral layer until the next crawl, so for a window both systems are confidently correct and different. A definition approved in the neutral layer reaches the console only through the Aspect field values reverse-sync supports, so an approval can be real and invisible where the platform team is looking. Anything outside BigQuery has no write path today, which is the shape context drift takes when nothing is watching, and why context drift detection belongs in the operating routine rather than the incident review. That window is also where tribal knowledge re-enters: someone knows which record is right, and no agent can ask them.

Set the precedence rule before you connect the second MCP server

• Do the two glossaries agree on the definition text and the named owner, checked the same day?
• Does the agent’s MCP path resolve to the layer holding the approved definition, not the one that answers fastest?
• Which agents hold dataplex.read-write rather than dataplex.readonly, and who reviews what they create through /mcp/data-products?
• Do the data product and the contract name the same owner and scope?
• When they disagree, which record would you defend to an auditor?
• Is there a reconciliation cadence with someone’s name on it, or only an integration?

Coexistence is an operational discipline, not a static state. Two systems holding live semantics over the same BigQuery assets will not stay consistent on their own; one becomes the de facto source of truth whether or not anyone chose it. Every shared term needs an explicit precedence rule or a periodic reconciliation job, and a shared context layer glossary is only as authoritative as the last reconciliation. Skip that and metric drift in enterprise text-to-SQL arrives through a second door.

---

When does Knowledge Catalog cover what your agents need on its own?

There are real conditions under which a second layer is not yet earning its place.

Knowledge Catalog covers what your agents need on its own when your data genuinely sits in BigQuery and Looker, your agent surface is Gemini and Gemini Enterprise only, and no definition has to hold identically on a system Google Cloud does not observe. One more condition is your team: the API, client library, CLI and IAM roles still say Dataplex, so configuring it lands with whoever owns your Google Cloud infrastructure.

Cost belongs in the judgement, and it has a second meter now. Google’s pricing meters Knowledge Catalog in Data Compute Unit hours across Standard and Premium tiers, pay as you go, at $0.06 per DCU for standard processing in Iowa, and states verbatim that “Pricing SKUs will remain named as Dataplex.” Data organization and security policy application are free of charge. A second meter lands on data insights specifically. Google’s Knowledge Catalog FAQ states that “active billing for data insights starts on October 27, 2026,” that usage is “measured in data tokens,” and points to Data Cloud Agent pricing for the rate: $3 per million input data tokens and $20 per million output data tokens (as of September 15, 2026). Read the pricing page alone and you would miss it, because it still describes Gemini-powered features as billing under Gemini in BigQuery. The Data Cloud agent free trial runs through September 30, 2026, a different date again, so anyone who sized this product during the trial sized it without either line. Two meters, one usage-shaped and one token-shaped, are what a context layer TCO assessment across build, buy, and bundle puts to every option, bundling included, alongside the full-stack platform and best-of-breed context layer decision. For a single-vendor estate the bundled answer is defensible.

The neutral layer’s job starts on a specific day: when a second agent vendor asks the same question, or a definition has to hold somewhere Google Cloud does not observe.

---

How Knowledge Catalog and the Atlan context layer work together on BigQuery

The coexistence architecture is described most clearly by Google. Chaitanya Pydimukkala, Product Leader at Google Cloud and co-author of its Knowledge Catalog launch post:

“Through our integration with Atlan, we’re building the context layer that connects meaning and quality across even the most complex environments. Knowledge Catalog provides context for structured and unstructured data assets on Google Cloud, and Atlan augments it with machine-readable context about definitions, users, data, and semantics from across the data estate. Together, we’re expanding universal context to multi-cloud and hybrid cloud systems, so teams can maximize value from their data and AI.”

Chaitanya Pydimukkala, Product Leader, Google Cloud

The mechanics, with status on each. Atlan’s Knowledge Catalog connector is in beta, BigQuery-first: it crawls Aspects metadata, ingests Data Quality and Data Profiling scan results at column level, and auto-discovers new Google Cloud projects and Aspect Type definitions. Aspects Reverse-Sync writes context decisions back as Aspect field values, visible in the Google Cloud console. PSC-native transit keeps metadata inside the customer VPC under VPC Service Controls. Atlan’s hosted MCP server is GA, with LookML extraction and field-level lineage production-grade.

Google’s April 2026 launch post names Atlan among the third-party catalogs it supports, so the pattern is documented on both sides rather than asserted on one. Atlan runs the same division of labor alongside other platform-native context surfaces, written up for Snowflake Horizon Context and Genie Ontology, and the sequence in how to implement an enterprise context layer for AI holds here: decide the authority line first, connect second.

---

Real stories from real customers: context on Google Cloud and across the estate

CME Group runs BigQuery and Looker with on-premises systems in one lineage graph, the estate shape this question is about. Atlan’s public CME Group story puts it at more than 18 million assets, over 1,300 glossary terms, and more than 100 active users in the first year. Workday’s version comes from the agent side: the shared language already existed, and what changed was making it resolvable by an agent over MCP.

---

Coexistence is an operational discipline

The axis moved. It used to run from single-cloud to multi-cloud, and Google answered that in April 2026 with federation, third-party aggregation, and an MCP server that ChatGPT and Claude can call. What remains is which layer is authoritative when both hold the same definition.

Both stay true only with work: a precedence rule, a reconciliation cadence, and someone’s name on it. Decide the authority line before you wire the agent harness, because otherwise the first thing you debug is the definition rather than the agent, and that is why context layer evaluation criteria start with authority rather than connector counts.

When four agents on three vendors ask what revenue means, which layer do you want to have answered, and did you decide that or did the tool ordering?

---

FAQs about Knowledge Catalog and an enterprise context layer for BigQuery

1. What is the Google Cloud Knowledge Catalog?

Google Cloud Knowledge Catalog is Google’s Gemini-powered context engine for a Google Cloud data estate, which Google describes as an always-on engine unifying structured, unstructured, and SaaS data into agent-ready context. It was renamed from Dataplex Universal Catalog on April 10, 2026.

2. Is Google Cloud Data Catalog still available?

No. Legacy Data Catalog was deprecated on February 3, 2025 and carries a shutdown date of June 1, 2026, as does its Business Glossary. Google still publishes a two-phase transition guide, so estates with custom metadata may still be mid-move. Knowledge Catalog is the successor, and the API, CLI, and IAM names carried over unchanged.

3. How much does Google Knowledge Catalog cost?

Knowledge Catalog is metered in Data Compute Unit hours across Standard and Premium tiers, pay as you go, with no published flat per-asset price. A second meter applies to data insights: Google’s Knowledge Catalog FAQ states that active billing for data insights starts on October 27, 2026, measured in data tokens, at the Data Cloud Agent rate of $3 per million input data tokens and $20 per million output data tokens. Standard processing runs $0.06 per DCU in Iowa (us-central1), with 1-year and 3-year committed-use rates of $0.054 and $0.048. Both meters follow usage rather than a fixed inventory.

4. Can Knowledge Catalog catalog non-Google sources?

Yes, with a status caveat. Google Cloud’s documentation lists federated support for Databricks Unity IRC, AWS Glue Data Catalog IRC, and Snowflake Horizon IRC, plus context federation for five SaaS platforms including SAP and ServiceNow. All are in Preview, and Google notes certain automated semantic extractions might be limited to built-in services.

5. Which parts of Knowledge Catalog are generally available and which are in Preview?

Generally available: metadata aggregation, data products, high-precision semantic search, and access-control-aware search. In Preview: Looker ingestion, context federation, BigQuery measures, deep multimodal extraction, automated context curation, verified queries and semantic guardrails, and the data lineage remote MCP server, which Google offers as is with limited support. The Knowledge Catalog MCP servers sit in between: Google announced remote MCP server support as Preview in May 2026, the Preview banner is no longer on the page, and no GA announcement has followed.

6. How many MCP servers does Knowledge Catalog have, and can agents write through them?

Google ships four: a Knowledge Catalog remote server, a Knowledge Catalog local Toolbox server, a data lineage remote server, and a data lineage local Toolbox server. Only the data lineage remote server is in Preview. The Knowledge Catalog remote server answers on two endpoints, dataplex.googleapis.com/mcp for read-only discovery and dataplex.googleapis.com/mcp/data-products, which is read-write and exposes create_data_product, update_data_product, create_data_asset, and update_data_asset.

7. Do you still need an enterprise context layer if you use Knowledge Catalog?

It turns on one thing: whether any definition has to hold identically outside what Google Cloud can observe. If your data is BigQuery and Looker and your only agent surface is Gemini, Knowledge Catalog covers it. Once a second agent vendor asks, the neutral layer makes the answer the same either way.

8. What happens when Knowledge Catalog and an enterprise context layer both define the same business term?

Without an explicit precedence rule they diverge quietly and nothing alerts. Set the rule per object: Google Cloud is authoritative for schema, lineage, and enforcement, the neutral layer for the approved definition, the contract, and the accountable owner. Then reconcile on a cadence.

---

Sources

1. Knowledge Catalog overview, Google Cloud documentation

2. Introducing the Google Cloud Knowledge Catalog, Google Cloud Blog (2026)

3. Knowledge Catalog product page, Google Cloud

4. Use Knowledge Catalog with BigQuery, Google Cloud documentation

5. Use the Knowledge Catalog remote MCP server, Google Cloud documentation

6. Knowledge Catalog FAQ, Google Cloud documentation

7. Deprecations, Google Cloud documentation

8. Knowledge Catalog pricing, Google Cloud

9. About MCP servers in Knowledge Catalog, Google Cloud documentation

10. MCP Reference: dataplex.googleapis.com, Google Cloud documentation

11. Use the data lineage remote MCP server, Google Cloud documentation

12. About search in Knowledge Catalog, Google Cloud documentation

13. About metadata in Knowledge Catalog, Google Cloud documentation

14. Transition from Data Catalog to Knowledge Catalog, Google Cloud documentation

15. Data Cloud Agent pricing, Google Cloud

16. Introducing the Google Cloud Knowledge Catalog, Google Cloud blog

17. Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, dbt Labs (2026)

18. How 100 Enterprise CIOs Are Building and Buying Gen AI, a16z (2025)

19. CME Group: Context at Speed, Atlan