Data Catalogs Help You Find Data. Query Context Helps AI Use It Correctly.

# Data Catalogs Help You Find Data. Query Context Helps AI Use It Correctly.

Data catalogs have become an important part of the modern data stack. They help teams document assets, search for tables, understand ownership, and improve data discoverability.

But as enterprises start using AI agents, NL2SQL workflows, BI copilots, and internal data assistants, a new gap becomes clear.

Finding data is not the same as using data correctly.

A catalog can tell an AI system that a table exists. It may show column names, descriptions, owners, tags, and maybe lineage. But when an AI system needs to generate SQL, it needs more than discovery. It needs query-time context: the business definitions, trusted relationships, join paths, access policies, and lineage required to choose the right data and assemble the right query.

This article explains the difference between data catalogs and query context, why both matter, and why AI-generated SQL needs a context layer that goes beyond asset search.

---

## The Job of a Data Catalog

A data catalog helps people understand what data exists across an organization.

In most enterprises, data assets are spread across warehouses, databases, BI tools, dashboards, spreadsheets, pipelines, and operational systems. Without a catalog, teams waste time asking basic questions:

- Where is the customer table?

- Who owns this dataset?

- What does this column mean?

- Is this table certified?

- Which dashboard uses this field?

- Has anyone documented this metric?

A good catalog improves visibility. It creates a searchable inventory of data assets and helps teams avoid starting from zero.

Common catalog capabilities include:

- Data asset search

- Table and column descriptions

- Ownership and stewardship

- Tags and classifications

- Business glossary entries

- Basic lineage

- Data quality signals

- Certification status

- Collaboration and documentation

These capabilities are valuable. They help humans find data, understand data, and manage data assets at scale.

But AI systems do not only need to find data. They need to decide how to use it.

That is where catalogs alone are often not enough.

---

## The Job of Query Context

Query context is the information an AI system needs before it generates SQL.

It answers questions such as:

- Which metric definition is approved?

- Which physical fields should be used?

- Which table is the trusted source for this question?

- How do the required tables connect?

- Which join path should be used?

- Is this relationship validated or only inferred?

- Which user permissions apply?

- Should any fields be masked or excluded?

- Can the final answer be explained and audited?

This context is not just documentation. It must be structured, retrievable, and usable at query time.

For AI-generated SQL, query context usually includes four layers:

1. **Semantic context**: business terms, metrics, formulas, dimensions, filters, owners, and approved logic.

2. **Relationship context**: table relationships, join keys, join paths, cardinality, evidence, confidence, and validation status.

3. **Governance context**: access policies, sensitive fields, masking rules, row-level controls, and usage constraints.

4. **Lineage context**: which definitions, fields, tables, relationships, and policy decisions were used to produce the answer.

A catalog may store some of this information, but AI needs it in a more operational form. It must be available before SQL is generated, not only after someone searches a catalog page.

---

## Why Asset Discovery Is Not Enough for AI

Consider a simple business question:

> What was net revenue by region last quarter?

A data catalog may help an analyst search for tables related to revenue, orders, invoices, customers, or regions. It may show several candidate assets.

But an AI system generating SQL needs to make specific decisions:

- Does “net revenue” include refunds?

- Should tax be included or excluded?

- Which date field defines “last quarter”?

- Should revenue come from invoices, orders, payments, or accounting records?

- Which regional field should be used: billing region, sales region, delivery region, or operating region?

- How should customer, order, invoice, refund, and region tables be joined?

- Will the join path duplicate rows?

- Does the current user have permission to access every field?

A catalog can help locate possible assets. Query context helps decide which assets, definitions, relationships, and policies should actually be used.

Without query context, AI often does what humans would not do: it guesses.

Sometimes the generated SQL will fail. That is visible.

The bigger risk is when the SQL runs successfully but uses the wrong metric, wrong table, wrong join path, or wrong policy assumption. The answer looks clean, but the logic is wrong.

---

## The Relationship Gap in Traditional Catalogs

One of the most important gaps is relationship context.

In enterprise data environments, table relationships are rarely as clean as they look in diagrams. Foreign keys may be missing. Naming conventions may be inconsistent. Relationships may exist across systems. Some join paths are valid for one metric but wrong for another. Historical SQL, ETL logic, BI models, and dbt projects may contain relationship knowledge that is not declared in the database.

A catalog may show that two tables exist. It may even show that both contain a column named `customer_id`.

But AI needs to know more:

- Are these columns actually joinable?

- Is the relationship one-to-one, one-to-many, or many-to-many?

- What evidence supports the relationship?

- Has a data team validated it?

- Is this join path approved for this business question?

- Could this join create fanout or double counting?

- Is there a better path through another table?

This is why relationship discovery and join path validation are central to AI-generated SQL.

AI does not only need a list of tables. It needs a trusted map of how data connects.

---

## The Metric Definition Gap

Another gap is metric context.

Catalogs often include glossary terms or descriptions, but AI-generated SQL needs metric definitions that are precise enough to execute.

For example, a glossary entry might say:

> Net revenue is revenue after refunds and discounts.

That is helpful for a human, but not enough for SQL generation.

An AI system also needs to know:

- Which table contains the approved revenue source?

- Which fields represent gross revenue, refunds, discounts, tax, and credits?

- Which formula should be used?

- Which time dimension applies?

- Which dimensions are approved for grouping?

- Which filters must always be applied?

- Who owns the metric?

- Which version of the metric definition is current?

A catalog helps define meaning. Query context turns meaning into executable guidance.

For AI SQL, a metric definition should not only be readable. It should be usable by a query generation workflow.

---

## The Policy Gap

AI-generated SQL must also respect governance.

A catalog may classify sensitive fields or show ownership. But when a user asks a question, the AI system needs to know which data it is allowed to use before it generates SQL.

For example:

- Some users may see aggregated revenue but not customer-level revenue.

- Some columns may require masking.

- Some regions may have stricter access controls.

- Some fields may be restricted by role, contract, or compliance requirement.

- Some questions may need to be denied or clarified.

If governance is applied only after SQL is generated, the user experience becomes fragile. The AI may propose a query that violates policy, expose restricted field names, or produce an explanation that does not match the final executed query.

Query context helps move governance earlier in the workflow.

Instead of generating SQL first and checking later, the AI system can retrieve policy context before generation. That makes it more likely to choose allowed fields, apply the right constraints, and explain why certain data is unavailable.

---

## The Lineage Gap

Enterprise teams need more than answers. They need explanations.

When an AI system returns a number, users will eventually ask:

- Where did this answer come from?

- Which metric definition was used?

- Which fields and tables were selected?

- Which join path was applied?

- Which filters were included?

- Which access rules changed the result?

- Can this answer be audited later?

A catalog may contain lineage for pipelines or dashboards. But AI-generated SQL introduces a new lineage requirement: query-time lineage.

The system should be able to explain the path from business question to generated SQL, including the semantic definitions, relationships, policies, and data assets involved.

Without this, AI answers become difficult to defend in business, operational, and regulated environments.

---

## Data Catalog vs. Query Context

The difference is not that one is good and the other is bad. They solve different problems.

| Area | Data catalog | Query context |

|---|---|---|

| Primary job | Help people find and understand data assets | Help AI and tools use data correctly at query time |

| Main user | Analysts, data stewards, data teams | AI agents, NL2SQL workflows, BI copilots, data apps |

| Core question | “Where is the data?” | “How should this question be answered?” |

| Output | Search results, asset pages, descriptions, ownership | Definitions, join paths, policies, lineage, SQL grounding |

| Relationship handling | Often descriptive or manually documented | Needs evidence, confidence, validation, and approved paths |

| Metric handling | Glossary and documentation | Executable metric logic and field mappings |

| Governance | Classification and ownership | Policy-aware query generation |

| Timing | Before analysis, during discovery | Before SQL generation |

A data catalog makes data visible.

Query context makes data usable by AI.

---

## Why AI Needs Context at Query Time

AI-generated SQL is different from traditional manual analysis.

A human analyst can search a catalog, ask teammates, inspect dashboards, read SQL history, and apply judgment. An AI system needs that judgment to be represented as structured context.

This is why query context must be available at the moment of generation.

When a user asks a question, the AI system should be able to retrieve:

- Approved business definitions

- Relevant tables and fields

- Trusted relationship paths

- Confidence and evidence for joins

- Access policies and masking rules

- Lineage requirements

- Clarification rules for ambiguity

Only then can the system generate SQL that is not merely syntactically valid, but also aligned with enterprise logic.

The goal is not to make AI “know everything.” The goal is to reduce guessing.

---

## Where Catalogs Still Matter

Query context does not replace a data catalog.

In many organizations, the catalog remains the system of record for asset inventory, ownership, glossary management, classification, and collaboration. Those capabilities are still important.

The question is how catalog knowledge becomes operational.

If a catalog contains business definitions, those definitions should be available to AI query workflows.

If a catalog contains classifications, those classifications should inform policy-aware SQL generation.

If a catalog contains lineage, that lineage should help explain AI-generated answers.

If a catalog contains table and column metadata, that metadata should help relationship discovery and join path validation.

In this model, the catalog remains valuable, but it becomes part of a broader AI query context architecture.

---

## How Data Teams Can Start Building Query Context

Teams do not need to boil the ocean.

A practical starting point is to choose a small number of high-value business questions and trace what AI would need to answer them safely.

For each question, ask:

1. Which metric or business concept is involved?

2. Is there an approved definition?

3. Which tables and fields are required?

4. How do those tables connect?

5. Which join paths are trusted?

6. What evidence supports those relationships?

7. What access policies apply?

8. What lineage should be returned with the answer?

9. What ambiguity should trigger clarification?

10. Which context should be served through an API, MCP server, or BI workflow?

This exercise often reveals that the warehouse is technically queryable but not yet context-ready.

The first layer of query context should focus on the domains where AI-generated SQL will create the most value or the most risk.

---

## Where Arisyn Fits

Arisyn is designed to provide governed query context for AI-generated SQL.

Semora helps map business terms, metrics, dimensions, formulas, and approved logic to governed data fields. IntaLink helps discover, validate, and score table relationships and trusted join paths. Together, they help AI agents, NL2SQL workflows, BI tools, and analytics applications understand what to query, how the data connects, and which policies apply before SQL is generated.

Arisyn does not need to replace your data catalog, warehouse, BI platform, or semantic layer. Instead, it helps turn definitions, relationships, policies, and lineage into query-time context that AI systems can use.

The result is a more reliable path from business question to governed SQL.

---

## Final Thought

Data catalogs help enterprises answer an important question:

> What data do we have?

AI-generated SQL requires another question:

> What context does AI need to use this data correctly?

As AI becomes part of analytics workflows, the second question becomes increasingly important.

A catalog can help people find data. Query context helps AI systems understand which data to use, how to join it, what definitions to follow, what policies to respect, and how to explain the answer.

That is the difference between searchable data and AI-ready data.