Your Data Is Your AI Engineer: Why Schema Quality Determines AI ROI for SQL Server Teams

---

There is a recurring conversation happening in organizations that have deployed AI tools against their SQL Server databases. The AI is inconsistent. Some queries come back correct, some come back plausible-looking but wrong, and nobody can reliably predict which one they will get. The instinct is to blame the prompt, so teams invest time in refining their questions, adding more context, and experimenting with different phrasing. The results improve slightly and then plateau.

The problem is not the prompt. The problem was there long before the AI arrived. It is in the database itself: in the column names that made sense to the developer who created them in 2019 but mean nothing to anyone reading them fresh, in the tables with no description, in the status codes with values 1 through 7 and no documentation of what each value means, in the business rules that exist only in the heads of two people on the finance team.

Phil Schmid of Hugging Face published a widely-read analysis in 2025 making the case that most AI agent failures are not prompt failures. They are context failures. The AI received the wrong information, incomplete information, or information it could not interpret correctly, and produced a result that reflected that poor context. No amount of rephrasing the question fixes a system that provides the wrong context to the model.

For SQL Server teams, that context comes from your schema. Your schema is your AI engineer. If it is well-documented, the AI generates correct SQL on the first attempt. If it is undocumented, the AI guesses and guesses confidently.

1 How an LLM Actually Reads Your Database Beginner

When an AI tool connects to your SQL Server database through MCP or a direct integration, it does not have access to your data rows. It reads your schema. It reads your table names, your column names, your data types, your relationships, and any extended property documentation you have added. From those raw schema objects it builds an understanding of what your database contains and what the data means.

That process is called context assembly. Before the AI answers any question about your data, it assembles a description of the relevant tables and columns and passes that description to the language model as context alongside the user’s question. The quality of the answer depends entirely on the quality of that assembled context.

If the context says “table: Orders, columns: id, cust_id, amt, flg1, flg2, dt1, dt2” the AI has almost nothing to work with. It knows there is a table called Orders with some numeric columns and two dates. It will generate SQL that might be structurally correct but will guess at what flg1 means and whether dt1 is the order date or the ship date.

If the context says “table: Orders, columns: OrderID (primary key, integer), CustomerID (foreign key to Customers.CustomerID), OrderTotalUSD (decimal, the total order value in US dollars excluding tax), IsShipped (bit, 1 when the order has shipped), IsCancelled (bit, 1 when the order was cancelled by the customer), OrderDate (datetime2, when the order was placed), ShipDate (datetime2, NULL until the order ships)” the AI can generate correct SQL on the first attempt for almost any reasonable question about orders.

The difference between those two outcomes is not the prompt. It is the schema documentation.

2 Why Undocumented Schemas Produce Wrong Answers Beginner

The Garbage In, Garbage Out principle has been true of database systems since the first database was built. What changes with generative AI is the speed and confidence of the output. A traditional query against a misnamed column produces an obviously wrong result. An AI query against an undocumented column produces a confidently wrong result that looks correct until someone with domain knowledge examines it.

Here are the specific failure modes that undocumented schemas introduce:

Ambiguous Column Names

A column named Status appears in dozens of tables across most production databases. Without documentation, the AI cannot know that Status in the Orders table means shipment status, Status in the Customers table means account standing, and Status in the Jobs table means processing state. It will guess based on context and will sometimes be wrong.

Undocumented Status Codes

A column named OrderStatusID with values 1 through 6 is better than a column named flg1 but it is still incomplete. The AI does not know that value 5 means Delivered and value 6 means Returned. If a user asks “show me revenue from completed orders,” the AI must guess which status values represent completed. It might use 4 and 5. The correct answer might be 5 only. The result is wrong revenue figures with no error message.

Missing Business Rules

Many databases have implicit business rules that are not reflected in the schema: rows with IsDeleted = 1 should never appear in reports, only records from the current fiscal year are relevant for performance metrics, certain customer tiers have different pricing rules. These rules are applied correctly by experienced developers who learned them over time. They are completely invisible to an AI assembling context from schema objects alone.

Misleading Table Names

Legacy databases accumulate tables whose names no longer reflect their actual contents. A table created as TempCustomerData in 2017 for a migration project became a permanent customer reference table. An AI reading the table name will assume it contains temporary or non-authoritative data and may deprioritize it or ignore it entirely when a more authoritative-sounding table exists.

3 The Context Assembly Problem Is a Data Problem Beginner

Phil Schmid’s context engineering analysis makes a point that resonates directly with the DBA’s role. He argues that the term “prompt engineering” misdirects attention toward the phrasing of queries when the real investment should go into how context is assembled, ordered, and filtered before the query reaches the model. For SQL Server teams, context assembly is a schema and metadata problem, not an AI problem.

The organizations that get reliable AI results from their databases are not the ones that hired the most skilled prompt writers. They are the ones whose data teams invested in making the database self-describing. Their tables have descriptions. Their columns have names that communicate intent. Their status codes have documented values. Their business rules are written into extended properties so any tool reading the schema can access them.

Andrew Ng made a related observation in his May 2026 Batch newsletter when discussing Forward Deployed Engineers, the specialists organizations embed to make AI tools work against their actual data. His point was that these engineers are often solving data foundation problems that nobody fixed upstream. The strategic implication is that every hour spent by an embedded specialist translating messy schema into usable AI context is an hour that would have been unnecessary if the schema had been documented properly in the first place.

For SQL Server DBAs this reframes the job description. Maintaining schema documentation is not bureaucratic overhead. It is AI infrastructure. The extended properties you write today are the context that your AI tools will use tomorrow, and the day after, and for every tool that connects to this database in the future regardless of what it is.

4 Extended Properties: The Mechanism You Already Have Beginner

SQL Server has stored documentation inside the database since SQL Server 2000 through the extended properties system. Most DBAs know extended properties exist. Few use them consistently. In 2026, the reason to use them has changed from “it is good practice” to “it directly determines whether your AI tools work correctly.”

Extended properties attach metadata to any database object: tables, columns, schemas, indexes, stored procedures, functions, views. The metadata is stored inside the database and survives backup and restore. It is readable by any tool with access to the database through sys.extended_properties and the fn_listextendedproperty function. MCP servers and AI integrations built for SQL Server read this data automatically as part of context assembly.

-- Add documentation to a table
EXEC sys.sp_addextendedproperty
    @name  = N'MS_Description',
    @value = N'Core order header table. Contains one row per customer order.
               For revenue reporting use only rows where IsCancelled = 0.
               OrderTotalUSD excludes tax. See OrderTax table for tax amounts.
               Soft deletes are not used -- cancelled orders remain with IsCancelled = 1.',
    @level0type = N'SCHEMA', @level0name = N'dbo',
    @level1type = N'TABLE',  @level1name = N'Orders';

-- Add documentation to a column with status code values
EXEC sys.sp_addextendedproperty
    @name  = N'MS_Description',
    @value = N'Order processing status.
               1 = Draft (not yet submitted by customer)
               2 = Submitted (awaiting processing)
               3 = Processing (in fulfillment)
               4 = Shipped (dispatched, awaiting delivery confirmation)
               5 = Delivered (confirmed received by customer)
               6 = Cancelled (cancelled by customer or support)
               For revenue reports: include only status 5 (Delivered).
               For active order counts: include status 2, 3, and 4.',
    @level0type = N'SCHEMA', @level0name = N'dbo',
    @level1type = N'TABLE',  @level1name = N'Orders',
    @level2type = N'COLUMN', @level2name = N'OrderStatusID';

-- Update an existing extended property
EXEC sys.sp_updateextendedproperty
    @name  = N'MS_Description',
    @value = N'Updated description here',
    @level0type = N'SCHEMA', @level0name = N'dbo',
    @level1type = N'TABLE',  @level1name = N'Orders',
    @level2type = N'COLUMN', @level2name = N'OrderStatusID';

-- Read all extended properties for a table
SELECT
    ep.name                             AS PropertyName,
    CASE ep.minor_id
        WHEN 0 THEN 'Table'
        ELSE c.name
    END                                 AS ObjectOrColumn,
    ep.value                            AS Description
FROM sys.extended_properties ep
LEFT JOIN sys.columns c
    ON  c.object_id = ep.major_id
    AND c.column_id = ep.minor_id
WHERE ep.major_id = OBJECT_ID('dbo.Orders')
AND   ep.name = 'MS_Description'
ORDER BY ep.minor_id;

5 What Good Schema Documentation Looks Like Beginner

Good documentation is not long documentation. It is precise documentation that tells the reader, and the AI, exactly what they need to know to use the object correctly. Here is the difference in practice:

What Every Table Description Should Include

• What the table contains in one sentence
• Any mandatory filters for correct results (soft delete flags, status filters, date range requirements)
• What related tables to use for specific use cases
• Any known data quality issues or limitations

What Every Column Description Should Include

• What the column represents in plain business language
• For status and type columns: every possible value and what it means
• Units for numeric columns (USD, kg, minutes, percentage)
• Whether NULL is meaningful or indicates missing data
• Any business rules that depend on this column

-- Example: documenting a financial column with units and rules
EXEC sys.sp_addextendedproperty
    @name  = N'MS_Description',
    @value = N'Total order value in US dollars, excluding sales tax and shipping.
               Stored as DECIMAL(18,2). Never NULL -- defaults to 0.00 for zero-value orders.
               For gross revenue calculations use this column.
               For net revenue subtract the corresponding row in dbo.OrderDiscounts.
               Do not sum this column across orders with OrderStatusID = 6 (Cancelled).',
    @level0type = N'SCHEMA', @level0name = N'dbo',
    @level1type = N'TABLE',  @level1name = N'Orders',
    @level2type = N'COLUMN', @level2name = N'OrderTotalUSD';

-- Example: documenting a foreign key with usage guidance
EXEC sys.sp_addextendedproperty
    @name  = N'MS_Description',
    @value = N'Foreign key to dbo.Customers.CustomerID.
               Always join to dbo.Customers to get customer name, tier, and region.
               Never NULL -- all orders must belong to an active customer account.
               Customers marked IsActive = 0 may still have orders in history.',
    @level0type = N'SCHEMA', @level0name = N'dbo',
    @level1type = N'TABLE',  @level1name = N'Orders',
    @level2type = N'COLUMN', @level2name = N'CustomerID';

6 The Documentation Audit: Finding Your Gaps Beginner

Before starting a documentation effort, understand the current state. Most production databases have documentation on fewer than 20 percent of their objects. Start with the tables and columns your AI tools are most likely to query and work outward from there.

-- ============================================================
-- DOCUMENTATION COVERAGE AUDIT
-- See what percentage of your database is documented
-- ============================================================

-- Table-level documentation coverage
SELECT
    t.name                              AS TableName,
    CASE WHEN ep.value IS NOT NULL
         THEN 'Documented'
         ELSE 'MISSING'
    END                                 AS TableDoc,
    ep.value                            AS TableDescription
FROM sys.tables t
LEFT JOIN sys.extended_properties ep
    ON  ep.major_id   = t.object_id
    AND ep.minor_id   = 0
    AND ep.name       = 'MS_Description'
WHERE t.is_ms_shipped = 0
ORDER BY TableDoc DESC, t.name;

-- Column-level documentation coverage
SELECT
    OBJECT_NAME(c.object_id)            AS TableName,
    c.name                              AS ColumnName,
    c.column_id,
    t.name                              AS DataType,
    CASE WHEN ep.value IS NOT NULL
         THEN 'Documented'
         ELSE 'MISSING'
    END                                 AS ColumnDoc,
    ep.value                            AS Description
FROM sys.columns c
JOIN sys.types t
    ON t.user_type_id = c.user_type_id
LEFT JOIN sys.extended_properties ep
    ON  ep.major_id   = c.object_id
    AND ep.minor_id   = c.column_id
    AND ep.name       = 'MS_Description'
WHERE OBJECTPROPERTY(c.object_id, 'IsUserTable') = 1
ORDER BY TableName, c.column_id;

-- Summary: documentation coverage percentage per table
SELECT
    OBJECT_NAME(c.object_id)            AS TableName,
    COUNT(c.column_id)                  AS TotalColumns,
    COUNT(ep.value)                     AS DocumentedColumns,
    CAST(COUNT(ep.value) * 100.0
         / COUNT(c.column_id) AS DECIMAL(5,1))
                                        AS CoveragePerct
FROM sys.columns c
LEFT JOIN sys.extended_properties ep
    ON  ep.major_id   = c.object_id
    AND ep.minor_id   = c.column_id
    AND ep.name       = 'MS_Description'
WHERE OBJECTPROPERTY(c.object_id, 'IsUserTable') = 1
GROUP BY c.object_id
ORDER BY CoveragePerct ASC;

-- Generate missing documentation as a script template
-- Run this and fill in the descriptions
SELECT
    'EXEC sys.sp_addextendedproperty' + CHAR(13) +
    '    @name  = N''MS_Description'',' + CHAR(13) +
    '    @value = N''TODO: describe this column'',' + CHAR(13) +
    '    @level0type = N''SCHEMA'', @level0name = N''dbo'',' + CHAR(13) +
    '    @level1type = N''TABLE'',  @level1name = N''' +
        OBJECT_NAME(c.object_id) + ''',' + CHAR(13) +
    '    @level2type = N''COLUMN'', @level2name = N''' +
        c.name + ''';' + CHAR(13)   AS GeneratedScript
FROM sys.columns c
LEFT JOIN sys.extended_properties ep
    ON  ep.major_id   = c.object_id
    AND ep.minor_id   = c.column_id
    AND ep.name       = 'MS_Description'
WHERE OBJECTPROPERTY(c.object_id, 'IsUserTable') = 1
AND   ep.value IS NULL  -- undocumented columns only
ORDER BY OBJECT_NAME(c.object_id), c.column_id;

Prioritizing the Documentation Work

Not all tables and columns are equal. Focus documentation effort where it has the most impact for AI accuracy.

Priority	What to Document First	Why
1 (Highest)	Status and type columns with integer codes	These produce the most wrong answers. An undocumented status column will generate incorrect filters in almost every query.
2	Tables that appear in the most queries	Check sys.dm_exec_query_stats to find the most frequently queried tables. Documenting these first improves the most queries.
3	Tables with ambiguous or legacy names	Any table whose name does not clearly communicate its contents is a source of AI confusion.
4	Columns with business rule dependencies	Soft delete flags, mandatory filters, and calculation dependencies must be documented or the AI will produce results that violate them.
5	All remaining columns	Work through remaining undocumented columns systematically. The coverage audit query above generates the script templates.

7 Connecting Schema Quality to RAG Pipeline Quality Intermediate

Schema documentation feeds AI accuracy through two separate paths that reinforce each other. Understanding both paths helps prioritize where documentation effort has the most impact.

Path 1: Direct Schema Context

When an AI tool generates SQL against your database, it reads your schema objects including extended properties and uses that information to build the SQL. Better extended property documentation means better generated SQL. This is the most direct path and the one covered in Sections 4 and 5.

Path 2: The RAG Knowledge Base

For AI assistants that answer questions about your business data (not just generate SQL), the quality of the RAG knowledge base is critical. That knowledge base typically contains your DBA runbooks, data dictionaries, business glossaries, and schema documentation. Extended property descriptions from your SQL Server database can be exported and loaded into the RAG knowledge base directly, making your schema documentation available as retrievable context for natural language questions about your data.

-- Export schema documentation for RAG knowledge base loading
-- This produces structured documentation that can be chunked
-- and embedded into a vector store for semantic retrieval

SELECT
    'TABLE: ' + OBJECT_SCHEMA_NAME(t.object_id) + '.' + t.name + CHAR(13) +
    'DESCRIPTION: ' + ISNULL(CAST(tep.value AS NVARCHAR(MAX)),
                             'No description available') + CHAR(13) +
    'COLUMNS:' + CHAR(13) +
    STRING_AGG(
        '  ' + c.name + ' (' + ty.name + '): ' +
        ISNULL(CAST(cep.value AS NVARCHAR(MAX)), 'No description'),
        CHAR(13)
    ) WITHIN GROUP (ORDER BY c.column_id)
                                        AS TableDocumentation
FROM sys.tables t
JOIN sys.columns c
    ON c.object_id = t.object_id
JOIN sys.types ty
    ON ty.user_type_id = c.user_type_id
LEFT JOIN sys.extended_properties tep
    ON  tep.major_id = t.object_id
    AND tep.minor_id = 0
    AND tep.name     = 'MS_Description'
LEFT JOIN sys.extended_properties cep
    ON  cep.major_id = c.object_id
    AND cep.minor_id = c.column_id
    AND cep.name     = 'MS_Description'
WHERE t.is_ms_shipped = 0
GROUP BY t.object_id, t.name, tep.value
ORDER BY t.name;

-- Each row of this result is a document chunk describing one table
-- Load these into your vector store for semantic retrieval
-- A question like "how do I calculate revenue?" will retrieve
-- the Orders table documentation and surface the IsCancelled filter
-- and the status code values automatically

The connection between schema documentation and RAG quality means that a single documentation effort serves two purposes: it improves direct SQL generation accuracy and it improves natural language query accuracy against the knowledge base. Every extended property description you write is an investment that pays into both paths simultaneously.

8 The Practical Roadmap for SQL Server Teams Beginner

The gap between where most databases are today and where they need to be for reliable AI output is real but closeable. Here is a practical sequence.

Week 1: Assess and prioritize

Run the documentation coverage audit query from Section 6. Identify your ten most-queried tables. Identify all status and type columns with integer code values. These are your first targets.

Week 2 to 4: Document the critical layer

Write table descriptions and column descriptions for the ten most-queried tables. For every status and type column, document every valid value and its business meaning. This is the work that has the highest immediate impact on AI accuracy.

Month 2: Systematic coverage

Use the script generator query from Section 6 to produce the template scripts for all remaining undocumented columns. Work through them systematically with the team members who know the business meaning of each column. Distribute this work across the people who know the data rather than making it a single DBA’s project.

Ongoing: Documentation as a development standard

Add extended property documentation as a requirement for any new table or column before deployment. This is a one-time cost at development time that prevents accumulation of new undocumented objects. Code reviews should check for the presence of extended property documentation the same way they check for indexes and constraints.

References

• Phil Schmid (Hugging Face): Context Engineering is the New Prompt Engineering (2025)
• Liu et al.: Lost in the Middle: How Language Models Use Long Contexts (2023, Stanford / UC Berkeley)
• Andrew Ng: Forward Deployed Engineers and the Future of AI Engineering, The Batch (May 29, 2026)
• Microsoft Docs: sp_addextendedproperty
• Microsoft Docs: sys.extended_properties
• SQLYARD: Your Column Names Now Determine How Smart Your AI Is
• SQLYARD: How AI Connects to Your Company Data
• SQLYARD: MCP and SQL Server: What Every DBA Needs to Know
• SQLYARD: From Rows to Reasoning: Designing SQL Server Databases for AI Apps