DEV Community: ArisynData

Beyond SQL Accuracy: Building Evidence Chains for AI Data Agents

ArisynData — Thu, 20 Aug 2026 03:10:07 +0000

AI data agents are getting good at producing executable SQL.

That is useful, but executable SQL is not the same thing as a correct business answer.

A query can compile, run successfully, return real rows, and still answer the wrong question because the agent selected the wrong metric definition, source table, relationship, grain, time field, or filter.

For production systems, this creates a different engineering requirement:

An AI data agent should not only generate an answer. It should preserve the evidence that produced it.

This article explores how to treat that evidence as a first-class artifact rather than an explanation generated after the fact.

## 1. Why SQL Accuracy Is an Incomplete Target

Consider this question:

What was net revenue by region last quarter?

The agent generates:

SELECT
    c.region,
    SUM(i.invoice_amount) AS net_revenue
FROM invoices i
JOIN customers c
    ON i.customer_id = c.customer_id
WHERE i.invoice_date >= '2026-04-01'
  AND i.invoice_date < '2026-07-01'
GROUP BY c.region;

The query is valid.

But suppose the enterprise definition is:

Net Revenue
=
Recognized Revenue
-
Refunds
-
Credits

and regional attribution is based on the billing account rather than the customer master.

The SQL engine cannot detect this error.

From the database's perspective, the query is correct.

From the business's perspective, it is wrong.

That gives us two different validation layers:

SQL Validity
=
Can this query execute?

Business Validity
=
Does this query represent the intended business question?

Production AI analytics needs both.

## 2. The Failure Surface Is Larger Than SQL Generation

A useful way to model an AI data query is:

Question
   ↓
Semantic Resolution
   ↓
Source Selection
   ↓
Relationship Selection
   ↓
Filter / Time Resolution
   ↓
SQL Generation
   ↓
Execution
   ↓
Answer

An error can occur at any stage.

For example:

Semantic Resolution
Revenue → Invoice Amount       ❌

Source Selection
invoices                       ✓

Relationship Selection
invoice.customer_id → customer ✓

Time Resolution
invoice_date                   ❌

SQL Generation
Valid SQL                      ✓

Execution
Success                        ✓

If we evaluate only the final SQL syntax or execution status, the system appears healthy.

The real failure happened much earlier.

This is why AI data agents need evidence chains, not just query logs.

## 3. What Is an Evidence Chain?

An evidence chain records the artifacts and decisions that connect a user question to the final answer.

Conceptually:

User Question
      │
      ▼
Business Definition
      │
      ▼
Source Data
      │
      ▼
Relationships
      │
      ▼
Filters / Time Rules
      │
      ▼
Generated SQL
      │
      ▼
Execution Result
      │
      ▼
Final Answer

The goal is not to create another verbose chain-of-thought log.

The goal is to preserve verifiable system artifacts.

That distinction matters.

Internal model reasoning is probabilistic and may not be suitable as an audit artifact.

A metric identifier, relationship identifier, SQL query, data-source identifier, and execution result are inspectable.

## 4. Evidence Should Be Structured

Instead of storing only:

question
sql
answer

store a structured evidence object.

For example:

{
  "question": "What was net revenue by region last quarter?",

  "semantic_resolution": {
    "metric_id": "net_revenue",
    "metric_version": "3.2",
    "dimensions": ["billing_region"]
  },

  "sources": [
    "orders",
    "refunds",
    "billing_accounts"
  ],

  "relationships": [
    {
      "relationship_id": "rel_orders_billing_account",
      "from": "orders.billing_account_id",
      "to": "billing_accounts.account_id",
      "status": "trusted"
    }
  ],

  "time": {
    "field": "settlement_date",
    "period": "last_quarter"
  },

  "sql": {
    "query_id": "q_8271"
  },

  "execution": {
    "result_id": "r_4412",
    "status": "success"
  },

  "validation": {
    "status": "passed"
  }
}

Now the answer has provenance.

## 5. Capture Evidence During Execution, Not Afterward

A common anti-pattern is:

1. Agent generates answer
2. User asks "Why?"
3. LLM generates an explanation

That produces a narrative, not necessarily provenance.

The model may describe what it believes happened.

A stronger implementation captures evidence as each stage executes.

For example:

evidence = Evidence(question=question)

metric = resolve_metric(question)
evidence.metric_id = metric.id
evidence.metric_version = metric.version

dimension = resolve_dimension(question)
evidence.dimensions.append(dimension.id)

path = relationship_service.get_trusted_path(
    metric=metric,
    dimensions=[dimension]
)
evidence.relationship_ids.extend(path.relationship_ids)

sql = generate_sql(
    question=question,
    metric=metric,
    dimensions=[dimension],
    relationship_path=path
)
evidence.sql = sql

result = execute(sql)
evidence.execution_status = result.status
evidence.result_id = result.id

The evidence object is built from actual system events.

That makes it much more useful for debugging and audit.

6. Semantic Evidence

The first layer is semantic resolution.

If the user asks:

What was revenue last quarter?

the system should be able to show:

User Term:
Revenue

Resolved Metric:
Net Revenue

Version:
3.2

Definition:
Recognized Revenue - Refunds - Credits

This matters because business terms are often ambiguous.

The SQL may be technically perfect while using the wrong definition.

A metric version is particularly important.

If Revenue v3.1 and v3.2 differ, the evidence chain should preserve which version generated the answer.

## 7. Source Evidence

The next question is:

Which data actually contributed to the answer?

For example:

orders
refunds
billing_accounts

A production evidence record may also include fields:

{
  "source": "orders",
  "fields": [
    "billing_account_id",
    "recognized_amount",
    "settlement_date"
  ]
}

This makes it possible to inspect whether the agent used an authoritative source rather than merely a semantically similar table.

## 8. Relationship Evidence

Multi-table queries require another layer of provenance.

Suppose the query joins:

orders
   ↓
billing_accounts
   ↓
region

The evidence should preserve why that path was selected.

At minimum:

{
  "relationship_id": "rel_orders_billing_account",
  "from": "orders.billing_account_id",
  "to": "billing_accounts.account_id",
  "status": "trusted"
}

More advanced systems could include relationship evidence such as:

Database Constraint
Naming Similarity
Value Inclusion
Uniqueness
Business Validation

The important point is that the agent is not silently inventing a join.

The relationship is inspectable.

## 9. Filter and Time Evidence

Filters are easy to overlook because they often appear as simple SQL predicates.

But they can completely change the business answer.

For example:

"last quarter"

might resolve to:

2026-04-01 → 2026-06-30

and use:

settlement_date

rather than:

invoice_date

The evidence record should preserve both.

For example:

{
  "time_resolution": {
    "business_period": "last_quarter",
    "start": "2026-04-01",
    "end": "2026-06-30",
    "field": "settlement_date"
  }
}

This makes temporal interpretation auditable.

## 10. Query Evidence

The SQL itself remains critical evidence.

But do not treat SQL as the entire explanation.

SQL is the executable consequence of upstream decisions.

A useful query record might include:

{
  "query_id": "q_8271",
  "sql_hash": "sha256:...",
  "generated_at": "2026-08-20T09:15:00Z",
  "metric_version": "3.2",
  "relationship_ids": [
    "rel_orders_billing_account"
  ]
}

This makes the query reproducible and connects it to the semantic and relationship state used during generation.

## 11. Execution Evidence

Execution success is useful evidence, just not sufficient evidence.

Capture:

Execution Status
Duration
Rows Returned
Data Source
Query Timestamp
Result Identifier

Potentially:

{
  "status": "success",
  "duration_ms": 842,
  "rows_returned": 8,
  "result_id": "r_4412"
}

This lets the system distinguish:

Bad SQL

from:

Valid SQL + Wrong Business Interpretation

## 12. Validation Should Check the Chain

Instead of asking only:

Did the SQL execute?

validation can inspect several layers.

### Semantic Validation

Was an approved metric definition used?

### Source Validation

Were authorized and current data sources used?

### Relationship Validation

Were joins based on trusted relationships?

### Filter Validation

Were required business filters applied?

### Query Validation

Did the SQL pass syntax and safety checks?

This produces a richer validation object:

{
  "semantic": "passed",
  "sources": "passed",
  "relationships": "passed",
  "filters": "passed",
  "sql": "passed"
}

## 13. Why LLM-as-a-Judge Cannot Be the Only Validator

A second model can review generated SQL.

That is useful.

But consider:

Agent:
Revenue = invoice_amount

Judge:
The SQL correctly sums invoice_amount.

Both models agree.

Both can still be wrong relative to the enterprise definition.

Language models are good at evaluating logical consistency inside the context they receive.

They cannot recover enterprise truth that is missing from that context.

So:

You cannot verify a data answer with language alone.

Verification needs grounded evidence from semantic definitions, metadata, relationships, executed SQL, and query results.

## 14. Evidence Chains Improve Debugging

Suppose an answer is reported as incorrect.

Without structured evidence, the debugging workflow may be:

Reproduce Prompt
↓
Inspect Agent Logs
↓
Inspect SQL
↓
Guess What Went Wrong

With evidence:

Semantic Resolution      PASS
Source Selection         PASS
Relationship Selection   FAIL
Filter Resolution        PASS
SQL Validation           PASS
Execution                PASS

The engineering team immediately knows where to investigate.

This is especially valuable because many production NL2SQL failures happen before SQL generation.

## 15. Evidence Chains Improve Evaluation

Evidence also makes offline and online evaluation more granular.

Instead of only measuring:

Exact SQL Match
Execution Accuracy
Final Answer Accuracy

teams can measure:

Metric Resolution Accuracy
Source Selection Accuracy
Relationship Selection Accuracy
Filter Resolution Accuracy
Trusted Relationship Usage
SQL Validation Pass Rate

This turns a monolithic accuracy score into a diagnostic system.

If final-answer accuracy drops, the team can determine which layer caused the regression.

## 16. Evidence as an API Object

Evidence should not exist only in the UI.

It can be part of the agent API.

For example:

{
  "answer": {
    "metric": "Net Revenue",
    "value": 27300000,
    "currency": "USD"
  },

  "evidence": {
    "metric": {
      "id": "net_revenue",
      "version": "3.2"
    },

    "sources": [
      "orders",
      "refunds",
      "billing_accounts"
    ],

    "relationships": [
      "rel_orders_billing_account"
    ],

    "query_id": "q_8271",

    "validation": "passed"
  }
}

Now downstream systems can choose how much evidence to expose.

## 17. Progressive Disclosure in the UI

Most business users do not want to read SQL after every question.

So the default UI can remain simple:

Net Revenue
$27.3M

✓ Evidence available

Then:

Why this answer?

can reveal:

Metric Definition
Source Data
Relationships
Filters
SQL
Validation

Different users can inspect different levels.

An executive may stop at the answer.

An analyst may inspect the metric and filters.

A data engineer may inspect joins and SQL.

## 18. Evidence Is Stronger Than Explanation

There is an important difference between:

Explainable

and:

Inspectable

An LLM can generate a convincing explanation.

An inspectable system exposes the artifacts that actually produced the answer.

For enterprise data, inspectability is often the stronger trust mechanism.

The user does not have to believe the explanation.

They can inspect the evidence.

## 19. A Practical Evidence Pipeline

A simplified architecture could look like:

User Question
      │
      ▼
Semantic Resolver
      │
      ├── metric_id
      └── dimension_ids
      │
      ▼
Relationship Resolver
      │
      └── relationship_ids
      │
      ▼
Context Builder
      │
      ▼
SQL Generator
      │
      └── query_id
      │
      ▼
SQL Validator
      │
      ▼
Query Executor
      │
      └── result_id
      │
      ▼
Answer Generator
      │
      ▼
Evidence Object

Every stage contributes structured evidence.

The evidence object becomes the trace that connects the original question to the final answer.

## 20. What Should Be Stored?

At minimum:

Question ID
User Question
Resolved Metric + Version
Resolved Dimensions
Source Tables / Fields
Relationship IDs
Filters
Time Interpretation
Generated SQL / Query ID
Execution Result ID
Validation Status
Timestamp

Depending on governance requirements, also consider:

Semantic Model Version
Relationship Model Version
Data Snapshot / Query Timestamp
Authorization Context
Agent Version
Model Version

This makes answers reproducible even as the system evolves.

## 21. A Better Definition of Production Readiness

For a prototype, this may be enough:

Question → SQL → Answer

For production enterprise AI, a stronger standard is:

Question
→ Governed Interpretation
→ Trusted Data Path
→ Executable Query
→ Traceable Result
→ Evidence-Backed Answer

The difference is not cosmetic.

It changes how the system can be trusted, evaluated, debugged, audited, and improved.

## Final Thoughts

AI data agents are rapidly improving at generating SQL.

But SQL generation is only one stage in a much larger correctness problem.

A production system should be able to answer two questions:

What is the answer?

and:

What evidence produced that answer?

That evidence should include the business definition, source data, relationships, filters, SQL, execution result, and validation state.

Not because every user wants to inspect every detail.

But because enterprise trust should be based on something stronger than model confidence.

A trustworthy data agent does not just return a number. It preserves the chain of evidence that makes the number verifiable.

The Reasoning Tax: Why AI Data Agents Waste Tokens Relearning Your Schema

ArisynData — Tue, 18 Aug 2026 02:52:49 +0000

If your data agent has to rediscover metric definitions, table relationships, and trusted query paths on every request, you are spending LLM reasoning on knowledge your system should already have.

AI data agents are becoming increasingly capable.

A modern agent can:

retrieve schemas;
interpret business terms;
identify candidate tables;
infer joins;
generate SQL;
validate queries;
execute them;
explain the result.

That looks like progress.

But from an engineering perspective, there is an uncomfortable question:

How much of this work is genuinely new reasoning, and how much is the agent repeatedly rediscovering facts the enterprise already knows?

That repeated work creates a hidden cost: the reasoning tax.

## A Typical Data Agent Does Too Much at Query Time

Consider this question:

What was revenue by customer last quarter?

A typical agent pipeline may look like:

User Question
      ↓
Intent Detection
      ↓
Schema Retrieval
      ↓
Business Term Resolution
      ↓
Candidate Table Selection
      ↓
Relationship Discovery
      ↓
Join Path Selection
      ↓
Metric Construction
      ↓
SQL Generation
      ↓
SQL Validation
      ↓
Execution

Now the user asks:

Show customer revenue for Q2.

The analytical intent is almost identical.

But many implementations repeat most of the pipeline.

The agent may again retrieve schemas, resolve Revenue, identify Customer, compare join paths, and choose the reporting date.

This is wasteful because much of that information is not query-specific.

## Separate Query-Time Reasoning From Reusable Knowledge

A useful engineering distinction is:

Reusable Enterprise Knowledge
vs.
Query-Specific Reasoning

### Reusable Enterprise Knowledge

Examples:

Revenue = Recognized Revenue

Customer = canonical customer entity

Revenue Date = recognition_date

Customer → Order = trusted relationship

Order → Revenue = validated query path

These should not be probabilistically reconstructed on every request.

### Query-Specific Reasoning

Examples:

What is the user asking?

Does "last quarter" mean fiscal or calendar quarter?

Should results be grouped by customer or customer segment?

Is the user asking for a comparison?

What should be investigated next?

These genuinely depend on the current request.

The design principle is:

Retrieve the known. Reason about the unknown.

## Why the Reasoning Tax Matters

There are three immediate engineering consequences.

### 1. Token Usage

Suppose schema retrieval returns 30 tables, each with:

table descriptions;
columns;
data types;
comments;
sample values.

The agent may receive thousands of tokens before reasoning even starts.

If every query repeatedly includes the same structural information, token consumption scales with query volume.

A rough model is:

Total Token Cost
≈
Requests
×
(Context Tokens + Reasoning Tokens + Output Tokens)

Reducing repeated context has a direct effect on cost.

### 2. Latency

Agent workflows often involve multiple model or tool calls:

Retrieve
→ Classify
→ Resolve
→ Plan
→ Generate
→ Validate

Even if each step takes only a small amount of time, the total latency accumulates.

If a trusted metric definition can be returned from a deterministic service in milliseconds, there is little value in asking an LLM to infer it again.

### 3. Inconsistency

Repeated reasoning also introduces variability.

One request may produce:

Revenue → invoice_amount

Another:

Revenue → recognized_revenue

Another:

Revenue → order_amount

The model may be behaving reasonably in all three cases.

The architecture is simply asking it to repeatedly solve an ambiguous problem.

Govern the definition once and retrieve it consistently.

## Schema Retrieval Is Necessary, but It Is Not Enough

A common NL2SQL architecture is:

Question
   ↓
Embedding Search
   ↓
Relevant Tables
   ↓
LLM
   ↓
SQL

This is much better than sending the entire warehouse schema.

But table retrieval still leaves unresolved questions:

Which metric is authoritative?

Which entity is canonical?

Which relationship is trusted?

Which date field should be used?

Which join path is safe?

Retrieval that returns only schema is still forcing the LLM to reconstruct business knowledge.

A richer query context should return something closer to:

question: "revenue by customer last quarter"

metric:
  name: revenue
  definition: recognized_revenue
  aggregation: SUM

dimensions:
  - customer

time:
  field: recognition_date

tables:
  - customer
  - sales_order
  - finance_revenue

trusted_path:
  - customer
  - sales_order
  - finance_revenue

Now the LLM is not discovering the data model.

It is using it.

## Precompute Relationship Knowledge

Relationship inference is a major source of unnecessary query-time reasoning.

Suppose the agent needs to connect:

Customer

to:

Payment

It may discover several candidate paths:

Customer → Order → Invoice → Payment

Customer → Account → Payment

Customer → Contract → Invoice → Payment

If the organization has already validated the first path for this analytical scenario, there is no reason to compare all three paths again.

Relationship knowledge can be discovered ahead of time using evidence such as:

Primary / Foreign Keys
Column Naming
Value Overlap
Uniqueness
Inclusion Ratio
Historical Query Patterns
Business Validation

For example:

A = order.customer_id
B = customer.customer_id

A useful signal is:

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

Relationship candidates can then move through:

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted

Query-time agents should preferentially retrieve the trusted result.

## Move Metric Resolution Out of the Prompt

Metric definitions are another common source of repeated reasoning.

Instead of embedding this in every system prompt:

When the user says revenue, use recognized_amount
from finance_revenue unless...

maintain a governed metric object:

{
  "metric": "revenue",
  "version": "2.1",
  "aggregation": "SUM",
  "table": "finance_revenue",
  "column": "recognized_amount",
  "time_field": "recognition_date",
  "status": "active"
}

The agent calls:

get_metric_definition("revenue")

and receives the current definition.

This has several advantages:

one definition across agents;
easier versioning;
easier auditing;
less prompt complexity;
fewer tokens;
less ambiguity.

## Build Query Context Before Calling the LLM

A useful architecture is:

                User Question
                     │
                     ▼
          ┌────────────────────┐
          │ Context Resolver   │
          ├────────────────────┤
          │ Business Terms     │
          │ Metrics            │
          │ Metadata           │
          │ Relationships      │
          │ Trusted Paths      │
          └─────────┬──────────┘
                    │
                    ▼
             Trusted Context
                    │
                    ▼
                  LLM
                    │
             Reason / Generate
                    │
                    ▼
                   SQL

The LLM receives only what is relevant.

This changes the role of the model.

Before:

LLM = Data Discovery + Business Interpretation + Reasoning + SQL

After:

Data Layer = Known Enterprise Facts

LLM = Intent + Reasoning + SQL / Analysis

## A Simple Context Resolver

Conceptually, the resolver could work like this:

def build_query_context(question):
    concepts = resolve_business_terms(question)

    metrics = get_metric_definitions(concepts)
    entities = get_business_entities(concepts)

    metadata = get_relevant_metadata(
        metrics=metrics,
        entities=entities
    )

    relationships = get_trusted_relationships(
        metadata.tables
    )

    return {
        "metrics": metrics,
        "entities": entities,
        "metadata": metadata,
        "relationships": relationships
    }

Then:

context = build_query_context(question)

sql = llm.generate_sql(
    question=question,
    context=context
)

The exact implementation will vary.

The architectural point is that the model does not have to infer every layer of enterprise knowledge itself.

## Cache Stable Knowledge at the Right Level

Not all knowledge changes at the same frequency.

For example:

Table Schema
→ changes occasionally

Metric Definition
→ changes occasionally

Trusted Relationship
→ changes occasionally

User Question
→ changes every request

This suggests different caching and refresh strategies.

A system might maintain:

Metadata Cache
Semantic Cache
Relationship Cache
Query Context Cache

with invalidation triggered by:

Schema Change
Metric Version Change
Relationship Update
Governance Update

This is more efficient than treating every query as a completely new reasoning problem.

## MCP Can Expose the Known Layer

For agent-based architectures, MCP can provide a clean interface to reusable enterprise knowledge.

For example:

get_metric_definition

get_business_entity

get_table_metadata

get_trusted_relationships

get_query_context

The agent workflow becomes:

Question
   ↓
Agent
   ↓
MCP Tools
   ↓
Enterprise Data Intelligence
   ↓
Trusted Context
   ↓
LLM Reasoning

MCP does not remove the need for semantic or relationship intelligence.

It gives agents a standardized way to access it.

## Do Not Confuse Precomputation With Hard-Coding

Moving knowledge out of query-time reasoning does not mean freezing the data model.

Enterprise knowledge changes.

Schemas evolve.

Metrics change.

Relationships change.

The reusable layer therefore needs:

Discover
   ↓
Detect Change
   ↓
Evaluate Impact
   ↓
Validate
   ↓
Version
   ↓
Publish
   ↓
Invalidate Cache

The objective is not:

Never reason about the data model again.

It is:

Do not reason about the same established data knowledge on every request.

## Measure the Reasoning Tax

Teams can make this problem observable.

Useful metrics might include:

### Context Tokens per Query

Average tokens sent before generation

### Reasoning Calls per Query

Average LLM calls required before SQL execution

### Schema Candidates per Query

How many tables / columns must the model evaluate?

### Relationship Resolution Rate

% of queries using prevalidated relationships

### Metric Resolution Rate

% of business metrics resolved without LLM inference

### Time to First SQL

Question received
→
Executable SQL generated

These metrics can reveal whether the agent is spending most of its time solving analytical problems or reconstructing the enterprise data model.

## The Optimization Target Changes

A common optimization question is:

Which model gives the best SQL accuracy?

That still matters.

But production systems should also ask:

How much unnecessary reasoning are we forcing the model to perform?

A more capable model may hide poor architecture by successfully reasoning through large amounts of noisy context.

That does not make the architecture efficient.

The better system may be the one that gives the model less to figure out.

## Final Thoughts

AI agents are good at reasoning.

Reasoning is also probabilistic, expensive, and slower than deterministic lookup.

So use it where it adds value.

If Revenue already has a governed definition:

retrieve it.

If Customer already has a canonical entity:

retrieve it.

If a join path is already trusted:

retrieve it.

Then let the model solve the genuinely new problem:

what the user is asking and how to analyze it.

The next generation of enterprise data agents may not win by thinking harder.

They may win by knowing what they no longer need to think about.

Why Every AI Agent Shouldn't Have to Rediscover Your Data Model

ArisynData — Fri, 14 Aug 2026 10:23:00 +0000

Enterprise AI is moving toward a multi-agent architecture.

Instead of one general-purpose assistant, organizations are starting to build specialized agents for:

sales;
finance;
operations;
customer support;
analytics;
management.

That creates an engineering problem that is easy to miss.

If every agent independently receives database schemas, retrieves metadata, learns metric definitions, discovers join paths, and builds its own interpretation of the business, then every new agent becomes another data-modeling project.

The result is not only duplicated engineering work.

It is duplicated enterprise understanding.

A better architecture is to separate agent reasoning from shared data intelligence.

## The Problem With Agent-Local Data Knowledge

A simple data agent often looks something like:

User
  ↓
Agent
  ├── System Prompt
  ├── Schema Retrieval
  ├── Metric Definitions
  ├── Join Instructions
  ├── SQL Tool
  └── LLM
        ↓
    Database

For a single proof of concept, this is reasonable.

Now imagine five teams building five agents:

Sales Agent
Finance Agent
Supply Chain Agent
Support Agent
Analytics Agent

Each team has to solve the same problems:

Which tables are relevant?

What does "Customer" mean?

Which definition of Revenue is authoritative?

How should Customer connect to Order?

Which data source should be trusted?

The implementation may be different, but the underlying enterprise knowledge is largely the same.

If that knowledge lives inside each agent, duplication begins immediately.

## Example: Five Agents, Three Definitions of Revenue

Suppose an enterprise contains:

sales_order.total_amount
finance_invoice.invoice_amount
finance_revenue.recognized_amount
payment.received_amount

A sales agent might map:

Revenue → sales_order.total_amount

A finance agent might use:

Revenue → finance_revenue.recognized_amount

An analytics agent might retrieve:

Revenue → finance_invoice.invoice_amount

All three agents may generate syntactically correct SQL.

All three queries may execute successfully.

But the organization now has three AI systems answering the same business question differently.

The problem is not LLM reasoning.

The problem is that business meaning was implemented locally inside each agent.

## Business Knowledge Should Be an Enterprise Dependency

Agent-specific knowledge and enterprise-wide knowledge should be separated.

An agent may legitimately own:

task instructions;
workflow logic;
persona;
tool selection;
planning strategy.

But definitions such as these should not be duplicated:

Customer
Revenue
Active Customer
Inventory Balance
Gross Margin

The same applies to data relationships:

Customer
   ↓
Order
   ↓
Invoice
   ↓
Payment

These are enterprise data assets.

They should be reusable dependencies.

## Thick Agents vs. Thin Agents

A thick agent contains a large amount of enterprise-specific intelligence:

Agent
├── LLM
├── Business Semantics
├── Metrics
├── Schema Knowledge
├── Relationship Knowledge
├── Business Rules
├── Query Logic
└── Tools

This creates coupling.

If the Revenue definition changes, multiple agents may need to change.

If a trusted join path changes, multiple prompts or tools may need to be updated.

If the organization switches models, important business knowledge may be buried inside model-specific implementation.

A thinner design looks different:

Agent
├── LLM
├── Task Logic
├── Planning
└── Tools
      ↓
Shared Data Intelligence
├── Business Semantics
├── Metrics & Dimensions
├── Metadata
├── Trusted Relationships
└── Query Context
      ↓
Enterprise Data

Now the agent does not need to rediscover the enterprise every time it answers a question.

## What Should the Shared Data Layer Expose?

The shared layer does not have to be one monolithic service.

It can expose several reusable capabilities.

### 1. Metadata Retrieval

For example:

{
  "table": "sales_order",
  "columns": [
    "order_id",
    "customer_id",
    "order_date",
    "total_amount"
  ]
}

But raw metadata alone is not enough.

### 2. Business Semantics

The agent should be able to resolve:

"recognized revenue"

into something like:

metric: revenue
definition: recognized revenue
aggregation: SUM
source:
  table: finance_revenue
  column: recognized_amount

This definition can then be reused by every authorized agent.

### 3. Relationship Discovery

Suppose the agent needs Customer and Payment data.

It should not have to guess the join path from raw schemas.

A relationship service could return:

Customer
   ↓ customer_id
Order
   ↓ order_id
Invoice
   ↓ invoice_id
Payment

along with evidence or confidence information.

For example:

{
  "path": [
    "customer",
    "sales_order",
    "invoice",
    "payment"
  ],
  "status": "trusted"
}

### 4. Query Context

Instead of sending an entire warehouse schema into the prompt, the agent can receive only the relevant context:

Question
   ↓
Resolve Business Concepts
   ↓
Retrieve Relevant Metadata
   ↓
Retrieve Trusted Relationships
   ↓
Generate Query Context
   ↓
LLM

This reduces unnecessary context and gives the model more targeted information.

## Why Schema Retrieval Alone Is Not Enough

A common pattern today is:

Question
   ↓
Embedding Search
   ↓
Relevant Tables
   ↓
LLM
   ↓
SQL

This is useful.

It solves the problem of sending thousands of tables to the model.

But it does not answer:

Which metric definition is authoritative?

Which relationship is trusted?

Which business entity does this table represent?

Retrieval answers:

What looks relevant?

A shared data intelligence layer must also answer:

What is valid for this business question?

That distinction matters more as the number of agents grows.

## Relationship Knowledge Should Be Evidence-Based

Enterprise relationships are often not fully represented by foreign keys.

A relationship engine can use several signals:

Database constraints
Naming similarity
Value overlap
Uniqueness
Inclusion relationships
Validated business mappings

For example, if:

A = order.customer_id
B = customer.customer_id

we can calculate:

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

A high inclusion ratio can provide evidence that A references B.

But discovered relationships should not automatically become business truth.

A safer lifecycle is:

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted

Agents should preferentially consume trusted relationships rather than independently inventing joins.

## MCP Fits Here — But It Is Not the Data Model

MCP gives agents a standardized way to discover and call tools.

That makes it a natural interface for shared data capabilities.

For example, an enterprise data MCP server could expose tools such as:

get_metric_definition()

get_table_metadata()

discover_relationships()

get_query_context()

An agent could then call:

Agent
  ↓
MCP
  ↓
Shared Data Intelligence Services

But MCP itself does not determine:

What Revenue means

Which customer definition is authoritative

Which join path is trusted

Those decisions come from the data intelligence behind the interface.

A useful distinction is:

MCP standardizes access. Shared data intelligence standardizes understanding.

## Centralization Does Not Mean Static Knowledge

Moving enterprise knowledge into a shared layer solves duplication, but it creates another responsibility:

the shared knowledge must stay current.

Enterprise systems continuously change:

New tables
New columns
New metrics
New business rules
New relationships

So the shared layer needs its own lifecycle:

Discover
   ↓
Detect Change
   ↓
Evaluate Impact
   ↓
Validate
   ↓
Version
   ↓
Publish

Otherwise the organization simply replaces many stale agent configurations with one stale central configuration.

## What Happens When a Metric Changes?

Suppose:

Revenue v1
=
SUM(invoice_amount)

changes to:

Revenue v2
=
SUM(recognized_amount)

With agent-local knowledge:

Sales Agent → update
Finance Agent → update
Analytics Agent → update
Management Agent → update
Support Agent → maybe update

Someone has to discover every dependency.

With shared semantics:

Revenue Definition
       ↓
Version Update
       ↓
Shared Data Intelligence
       ↓
All Authorized Agents

The enterprise changes the definition once.

Agents consume the updated version.

That is a much cleaner dependency model.

## Shared Data Intelligence Also Reduces Agent Coupling

There is another benefit.

Agent frameworks are changing quickly.

Organizations may switch between:

models;
orchestration frameworks;
agent runtimes;
application interfaces.

Business knowledge should survive those changes.

If metric definitions, data relationships, and business mappings are independent of the agent implementation, agents become easier to replace.

That suggests an architectural principle:

Agents = Replaceable Compute / Reasoning

Enterprise Data Intelligence = Durable Knowledge

The enterprise should own its understanding of itself.

Not the current agent framework.

## A Practical Multi-Agent Data Architecture

A simplified architecture might look like:

               Sales Agent
                    │
              Finance Agent
                    │
             Analytics Agent
                    │
             Operations Agent
                    │
                    ▼
        ┌──────────────────────┐
        │ Shared Data          │
        │ Intelligence Layer   │
        ├──────────────────────┤
        │ Business Semantics   │
        │ Metrics & Dimensions │
        │ Metadata             │
        │ Relationships        │
        │ Trusted Query Paths  │
        └──────────────────────┘
                    │
                    ▼
             Enterprise Data

The shared layer does not replace agents.

It makes them thinner.

It does not replace the LLM.

It gives the LLM a consistent representation of the enterprise.

## Final Thoughts

The first generation of enterprise agents focused on making individual agents more capable.

The multi-agent era creates a different engineering problem:

How do many agents share one consistent understanding of enterprise data?

If every agent independently discovers schemas, defines metrics, and guesses relationships, organizations will create duplicated logic and inconsistent answers.

The better pattern is separation of concerns:

Agents reason.

Shared data intelligence defines what the enterprise means.

Models will change.

Agents will change.

Frameworks will change.

Your enterprise should not have to rediscover its own data model every time they do.

Semantic Drift: The Hidden Failure Mode of Enterprise AI Analytics

ArisynData — Wed, 12 Aug 2026 13:18:00 +0000

Enterprise AI systems rarely fail only because the model is weak.

A more subtle failure happens when the model is working correctly, the SQL executes successfully, and the result looks reasonable — but the system is reasoning over an outdated representation of the business.

This is semantic drift.

As more teams put semantic layers between LLMs and enterprise data, maintaining those semantics becomes a production engineering problem rather than a one-time modeling task.

The database changes.

Business definitions change.

Relationships change.

If the AI's understanding does not change with them, accuracy degrades quietly.

A Semantic Layer Is Runtime Infrastructure

A common AI analytics architecture looks roughly like this:

User Question
     ↓
LLM / Query Agent
     ↓
Semantic Layer
     ↓
Enterprise Data

The semantic layer may contain:

business terms;
metric definitions;
dimensions;
mappings to physical tables and columns;
relationships used to generate queries.

This helps prevent an LLM from guessing directly from raw schemas.

But there is an important consequence:

Once AI depends on the semantic layer at query time, stale semantics become a runtime failure.

The problem is that semantic models are often maintained as if they were documentation.

Define them once.

Review them.

Publish them.

Then assume they remain correct.

Enterprise data does not behave that way.

Failure Mode 1: Schema Drift

Suppose a metric is mapped to:

customer.customer_id

After a warehouse migration, the organization introduces:

account_customer.customer_key

The old table may remain available for compatibility.

That creates a dangerous situation.

Nothing necessarily breaks.

The old query can still execute.

The semantic mapping is simply pointing to a representation that is no longer authoritative.

Traditional schema monitoring may tell you that a column was added.

AI analytics needs to answer a harder question:

Does this schema change invalidate any business meaning used by the AI?

That requires connecting physical metadata changes to semantic dependencies.

Failure Mode 2: Semantic Drift

Semantic drift happens even when the schema does not change.

Consider:

Active Customer

Version 1:

customer.status = 'ACTIVE'

Later, the business changes the definition:

customer with >= 1 completed order in the last 90 days

The database can remain exactly the same.

But the meaning has changed.

An AI system using the old definition may continue returning perfectly valid SQL and perfectly wrong business answers.

This is why execution success is a weak validation signal for enterprise AI.

SQL succeeded != business meaning is correct

Failure Mode 3: Relationship Drift

This problem becomes more interesting when queries span multiple tables.

Imagine the original analytical path is:

Customer
   ↓ customer_id
Order

After an ERP redesign:

Customer
   ↓
Account
   ↓
Order

The old join may still work because legacy identifiers remain populated.

But the organization has changed the business relationship.

An LLM that sees both paths now has multiple executable options.

Which one is correct?

This cannot be solved reliably with schema retrieval alone.

The system needs maintained relationship knowledge.

Why Embeddings Do Not Solve Drift

A common approach is to embed schema metadata and retrieve relevant tables for each question.

For example:

User Question
     ↓
Embedding Search
     ↓
Relevant Tables / Columns
     ↓
LLM
     ↓
SQL

This is useful for reducing schema size.

But semantic similarity does not tell us whether a definition is current.

Embedding search may find:

invoice_amount
recognized_revenue
payment_amount

for the term:

revenue

All three are semantically related.

Only business governance can determine which one currently represents the metric.

Likewise, embeddings may identify two similar identifiers, but similarity does not prove that they form the trusted join path.

Retrieval solves relevance.

It does not solve validity.

Treat Semantic Assets Like Versioned Code

If semantic definitions affect AI-generated answers, they should be treated more like production code than documentation.

A metric definition should have:

metric: revenue
version: 2.1
status: active
definition: recognized revenue
source:
  table: finance_revenue
  column: recognized_amount
valid_from: 2026-07-01

A relationship should also carry explicit evidence:

relationship:
  from: customer.customer_id
  to: account.customer_id
type: business_validated
confidence: 0.97
status: active

The exact format is less important than the engineering principle:

Meaning needs identity, state, history, and validation.

Without versioning, it becomes difficult to answer basic production questions:

Which definition generated this answer?
When did that definition change?
Which queries are affected?
Can we roll back?

Detect Changes Before They Become Wrong Answers

A living semantic system needs change detection.

At the physical layer, monitor:

New table
Column added
Column removed
Type changed
Constraint changed

At the relationship layer:

New candidate relationship
Join coverage changed
Identifier uniqueness changed
Relationship confidence changed

At the semantic layer:

Metric definition changed
Mapping became ambiguous
Business term changed
New semantic version published

The important part is not generating more alerts.

It is calculating impact.

For example:

finance_invoice.invoice_amount changed
                 ↓
revenue metric mapping affected
                 ↓
12 query templates affected
                 ↓
AI queries using Revenue require validation

Now schema monitoring becomes useful to AI governance.

Relationship Discovery Should Produce Candidates, Not Truth

Automatically discovering relationships can help keep a data model current.

Signals may include:

declared primary/foreign keys;
naming similarity;
value overlap;
uniqueness;
inclusion ratio;
historical joins.

For two columns A and B, a simple inclusion signal could be:

inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|

A high value can indicate a possible relationship.

But it should not automatically become trusted business logic.

A better lifecycle is:

Relationship Detected
        ↓
Candidate
        ↓
Evidence / Confidence
        ↓
Validation
        ↓
Trusted Relationship

This distinction matters.

Automated discovery improves coverage.

Governance establishes trust.

Human-in-the-Loop Is a Feature, Not a Failure

Enterprise semantics often cannot be inferred safely from technical metadata alone.

If the system finds:

Revenue

mapped plausibly to both:

sales_order.total_amount

and:

finance_revenue.recognized_amount

the correct behavior may be to ask for clarification.

A useful workflow is:

Ambiguity Detected
       ↓
Candidate Definitions
       ↓
Human Review
       ↓
Validate With Query
       ↓
Publish New Version

The goal of automation is not to eliminate domain experts.

It is to stop asking them to manually rediscover every schema and relationship change.

A Practical Living Data Model Loop

Putting the pieces together, the lifecycle looks like:

1. Discover metadata
        ↓
2. Detect schema and relationship changes
        ↓
3. Identify impacted semantic assets
        ↓
4. Generate candidate updates
        ↓
5. Validate ambiguous business meaning
        ↓
6. Version and publish
        ↓
7. Use validated semantics for AI queries
        ↓
8. Repeat

This is fundamentally different from:

Build semantic layer → Done

The semantic model becomes an operational system.

What Should Be Monitored?

A few useful signals include:

Semantic Coverage

How much of the active analytical surface has governed meaning?

governed metrics / queried metrics

Relationship Coverage

How many required multi-table query paths are backed by trusted relationships?

Ambiguity Rate

How often does a business term map to multiple plausible definitions?

Stale Mapping Rate

How many semantic mappings reference changed or deprecated physical assets?

Validation Failure Rate

How often do proposed semantic or relationship updates fail business validation?

These metrics tell you more about production readiness than simply measuring whether SQL execution succeeds.

The Key Engineering Shift

The first generation of LLM analytics focused heavily on query generation.

The next engineering challenge is maintaining the data knowledge used to generate those queries.

A stronger model cannot compensate for a stale business definition.

A larger context window cannot determine whether an old join path is still authoritative.

And better embeddings cannot decide when the organization changed the meaning of revenue.

The system needs a maintained layer of enterprise data knowledge.

Not static metadata.

Not a one-time semantic project.

A living model.

Final Thoughts

If your AI analytics system depends on business semantics, those semantics are production infrastructure.

Treat them accordingly.

Monitor changes.

Track relationships.

Version definitions.

Detect ambiguity.

Validate business meaning.

Because the most dangerous enterprise AI failure is not always a broken query.

Sometimes the query works perfectly — against yesterday's understanding of the business.

Building AI Analysts: Why Enterprise Analytics Needs More Than BI Dashboards

ArisynData — Mon, 10 Aug 2026 12:46:00 +0000

For decades, enterprises have relied on dashboards as the primary way to consume business data.

A typical workflow looks like:

Business Question
↓
Find the Right Dashboard
↓
Select Filters
↓
Review Metrics
↓
Human Analysis

This model works well for predefined questions.

But modern businesses increasingly ask questions that were never designed into dashboards:

Why did sales decline in East China last month?

Answering this requires combining:

sales data;
customer data;
product data;
regional information;
order history.

A dashboard can show what happened.

But understanding why it happened requires deeper analysis.

This is where AI Analysts become valuable.

From BI Dashboards to AI Analysts

AI changes the interaction model.

Instead of searching for reports, users can directly express business questions.

Business Question

↓

AI Understanding

↓

Data Discovery

↓

Multi-dimensional Analysis

↓

Business Insight

The goal is not simply generating charts.

The goal is helping users understand:

What happened?
Why did it happen?
What factors contributed?
What should be investigated next?

Why Building AI Analysts Is Difficult

Connecting an LLM to a database is not enough.

Enterprise analytics requires understanding the business behind the data.

An AI Analyst needs to understand:

business concepts;
data relationships;
analytical logic.

Understanding Business Concepts

Business users do not think in tables.

They ask:

Show me high-value customers.

But enterprises may have:

customer_table

account_table

crm_customer

billing_customer

The AI needs to understand:

Which customer definition is correct?
Which attributes define value?
Which data source should be trusted?

A business concept is not always a table.

It is a combination of entities, metrics, rules, and relationships.

Understanding Data Relationships

Enterprise analysis rarely depends on one table.

A typical path may involve:

Customer
↓
Order
↓
Contract
↓
Payment

However, enterprises often contain:

multiple applications;
duplicated entities;
different identifiers;
historical data models.

A database may allow many joins.

But only some relationships represent business logic.

The important question is not:

Can these tables be joined?

It is:

Is this the correct business relationship?

Moving From Answers to Analysis

Traditional systems answer:

What is the number?

AI Analysts should answer:

Why is this number changing?

For example:

Sales decreased last month. Why?

The system should analyze:

regional changes;
customer changes;
product changes;
historical trends.

This requires dynamic analysis instead of fixed dashboards.

The Architecture Behind AI-Native Analytics

A future analytics system is not simply:

User
↓
LLM
↓
Database

A more reliable architecture requires:

User Question

↓

AI Understanding

↓

Semantic Layer

↓

Relationship Intelligence

↓

Query Generation

↓

Analysis Result

AI needs to understand:

Business Semantics

What does the data mean?

Examples:

revenue definition;
active customer definition;
inventory calculation.

Data Relationships

How is enterprise data connected?

Examples:

customer to order;
order to invoice;
invoice to payment.

Analytical Context

What analysis should happen next?

Examples:

comparison;
trend analysis;
root cause exploration.

The Future of Enterprise Analytics

The next generation of analytics will combine:

large language models;
semantic understanding;
relationship intelligence;
enterprise data governance.

The future is not about creating more dashboards.

It is about creating AI systems that can become intelligent partners in business analysis.

Final Thoughts

Traditional BI helped enterprises understand what happened.

AI Analysts will help enterprises understand why it happened.

But this requires more than connecting an LLM to a database.

AI needs to understand business concepts, data relationships, and analytical context.

Only then can enterprise AI move from answering questions to supporting real analysis.

Beyond Data Lineage: Building Observability for AI-Generated Queries

ArisynData — Wed, 05 Aug 2026 11:20:00 +0000

Enterprise AI is moving from experimentation to production.

Organizations are deploying AI assistants that can query databases, generate reports, and analyze business data.

The first challenge was making AI capable of answering questions.

The next challenge is making those answers trustworthy.

When an AI system provides an answer, enterprises need to understand:

What data did AI use?
Why did AI choose those tables?
Which business definitions were applied?
How was the final answer generated?

This is where traditional data observability needs to evolve.

Traditional Data Observability Was Built for Data Pipelines

For years, enterprises focused on understanding how data moved.

A typical lineage looks like:

Source Database

↓

ETL Pipeline

↓

Data Warehouse

↓

BI Report

Organizations needed to know:

Where did data come from?
Which pipeline transformed it?
Which reports depend on it?

This became the foundation of modern data governance.

However, AI introduces a different type of data consumption.

AI does not only move data.

AI interprets data.

AI Creates a New Observability Challenge

Consider a question:

Why did sales decrease last month?

An AI assistant may:

Understand the question.
Select relevant data sources.
Generate SQL.
Execute the query.
Explain the result.

The final answer may look reasonable.

But enterprises need more visibility.

They need to understand:

User Question

↓

AI Interpretation

↓

Business Definition

↓

Selected Data Sources

↓

Relationship Path

↓

Generated SQL

↓

Final Answer

This is different from traditional data lineage.

It is AI reasoning lineage.

Why AI Query Results Need Explainability

Traditional BI systems use predefined reports.

Users usually know:

which metric is used;
which data source is connected;
how calculations are performed.

AI-powered analytics changes this.

The query path can be generated dynamically.

The selected tables may change.

The SQL may be different for different questions.

Therefore, AI systems need to explain not only the answer, but also the reasoning behind the answer.

The Four Layers of AI Data Observability

AI data observability extends traditional data governance with new capabilities.

1. Query Lineage

Traditional lineage asks:

Where did this data come from?

AI query lineage asks:

How did AI produce this answer?

It should capture:

user question;
generated SQL;
selected tables;
filters;
returned datasets.

2. Semantic Lineage

Enterprise concepts often have multiple meanings.

For example:

Revenue may mean:

sales revenue;
recognized revenue;
invoice amount;
payment amount.

AI observability needs to record:

which business definition was used;
which metric mapping was applied;
which semantic rules affected the answer.

3. Relationship Lineage

Enterprise queries often depend on relationships:

Customer

↓

Order

↓

Invoice

↓

Payment

AI needs to know:

which relationship path was selected;
why this path was chosen;
whether the relationship is trusted.

A valid SQL join does not always represent a valid business relationship.

4. Answer Explainability

Enterprise users need more than a result.

They need to understand:

where the data came from;
what logic was applied;
what assumptions were made.

This is critical in industries where decisions depend on reliable data.

From Data Governance to AI Governance

Traditional data governance focused on:

data quality;
metadata;
lineage;
ownership.

AI introduces new requirements:

AI query traceability;
semantic consistency;
relationship validation;
answer transparency.

The question is changing from:

"Can we manage enterprise data?"

to:

"Can we trust how AI uses enterprise data?"

Final Thoughts

AI can generate answers quickly.

But enterprises need more than speed.

They need confidence.

Traditional data lineage helped organizations understand how data moved.

AI observability will help organizations understand how AI reasons over data.

The future of enterprise AI will belong to systems that are not only intelligent, but also transparent and trustworthy.

Building Data Intelligence for Reliable Enterprise AI

ArisynData — Mon, 03 Aug 2026 11:41:00 +0000

Large language models are becoming more capable every year.

They can generate SQL, write code, analyze documents, and interact with enterprise systems through tools.

However, when organizations move AI applications from prototypes to production, a common problem appears:

AI can access enterprise data.

But access does not mean understanding.

Many enterprise AI failures are not caused by weak models.

They are caused by the fact that enterprise data was designed for applications and humans, not for AI systems.

Data Access Is Not Data Intelligence

Modern enterprises already have mature data platforms:

relational databases;
data warehouses;
data lakes;
BI systems;
metadata management platforms.

These systems solve an important problem:

How do we store and access data?

AI introduces a different challenge:

How does AI understand and use this data correctly?

A database can tell an AI system:

this is a customer table;
this is a revenue column;
this field contains an identifier.

But it usually cannot explain:

which customer definition is trusted;
what revenue means in this business context;
how data from different systems should be connected.

The difference is the gap between data access and data intelligence.

Why Traditional Metadata Is Not Enough

Many enterprise AI systems start by providing metadata to LLMs.

For example:

Table: customer

Columns:
customer_id
customer_name
create_time

This information helps AI discover available data.

But it does not provide enough business understanding.

Consider a simple question:

Who are our most valuable customers?

An enterprise may have:

crm_customer

erp_customer

billing_customer

All three tables may contain customer information.

The challenge is not finding these tables.

The challenge is understanding:

Are they the same business entity?
Which one is authoritative?
How should they be related?

Without this knowledge, AI has to guess.

And guessing creates unreliable answers.

Data Intelligence Starts With Business Meaning

Enterprise data contains many ambiguous concepts.

A common example is:

Revenue

It may represent:

sales revenue;
recognized revenue;
invoice amount;
payment amount;
contract value.

From a database perspective, all of these are valid fields.

From a business perspective, they answer different questions.

Humans resolve this ambiguity through experience.

AI needs this business meaning to be explicitly available.

This is why semantic understanding is a fundamental requirement for enterprise AI.

Relationships Are the Hidden Challenge

Enterprise data is not a collection of isolated tables.

Business processes connect data together.

A simple example:

Customer

↓

Order

↓

Invoice

↓

Payment

However, real enterprise environments are much more complex.

Organizations often have:

multiple systems;
duplicated entities;
inconsistent identifiers;
historical data models.

A database may allow many possible joins.

But only some relationships represent real business logic.

A technically valid join does not always mean a business-valid relationship.

For AI applications, trusted relationships matter.

Why Bigger LLMs Are Not Enough

A common assumption is:

"If the model becomes smarter, it will solve enterprise data problems."

Better models definitely improve reasoning capabilities.

But models cannot automatically know enterprise-specific knowledge.

They cannot magically determine:

which data source the company trusts;
which metric definition is correct;
which relationship represents the real business process.

The problem is not only intelligence.

The problem is the intelligence available around the data.

Building an AI-Ready Data Intelligence Layer

Reliable enterprise AI requires more than connecting an LLM to a database.

It requires data intelligence capabilities.

Business Entity Understanding

AI needs to understand important business objects:

Customer;
Product;
Supplier;
Contract;
Project.

Not just as database tables.

As business entities.

Data Semantic Understanding

AI needs to understand:

business terms;
metric definitions;
calculation logic;
organizational language.

The same field name can represent different meanings across organizations.

Trusted Data Relationships

AI needs to understand:

which entities are connected;
which relationships are reliable;
which data paths should be used.

This enables AI to generate answers based on trusted enterprise knowledge.

The Future of Enterprise AI Data Architecture

Traditional data platforms answered:

Where is the data?

AI requires a deeper answer:

What does this data mean?

How is it connected?

Can AI trust it?

The next generation of enterprise data architecture will not replace databases, warehouses, or lakes.

Instead, it will add intelligence that makes enterprise data understandable and usable for AI systems.

Final Thoughts

Enterprise AI is not only a model problem.

It is also a data intelligence problem.

Large language models provide reasoning capabilities.

Data intelligence provides the foundation that allows those capabilities to work reliably.

The future of enterprise AI will not only depend on smarter models.

It will depend on smarter data.

Why Enterprise AI Needs Data Semantics and Relationships

ArisynData — Fri, 31 Jul 2026 18:06:00 +0000

Large language models are becoming increasingly powerful.
They can generate SQL, write code, summarize documents, and reason through complex tasks.
However, when enterprises try to deploy AI systems in production, a common problem appears:
AI can access the data.
But it does not always understand the data.
This is where many enterprise AI projects struggle.
The problem is not only model capability.
It is the missing context behind enterprise data.

## The Difference Between Data Access and Data Understanding
Modern data platforms are excellent at storing and processing information.
They provide:
databases;
data warehouses;
data lakes;
metadata catalogs;
BI systems.
From a technical perspective, AI can retrieve:
table names;
column names;
data types;
sample values.
But enterprise questions are rarely only technical questions.
For example:
What are our top customers this year?
A database can show customer-related tables.
But AI still needs to understand:
Which customer definition should be used?
Which system is the authoritative source?
Does customer mean account, buyer, or contract owner?
The missing information is not stored data.
It is business meaning.

## Data Semantics: Teaching AI What Data Means
One of the biggest challenges in enterprise AI is that business concepts are often ambiguous.
Consider the word:
Revenue
An enterprise may have:
sales_amount
invoice_amount
payment_amount
contract_value
All of these contain financial information.
But they represent different business concepts.
A financial analyst understands the difference.
An AI system does not automatically know.
Without semantic understanding, AI may generate a technically valid answer that is still wrong from a business perspective.
The SQL executes successfully.
The business decision fails.

## Data Relationships: The Hidden Complexity Behind Enterprise Data
Enterprise data rarely exists in isolation.
A simple business process may involve:
Customer
↓
Order
↓
Invoice
↓
Payment
But real enterprise environments are much more complicated.
Organizations often have:
multiple customer tables;
different identifiers;
duplicated entities;
historical schemas;
disconnected applications.
Technically, many joins are possible.
Business-wise, only some relationships are meaningful.
This creates an important distinction:
A possible relationship is not always a trusted relationship.

## Why LLMs Cannot Solve This Automatically
A common assumption is:
"If the model becomes smarter, it will understand enterprise data."
But intelligence does not replace missing information.
A powerful LLM can reason about:
A → B → C
But it still needs to know:
What is A?
What does B represent?
Is this relationship valid?
If enterprise knowledge is not explicitly represented, the model has to guess.
And guessing creates unreliable AI.

## Building More Reliable Enterprise AI
Future enterprise AI systems need more than better models.
They need a stronger connection between AI and enterprise knowledge.
This requires three important capabilities.
### 1. Business Entity Understanding
AI needs to understand core business objects:
customers;
products;
suppliers;
contracts;
projects.
Not only as database tables.
As business entities.
### 2. Trusted Relationship Understanding
AI needs to understand how entities connect.
Not every foreign key or possible join represents business logic.
The system needs to identify trusted paths between data.
### 3. Business Semantic Understanding 
AI needs to understand business definitions.
Metrics.
Terms.
Rules.
Context.
Because the same field name can mean different things in different organizations.

## The Next Evolution of Enterprise Data Architecture
Traditional data platforms answered:
Where is the data?
AI requires a different answer:
What does this data mean?
How is it connected?
Can we trust it?
The future enterprise data stack will not replace databases or warehouses.
Instead, it will add a layer that makes enterprise knowledge understandable to AI systems.

## Final Thoughts
The next challenge in enterprise AI is not only building smarter models.
It is reducing the amount of guessing AI has to do.
Data semantics help AI understand meaning.
Data relationships help AI understand connections.
Together, they provide the missing context required for reliable enterprise AI.
Because AI does not only need access to enterprise data.
It needs to understand the business behind it.

I Didn't Break Enterprise Data Models. It Exposed Their Blind Spots.

ArisynData — Wed, 29 Jul 2026 06:19:24 +0000

Over the past few years, I've worked with several enterprise AI projects, especially those involving natural language querying and AI-powered analytics.

One pattern keeps showing up.

When an AI system returns the wrong answer, people usually blame the model.

"Maybe we need a larger LLM."

"Maybe the prompt needs more context."

"Maybe SQL generation isn't mature enough."

After digging into these projects, I came to a different conclusion.

In many cases, the model isn't the real problem.

The enterprise data model is.

Enterprise Data Models Were Never Designed for AI

For decades, enterprise databases have been optimized for applications.

Normalization reduces redundancy.

Indexes improve query performance.

Foreign keys maintain integrity.

Data warehouses organize information for reporting.

Everything makes sense because applications already know how the business works.

Business logic lives in source code, service layers, stored procedures, ETL pipelines, and developers' experience—not necessarily in the database itself.

Applications don't need the database to explain what a "customer" is.

Developers already know.

AI doesn't.

Schema Describes Structure, Not Meaning

Most AI systems start by reading metadata.

They can discover tables.

Columns.

Primary keys.

Sometimes foreign keys.

But metadata only tells AI how data is stored.

It doesn't explain what the data actually represents.

For example, imagine an enterprise with three different systems.

CRM stores customers.

ERP stores accounts.

The finance system stores billing entities.

To employees, these often represent the same business entity viewed from different business processes.

To AI, they are simply three unrelated tables.

Without additional business knowledge, every SQL statement becomes an educated guess.

The Hardest Problem Isn't Writing SQL

Modern language models are surprisingly good at generating SQL.

Syntax errors have become much less common.

The bigger challenge appears earlier.

Before generating SQL, AI must answer questions like:

Which customer table should I use?
Which data source is considered authoritative?
Are these two entities actually the same customer?
Which relationship reflects real business rules?

These aren't SQL problems.

They're knowledge problems.

Business Knowledge Lives Outside the Database

One thing I find interesting is that enterprise knowledge is rarely stored where AI can access it.

Developers understand join paths.

Business analysts understand metric definitions.

Database administrators understand physical schemas.

Domain experts understand the business process.

Each group holds part of the knowledge.

Very little of it is represented explicitly in the data model itself.

Humans bridge these gaps naturally.

AI cannot.

AI Has Become a New Consumer of Enterprise Data

This is probably the biggest architectural change we're seeing.

For years, applications were the only consumers of enterprise databases.

Now AI is becoming another consumer.

Unlike applications, AI doesn't read source code.

It doesn't attend design meetings.

It doesn't ask senior developers which table is "correct."

It only sees what the enterprise has documented.

And many enterprises have documented far less than they assumed.

The Future Isn't About Bigger Models

Large language models will continue to improve.

They'll write better SQL.

Reason more effectively.

Handle longer contexts.

But none of these improvements automatically provide business knowledge.

If an enterprise hasn't clearly defined its business entities, trusted relationships, or business semantics, AI has no reliable foundation to reason from.

The model can infer.

It can estimate.

It can guess.

It cannot know.

Final Thoughts

I don't think AI is exposing weaknesses in language models.

It's exposing weaknesses in enterprise data architecture.

For years, our data models were built to support applications.

Today, they also need to support AI.

That doesn't necessarily mean redesigning every database.

But it does mean making business entities, relationships, and business semantics far more explicit than they have been in the past.

The smarter AI becomes, the more valuable well-structured enterprise knowledge will be.

Foreign Keys Aren't Enough: Why Enterprise AI Needs Relationship Discovery

ArisynData — Mon, 27 Jul 2026 03:15:19 +0000

Modern AI systems are surprisingly good at writing SQL.

Give an LLM a database schema, and it can often generate syntactically correct queries within seconds. With Retrieval-Augmented Generation (RAG), database metadata, and function calling, connecting AI to enterprise databases has become easier than ever.

Yet many enterprise AI projects encounter the same problem after deployment:

The SQL executes successfully, but the answer is still wrong.

This isn't usually a model problem.

It's a relationship problem.

The assumption most AI systems make

Most AI-powered database assistants follow roughly the same workflow:

User Question
      │
      ▼
Schema Retrieval
      │
      ▼
LLM Generates SQL
      │
      ▼
Database Execution
      │
      ▼
Answer

This workflow assumes something important:

The schema contains enough information for AI to understand how data is connected.

Unfortunately, enterprise databases rarely work that way.

Real enterprise databases rarely have complete foreign keys

In tutorials, relationships are simple.

Customer
    │
    ▼
Order
    │
    ▼
Invoice

Every relationship is explicitly defined.

Every foreign key exists.

Every table follows the same modeling standard.

Production systems look very different.

A company may have:

an ERP system
a CRM platform
a financial system
a manufacturing system
a data warehouse
several legacy databases

Each system was designed independently.

Relationships frequently exist without database constraints.

For example:

the same customer appears under different identifiers
order numbers are reused across systems
warehouse codes connect operational databases
contract IDs link finance and sales data
relationships rely on business rules rather than foreign keys

Applications understand these connections because developers encoded them years ago.

The database itself often does not.

Why column names are unreliable

A common strategy is to infer joins from matching field names.

For example:

customer_id

appears in two tables.

Therefore they must be related.

Sometimes that's correct.

Sometimes it's completely wrong.

Likewise,

customer_code

and

account_number

may represent exactly the same business entity even though their names are different.

Enterprise systems evolve over years.

Naming conventions change.

Systems are merged.

Columns are duplicated.

Temporary tables become permanent.

Column names alone cannot describe the real data model.

Relationships exist inside the data

One of the biggest misconceptions is that relationships only exist in metadata.

In reality, much stronger evidence often exists inside the data itself.

Imagine two tables:

Orders

and

Customers

Neither contains a foreign key.

However:

every customer ID appearing in Orders also appears in Customers
Customer IDs are unique in Customers
the inclusion ratio remains stable over time

That combination provides strong evidence that the relationship is real.

Similar signals include:

distinct value overlap
inclusion ratios
uniqueness
composite key candidates
relationship direction
cardinality
value distribution

Unlike naming conventions, these signals come directly from the data.

Discovery is only the first step

Finding candidate relationships is valuable.

Trusting them automatically is dangerous.

Enterprise environments frequently contain multiple possible join paths.

For example:

Customer
   │
Order
   │
Invoice

may be valid.

So may:

Customer
   │
Contract
   │
Invoice

Technically, both queries execute.

Only one answers the business question correctly.

Relationship discovery should therefore be followed by relationship governance.

Organizations need to know:

which relationships were verified
where they came from
how reliable they are
which scenarios they support
which path should be preferred

Without that layer, AI still has to guess.

AI needs a relationship layer

Instead of discovering relationships every time SQL is generated, enterprises should treat relationship knowledge as reusable metadata.

An effective relationship layer can:

detect implicit relationships across databases
discover candidate joins from actual data
measure confidence using statistical evidence
preserve verified relationship paths
expose trusted relationships to AI systems
update relationship knowledge as data evolves

Once this layer exists, AI no longer starts from zero every time it answers a question.

It starts with knowledge accumulated by the organization.

Beyond SQL generation

Enterprise AI discussions often focus on better prompts, larger models, or more powerful agents.

Those improvements certainly matter.

But they cannot compensate for missing relationship knowledge.

A model cannot reliably choose a relationship that has never been made visible.

Better reasoning helps evaluate evidence.

It cannot invent enterprise knowledge that the organization has never captured.

As AI becomes a permanent part of enterprise software, relationship discovery is becoming more than a data engineering task.

It is becoming part of the infrastructure that enables AI to understand how enterprise data actually fits together.

Because in enterprise databases, the most important relationships often aren't missing.

They're simply invisible.

Designing a Production-Grade Text-to-SQL Pipeline

ArisynData — Mon, 13 Jul 2026 07:21:21 +0000

Text-to-SQL demos usually look like this:

Question → LLM → SQL → Result

That is fine for a controlled dataset.

It is not enough for a production system.

In a real warehouse, the model has to deal with duplicated concepts, undocumented joins, multiple date fields, inconsistent naming, and tables that were never designed for AI access.

The hard part is not generating SQL.

The hard part is building the context the model needs before generation.

Start with the question, not the schema

Take a simple request:

Show revenue by customer segment for last quarter.

A model can turn that into SQL quickly. But before it does, the system needs to answer a few basic questions:

Which revenue definition should be used?
Which date field represents the reporting period?
Is customer segment current or historical?
Which customer table is authoritative?
Which join path avoids duplicating revenue?

Those decisions should not be left to the model to guess.

A better pipeline resolves them before SQL generation.

A more realistic workflow

A production flow looks closer to this:

User Question
    ↓
Intent Parsing
    ↓
Semantic Mapping
    ↓
Metadata Retrieval
    ↓
Relationship Discovery
    ↓
Join Path Selection
    ↓
SQL Generation
    ↓
Validation
    ↓
Execution
    ↓
Explanation

Each step has a separate job.

1. Intent parsing

Extract the actual request:

{
  "metric": "revenue",
  "dimension": "customer_segment",
  "time_range": "last_quarter"
}

This is also where the system should detect ambiguity.

For example, “revenue” may refer to booked, invoiced, recognized, or paid revenue.

2. Semantic mapping

Map the user’s language to governed business definitions.

{
  "metric": "recognized_revenue",
  "formula": "SUM(invoice_line.recognized_amount)",
  "time_field": "invoice_line.recognition_date"
}

This prevents the model from choosing fields based only on similar names.

3. Metadata retrieval

Retrieve only the relevant tables and columns.

Passing the entire warehouse schema into the prompt usually creates more noise than value.

The model should receive a narrow working set:

customer
customer_segment_history
invoice
invoice_line

4. Relationship discovery

This is where many systems remain weak.

Foreign keys are useful, but enterprise databases often have missing, incomplete, or misleading constraints.

A relationship layer should provide more than table names. It should include:

source and target columns
relationship direction
cardinality
confidence
known fanout risk
preferred usage

For example:

{
  "from": "invoice.customer_id",
  "to": "customer.customer_id",
  "cardinality": "many_to_one",
  "confidence": 0.98,
  "fanout_risk": false
}

5. Join path selection

There may be several valid paths between the same business entities.

The shortest path is not always the safest one.

A good system should prefer a path that matches the query grain and metric definition, not just one that happens to connect the tables.

For the revenue example, joining directly to a current customer table may produce a valid result but lose historical segment accuracy.

The correct path may require a segment history table and an effective-date condition.

Validation has to be explicit

SQL execution is not validation.

A query can run successfully and still return the wrong answer.

At minimum, the validation stage should check:

- Are the selected tables approved for this metric?
- Does the join path match the required grain?
- Can the join duplicate fact rows?
- Are filters applied to the correct date field?
- Are permissions respected?
- Is the aggregation consistent with the metric definition?

Some checks are static. Others require running a small test query.

For example, a join can be tested for row multiplication before the final query is executed.

SELECT
    COUNT(*) AS rows_before,
    COUNT(DISTINCT invoice_line.id) AS distinct_rows
FROM invoice_line
JOIN customer
  ON invoice_line.customer_id = customer.customer_id;

If those numbers drift unexpectedly, the pipeline should stop.

Clarification is part of the system

One of the most useful behaviors in Text-to-SQL is asking a question instead of generating one.

Do you mean recognized revenue or invoiced revenue?

That is not a failure.

It is often the safest possible response.

A production system should know when the available semantic or relationship context is not strong enough to proceed.

Keep the reasoning visible

The final response should include more than the result.

A useful explanation might show:

Metric: Recognized Revenue
Time Field: recognition_date
Tables Used: invoice_line, customer_segment_history
Join Path: invoice_line.customer_id → customer_segment_history.customer_id
Validation: No fanout detected

That gives analysts a chance to review the logic and gives data teams something they can audit.

The model is not the whole pipeline

The LLM is still important. It can parse questions, generate SQL, explain results, and handle conversation.

But production reliability comes from the surrounding system:

Semantic context
+ Metadata
+ Trusted relationships
+ Validation
+ Governance

That is the difference between a query that looks reasonable and a query that can be trusted.

At Arisyn, we split those responsibilities across two layers: Semora handles business semantics, query reasoning, SQL generation, validation, and explanation, while IntaLink provides the table and field relationship context needed to choose safer data paths.

The SQL is generated near the end.

Most of the real work happens before it.

Enterprise Databases Were Built for Applications, Not AI

ArisynData — Fri, 10 Jul 2026 16:09:00 +0000

As engineers, we spend a lot of time talking about AI models.

Which model generates better SQL?

Which model reasons better?

Which one has the largest context window?

But after working with enterprise data, I've started to think we're looking in the wrong place.

Most enterprise databases were never designed for AI.

They were designed for applications.

## Applications Know the Rules. AI Doesn't.

A business application already knows where everything is.

If an order needs a customer record, the developer has already defined the relationship.

If a dashboard needs revenue, someone has already decided which calculation to use.

The application doesn't need to discover anything.

AI does.

When an LLM connects to an enterprise database, all it sees is hundreds of tables and thousands of columns.

It has no idea:

Which customer table is authoritative.
Which tables are safe to join.
Whether two IDs represent the same business entity.
Which revenue definition the business actually uses.

Generating SQL isn't the difficult part anymore.

Choosing the right data is.

*## Schemas Describe Structure, Not Business Knowledge
*
Even well-designed databases have this problem.

A schema tells you that a table exists.

It doesn't tell you:

why it exists,
when it should be used,
or whether another table has replaced it over time.

The knowledge that engineers build up over years of maintaining a system rarely exists inside the database itself.

It's stored in documentation, meeting notes, old dashboards—or simply in someone's head.

That's exactly the information AI is missing.

## Two Things Make Enterprise Data More Understandable

In my experience, AI becomes much more reliable when two gaps are addressed.

First, data relationships.

AI needs to know how tables, fields, and business entities are connected—not just through foreign keys, but through relationships that have been verified across real enterprise systems. Discovering and validating those relationships is the foundation of platforms like Arisyn-IntaLink. :contentReference[oaicite:0]{index=0}

Second, business semantics.

Even after the right data is found, AI still needs to understand what that data means. Shared metric definitions, business terminology, and governed semantic rules help ensure that "Revenue" or "Customer" means the same thing to everyone. That's exactly the role of a semantic layer such as Arisyn-Semora. :contentReference[oaicite:1]{index=1}

Relationships explain how data is connected.

Semantics explain what the data means.

AI needs both.

## Final Thoughts

I don't think enterprise AI is limited by SQL generation anymore.

The bigger challenge is helping AI understand enterprise data the way experienced engineers do.

The better we capture relationships and business semantics, the less AI has to guess.

And in enterprise systems, fewer guesses almost always lead to better decisions.