DEV Community

Arisyn
Arisyn

Posted on

What Makes Enterprise Data AI-Readable?

#ai #data #llm #sql

A schema tells an AI what exists. It does not tell the AI what the data means, how it should be connected, or when it should not be used.

For decades, enterprise databases have been designed primarily for developers, data engineers, and analysts.

That design worked because humans supplied the missing context.

An experienced analyst knows that invoice_amount is not the same as recognized revenue.

A data engineer knows that two tables should not be joined directly even though their IDs look compatible.

A finance team knows that created_at is an operational timestamp while financial reporting should use settlement_date.

None of this knowledge has to exist in the physical schema for humans to work effectively.

AI agents change that assumption.

If an agent is expected to query enterprise data directly, the data model must communicate much more than:

table
column
type
Enter fullscreen mode Exit fullscreen mode

The real engineering question becomes:

What information does an AI system need before enterprise data becomes reliably usable?

I think the answer is larger than schema retrieval and embeddings.

A useful model is:

AI-Readable Data
=
Meaning
+
Structure
+
Relationships
+
Usage Rules
+
Trust
Enter fullscreen mode Exit fullscreen mode

## 1. Machine-Readable Is Not AI-Readable

Consider this schema:

CREATE TABLE sales_order (
    order_id      BIGINT,
    customer_id   BIGINT,
    total_amount  DECIMAL(18,2),
    created_at    TIMESTAMP,
    status        VARCHAR(20)
);
Enter fullscreen mode Exit fullscreen mode

A model can parse it.

It knows that total_amount is numeric and created_at is temporal.

But it still does not know:

Does total_amount include tax?

Are cancelled orders included?

Is total_amount order value or recognized revenue?

Should created_at be used for financial reporting?

How does customer_id map across CRM and ERP?

Can this table be joined directly to invoice?
Enter fullscreen mode Exit fullscreen mode

The schema describes structure.

Enterprise analytics requires usage context.

That gap is where many AI data failures begin.

## 2. Descriptions Help, but They Do Not Solve the Problem

A common improvement is to add table and column descriptions:

table: sales_order

columns:
  total_amount:
    type: decimal
    description: Total amount of the sales order.

  created_at:
    type: timestamp
    description: Time when the order was created.
Enter fullscreen mode Exit fullscreen mode

This is useful metadata.

But now ask:

What was revenue last quarter?

The description still does not tell the model whether total_amount should be used as Revenue.

A technically accurate description can still be insufficient for analytical reasoning.

The missing information is not:

What is this column?
Enter fullscreen mode Exit fullscreen mode

It is:

When is this column valid for a business question?
Enter fullscreen mode Exit fullscreen mode

## 3. Meaning Should Be Explicit

Suppose the warehouse contains:

sales_order.total_amount
invoice.invoice_amount
finance_revenue.recognized_amount
payment.received_amount
Enter fullscreen mode Exit fullscreen mode

All four fields may be retrieved for the word:

Revenue
Enter fullscreen mode Exit fullscreen mode

Embedding similarity is doing exactly what it should.

The fields are semantically related.

But enterprise AI needs a stronger object:

metric:
  id: revenue
  name: Revenue
  version: 2.1

  definition:
    business_term: Recognized Revenue
    aggregation: SUM

  source:
    table: finance_revenue
    column: recognized_amount

  time:
    field: recognition_date
Enter fullscreen mode Exit fullscreen mode

This changes the problem from:

Which revenue-like field should the model choose?
Enter fullscreen mode Exit fullscreen mode

to:

Retrieve the governed Revenue definition.
Enter fullscreen mode Exit fullscreen mode

That is a much more reliable operation.

## 4. Relationships Need to Be First-Class Context

Even perfect semantic definitions are not enough for multi-table analytics.

Suppose a user asks:

Which customers have unpaid invoices?

The system may need:

Customer
   ↓
Order
   ↓
Invoice
   ↓
Payment
Enter fullscreen mode Exit fullscreen mode

But real enterprise schemas often do not contain complete foreign keys.

A relationship may exist because:

order.customer_id
Enter fullscreen mode Exit fullscreen mode

and:

customer.customer_id
Enter fullscreen mode Exit fullscreen mode

share values.

One useful relationship signal is inclusion:

Inclusion(A → B)
=
|distinct(A) ∩ distinct(B)|
---------------------------
|distinct(A)|
Enter fullscreen mode Exit fullscreen mode

where:

A = order.customer_id
B = customer.customer_id
Enter fullscreen mode Exit fullscreen mode

If the inclusion ratio is high and B has high uniqueness, the system has evidence for a possible reference relationship.

Relationship discovery can combine:

Database Constraints
Column Names
Value Inclusion
Uniqueness
Business Validation
Enter fullscreen mode Exit fullscreen mode

Then relationships can move through states:

Discovered
    ↓
Candidate
    ↓
Validated
    ↓
Trusted
Enter fullscreen mode Exit fullscreen mode

At query time, the AI should prefer trusted relationships instead of reconstructing joins from scratch.

## 5. Positive Knowledge Is Only Half the Model

Most semantic systems are good at representing positive knowledge:

Revenue uses recognized_amount.
Enter fullscreen mode Exit fullscreen mode

But production systems also need negative knowledge:

Do NOT use invoice_amount as Revenue.
Enter fullscreen mode Exit fullscreen mode

That distinction is more important than it looks.

Imagine:

field:
  table: sales_order
  name: total_amount

usage:
  valid_for:
    - order_value
    - sales_volume

  invalid_for:
    - recognized_revenue
    - cash_collection
Enter fullscreen mode Exit fullscreen mode

Now the system knows both:

What this field can answer.
Enter fullscreen mode Exit fullscreen mode

and:

What this field must not answer.
Enter fullscreen mode Exit fullscreen mode

Humans use this kind of knowledge constantly.

We say:

Don't use that table for finance.

Don't join those tables directly.

Don't use created_at for reporting.

That field looks like customer_id, but it is actually account_id.

These constraints often exist only as tribal knowledge.

For AI systems, they should become structured context.

## 6. Why Negative Knowledge Matters for Retrieval

Suppose a vector search for:

customer revenue
Enter fullscreen mode Exit fullscreen mode

returns:

sales_order.total_amount       score 0.91
invoice.invoice_amount         score 0.89
finance_revenue.recognized_amount score 0.87
Enter fullscreen mode Exit fullscreen mode

A naive retrieval pipeline might choose the highest score.

But relevance is not authority.

If the governed context says:

sales_order.total_amount
invalid_for: recognized_revenue
Enter fullscreen mode Exit fullscreen mode

the retrieval system can exclude or penalize that candidate.

Conceptually:

def rank_candidate(candidate, query_context):
    score = candidate.semantic_similarity

    if candidate.is_authoritative_for(query_context.metric):
        score += AUTHORITY_BONUS

    if candidate.is_invalid_for(query_context.metric):
        score -= INVALID_USAGE_PENALTY

    return score
Enter fullscreen mode Exit fullscreen mode

The important shift is that retrieval is no longer based only on similarity.

It becomes:

Similarity
+
Business Validity
+
Trust
+
Usage Constraints
Enter fullscreen mode Exit fullscreen mode

## 7. Usage Rules Should Be Machine-Consumable

A free-text description such as:

This table is generally used for order reporting and should normally not be used for financial revenue reporting.

is useful to humans.

For AI systems, structured rules are easier to enforce:

table: sales_order

valid_for:
  - order_analysis
  - sales_pipeline

invalid_for:
  - recognized_revenue
  - financial_close

preferred_time_field:
  order_analysis: created_at

constraints:
  - exclude_cancelled_orders
Enter fullscreen mode Exit fullscreen mode

This does not mean every business rule must become rigid YAML.

Some rules remain contextual.

But high-value, frequently reused constraints should be represented in a form tools and agents can consume deterministically.

## 8. Trust Signals Resolve Competing Context

Enterprise systems frequently contain multiple definitions.

For example:

Revenue v1.8
Revenue v2.0
Revenue v2.1
Enter fullscreen mode Exit fullscreen mode

Or several candidate relationships:

Customer → Order
Customer → Account → Order
Customer → Contract → Order
Enter fullscreen mode Exit fullscreen mode

An AI-readable context needs signals that help select among them.

For example:

metric:
  id: revenue
  version: 2.1
  status: active
  owner: finance
  effective_from: 2026-01-01
  validated: true
Enter fullscreen mode Exit fullscreen mode

A relationship might include:

relationship:
  id: rel_customer_account
  status: trusted
  confidence: 0.97
  validated_by: data_governance
Enter fullscreen mode Exit fullscreen mode

Now retrieval can distinguish:

Relevant
Enter fullscreen mode Exit fullscreen mode

from:

Relevant + Authoritative
Enter fullscreen mode Exit fullscreen mode

That difference matters in production.

## 9. AI-Readable Context Can Be Built as a Data Object

A richer representation for a field might look like:

field:
  table: sales_order
  name: total_amount
  type: decimal

meaning:
  business_term: Order Value
  description: Confirmed sales order value

structure:
  nullable: false
  distinct_ratio: 0.84

relationships:
  - target: customer.customer_id
    via: sales_order.customer_id
    status: trusted

usage:
  valid_for:
    - order_analysis
    - sales_volume

  invalid_for:
    - recognized_revenue
    - cash_received

trust:
  owner: sales_operations
  status: active
  validated: true
Enter fullscreen mode Exit fullscreen mode

This object contains far more actionable context than:

total_amount DECIMAL
Enter fullscreen mode Exit fullscreen mode

or even:

Total amount of the sales order.
Enter fullscreen mode Exit fullscreen mode

## 10. Build Query Context From AI-Readable Objects

Once these objects exist, query-time context construction becomes more reliable.

Suppose the question is:

Show recognized revenue by customer for last quarter.

A context builder could resolve:

Business Metric
→ Revenue v2.1

Dimension
→ Customer

Relevant Sources
→ finance_revenue
→ customer

Trusted Relationship
→ finance_revenue.customer_id
→ customer.customer_id

Time Field
→ recognition_date

Excluded Candidates
→ sales_order.total_amount
→ invoice.invoice_amount
Enter fullscreen mode Exit fullscreen mode

The resulting model context can be compact:

metric:
  name: Revenue
  source: finance_revenue.recognized_amount
  aggregation: SUM

dimension:
  name: Customer
  source: customer.customer_name

relationship:
  finance_revenue.customer_id -> customer.customer_id

time_field:
  finance_revenue.recognition_date

do_not_use:
  - sales_order.total_amount
  - invoice.invoice_amount
Enter fullscreen mode Exit fullscreen mode

The LLM no longer needs to infer the enterprise model from raw schema.

It receives an instruction-ready representation.

## 11. This Is More Than RAG

A standard RAG pipeline looks like:

Question
   ↓
Embedding
   ↓
Retrieve Relevant Context
   ↓
LLM
Enter fullscreen mode Exit fullscreen mode

An AI-readable data layer introduces additional steps:

Question
   ↓
Resolve Business Concepts
   ↓
Retrieve Relevant Data Objects
   ↓
Apply Usage Constraints
   ↓
Prefer Trusted Definitions
   ↓
Resolve Relationships
   ↓
Build Query Context
   ↓
LLM
Enter fullscreen mode Exit fullscreen mode

The goal is not merely:

Find context.
Enter fullscreen mode Exit fullscreen mode

It is:

Find context that is valid for this analytical task.
Enter fullscreen mode Exit fullscreen mode

## 12. AI-Readable Data Should Be Model-Independent

One architectural mistake is putting all of this context inside a model-specific system prompt.

For example:

If user asks Revenue, use table X.
Never join A directly to B.
For finance reporting use settlement_date.
...
Enter fullscreen mode Exit fullscreen mode

That works initially.

But the knowledge becomes coupled to one agent implementation.

A better architecture keeps enterprise data knowledge outside the model:

AI Agent
    ↓
Context Resolver
    ↓
AI-Readable Data Layer
    ↓
Enterprise Data
Enter fullscreen mode Exit fullscreen mode

Then different agents can consume the same knowledge:

Sales Agent
Finance Agent
Analytics Agent
Operations Agent
Enter fullscreen mode Exit fullscreen mode

The model can change without rebuilding the enterprise's data understanding.

## 13. AI-Readable Data Needs a Lifecycle

This context cannot be static.

Schemas change.

Metrics change.

Relationships change.

Usage rules change.

So the system needs:

Discover
   ↓
Validate
   ↓
Publish
   ↓
Monitor
   ↓
Detect Change
   ↓
Update
Enter fullscreen mode Exit fullscreen mode

For example, if:

Revenue v2.1
Enter fullscreen mode Exit fullscreen mode

becomes:

Revenue v2.2
Enter fullscreen mode Exit fullscreen mode

the old version should not silently disappear.

Historical queries may still need to be reproduced.

The same applies to relationships and usage constraints.

## 14. A Practical Architecture

One possible design:

                Enterprise Data
                      │
                      ▼
          ┌─────────────────────┐
          │ Metadata Extraction │
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Relationship        │
          │ Discovery           │
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Semantic / Metric   │
          │ Governance          │
          └──────────┬──────────┘
                     │
          ┌──────────▼──────────┐
          │ Usage Rules &       │
          │ Negative Knowledge  │
          └──────────┬──────────┘
                     │
                     ▼
          AI-Readable Data Objects
                     │
                     ▼
              Context Resolver
                     │
                     ▼
                 AI Agent
Enter fullscreen mode Exit fullscreen mode

The point is not that every implementation needs these exact services.

The important idea is the separation between:

Raw Enterprise Data
Enter fullscreen mode Exit fullscreen mode

and:

Context AI Can Reliably Use
Enter fullscreen mode Exit fullscreen mode

## 15. What Should Be Measured?

If AI-readability becomes a real engineering objective, teams can measure it.

Possible metrics include:

Semantic Coverage 

% of important tables / fields mapped to business concepts
Enter fullscreen mode Exit fullscreen mode

Relationship Coverage 

% of frequently queried multi-table paths represented as validated relationships
Enter fullscreen mode Exit fullscreen mode

Usage Rule Coverage 

% of high-value data objects with explicit valid / invalid usage
Enter fullscreen mode Exit fullscreen mode

Trusted Context Resolution Rate 

% of queries where metric + sources + relationships
are resolved without free-form LLM inference
Enter fullscreen mode Exit fullscreen mode

Negative Constraint Hit Rate 

How often invalid candidates are removed
because of explicit usage constraints
Enter fullscreen mode Exit fullscreen mode

These metrics move the conversation from:

Our documentation is better.

to:

Our data is increasingly usable by AI systems.

## 16. The New Definition of Data Readiness

Traditional data readiness asks:

Is the data available?
Is it clean?
Is it integrated?
Is it documented?
Enter fullscreen mode Exit fullscreen mode

AI adds another requirement:

Can an AI determine:
- what the data means,
- how it connects,
- when it is valid,
- when it is invalid,
- and why it should be trusted?
Enter fullscreen mode Exit fullscreen mode

That is a much stronger definition.

## Final Thoughts

Enterprise AI is exposing a problem that humans have hidden for years.

Our data models often depend on undocumented organizational knowledge.

Experienced people know:

which field to use,
which table not to use,
which relationship is valid,
which timestamp matters,
which definition is authoritative.
Enter fullscreen mode Exit fullscreen mode

AI does not automatically know any of that.

So the goal should not be merely to give AI access to more schemas.

The goal should be to make enterprise data AI-readable.

That means representing:

Meaning
Structure
Relationships
Usage Rules
Trust
Enter fullscreen mode Exit fullscreen mode

And especially the knowledge most systems still ignore:

What the AI should not do with the data.

Sometimes the difference between a demo and a production data agent is not another model upgrade.

It is one critical piece of enterprise knowledge:

Don't use this data that way.

Top comments (0)