Semantic Definitions Are Not Enough Without Relationship Context

## What Semantic Definitions Solve

A semantic definition gives business meaning to data.

For example, a company may define **customer lifetime value** as:

> Total recognized revenue from a customer over a defined period, minus eligible refunds and credits, grouped by the approved customer region.

This definition may include:

- metric name;

- business description;

- approved formula;

- source fields;

- allowed dimensions;

- default filters;

- aggregation rules;

- owner;

- version;

- access restrictions.

This is valuable because AI should not invent metric logic from column names.

If a user asks:

> What is customer lifetime value by region last quarter?

The AI system needs to understand what “customer lifetime value,” “region,” and “last quarter” mean before it writes SQL.

A governed semantic layer can provide that context.

But the SQL still needs something else.

It needs the right join path.

---

## Where Semantic Definitions Stop

A semantic definition may tell AI:

- which metric to calculate;

- which fields are involved;

- which dimensions are allowed;

- which time logic applies;

- which business definition is approved.

But it may not fully answer:

- which tables should be joined;

- which path connects customers, orders, refunds, and regions;

- whether a direct join is allowed;

- whether a bridge table is required;

- whether the join creates duplicate rows;

- whether the path is approved for this metric;

- whether there are multiple valid paths for different use cases.

This is where relationship context becomes necessary.

A metric definition can explain **what** to calculate.

Relationship context explains **how** to connect the data correctly.

---

## A Simple Example

Consider this question:

> What is customer lifetime value by region last quarter?

The semantic layer may correctly identify:

- Metric: customer lifetime value

- Dimension: region

- Time period: last quarter

- Revenue source: orders

- Refund adjustment: refunds

That sounds complete, but the AI still needs to know how these objects connect.

Possible paths may include:

1. `customers → orders → refunds → regions`

2. `customers → accounts → orders → billing_regions`

3. `orders → billing_accounts → region_mapping`

4. `customers → sales_territories → regions`

Each path may produce a different result.

The correct path depends on the company’s business logic. For example:

- customer profile region may not equal billing region;

- sales territory may not equal reporting region;

- refunds may need to be joined through orders, not customers;

- account-level relationships may be required for enterprise customers;

- bridge tables may be needed to avoid duplicate counts.

If AI only has the semantic definition but not the approved relationship path, it may still guess.

And a guessed join can break the answer.

---

## Why This Matters for AI-Generated SQL

Many AI-generated SQL errors are not obvious syntax errors.

The SQL runs. The result looks reasonable. The chart renders. The answer appears useful.

But the logic may be wrong because:

- the AI joined tables through the wrong path;

- the AI used a many-to-many relationship without handling fanout;

- the AI used a current dimension for a historical metric;

- the AI joined fields with similar names but different meanings;

- the AI ignored a required intermediate table;

- the AI used a relationship that is common but not approved.

This is dangerous because the error is hidden inside the relationship logic.

A semantic definition may prevent AI from using the wrong formula.

Relationship context helps prevent AI from using the wrong data path.

---

## Semantic Context and Relationship Context Are Complementary

A reliable AI query workflow needs both layers.

| Question AI must answer | Context needed |

|---|---|

| What does this business term mean? | Semantic context |

| Which metric definition is approved? | Semantic context |

| Which fields represent the metric? | Semantic context |

| Which tables contain the required data? | Semantic + relationship context |

| How should the tables be connected? | Relationship context |

| Which join path is trusted? | Relationship context |

| Can this user access the result? | Policy context |

| Can the answer be explained? | Lineage context |

Semantic context gives AI business meaning.

Relationship context gives AI structural truth.

Policy and lineage context make the final SQL governable and explainable.

---

## What Good Relationship Context Should Provide

For AI-generated SQL, relationship context should not be a simple list of foreign keys.

It should help the system understand:

- candidate relationships;

- validated relationships;

- join keys;

- relationship type;

- cardinality;

- confidence score;

- evidence sources;

- approved join paths;

- risky or deprecated paths;

- many-to-many or fanout warnings;

- lineage back to metadata, SQL history, or BI logic.

This allows AI to choose the right path, avoid unsafe joins, and explain why a specific SQL query was generated.

---

## When AI Should Ask Instead of Guess

Sometimes semantic and relationship context are still not enough to answer safely.

For example:

- two region definitions may be valid;

- multiple join paths may have similar confidence;

- a relationship may be low-confidence;

- the metric may be approved, but not for the requested dimension;

- the user may not have access to required fields.

In these cases, the correct AI behavior is not to generate SQL immediately.

The system should ask a clarifying question or surface the uncertainty.

For enterprise AI, “I need clarification” is often safer than a confident but wrong answer.

---

## What Data Teams Should Prepare

Teams building AI-generated SQL should not treat semantic modeling and relationship discovery as separate projects.

They should connect them around the questions users actually ask.

A practical starting point is to define:

1. the top business metrics users ask about;

2. the approved definitions for those metrics;

3. the tables and fields involved;

4. the trusted join paths for each metric;

5. dimensions that are allowed or restricted;

6. relationships that create duplicate-counting risk;

7. policies that apply before SQL generation;

8. lineage needed to explain the final answer.

This creates a query context layer that AI can use before generating SQL.

---

## Where Arisyn Fits

Arisyn is designed to combine semantic context and relationship context for AI-generated SQL.

**Semora** maps business terms, metrics, dimensions, formulas, and approved logic to governed data fields.

**IntaLink** helps discover, validate, score, and govern table relationships and trusted join paths.

Together, they help AI agents, NL2SQL workflows, and BI tools understand both:

- what the business question means;

- how the data should be connected.

The goal is not to replace the warehouse, BI tools, semantic layer, or data catalog. The goal is to provide governed query context before AI writes SQL.

---

## Final Thought

Semantic definitions help AI understand business meaning.

But business meaning is only half of the problem.

To generate reliable SQL, AI also needs trusted relationship context: which tables to use, how they connect, which paths are approved, and which joins should be avoided.

A semantic layer can tell AI what the answer should mean.

A relationship layer helps AI reach the answer correctly.

For enterprise AI, trusted SQL requires both.