In this chapter
- An assistant reads only what was captured. Names, types and keys, never what your business decided.
- Context belongs in a governed setting. Pasted into a chat, it’s private and unreviewed.
- The metadata contract has seven items. Each is a question for any vendor.
- Receipts make generation governable. Prompts under change control, and a record of every run.
What does the AI assistant in your data platform read? It reads what the platform holds: table names, column names, data types, keys, and whatever descriptions somebody once remembered to write. Call that the physical estate. Inside it, the assistants are genuinely good.
Every generator, whether that assistant, a template engine or the new hire who starts Monday, builds from what it was given to read and nothing else. Write down what that reading list must include and you get a specification for the metadata your team should capture. You also get an audit list for every “our AI does it” claim a vendor makes, including the one writing this book.
That reading list is the metadata contract.
The AI cannot see what was never captured
As of September 2026, the documentation for each assistant on Databricks, Snowflake and Microsoft Fabric says answer quality depends on expressive names, good descriptions and the curated context you supply. Each then ships a place to author it: instructions and example queries, a hand-written semantic model, or per-model AI instructions. The model was never the bottleneck, and everyone now agrees the context is.
But each of those context surfaces describes one platform’s physical estate, in its own format, for its own assistant, written after the data landed. The right idea has arrived, one tool at a time, at the wrong altitude.
Point the assistant at your source schemas and ask for a business model. It returns your source schema with better labels, because the schema was all you gave it to read. Ask it to integrate two systems and it can’t. Integration is an agreement between systems, and the assistant met yours one at a time. Neither schema records that your sales system’s customer number and your billing platform’s account identifier describe the same person.
Somebody has to decide that, and reading either system harder will never surface it.
Why is business context not an AI prompt?
The first workaround is the chat window. You paste in the glossary excerpt, the naming rules and the warning about the three customer tables, then ask. It works once, and that is its whole problem.
Pasted context is unversioned, unreviewed and gone tomorrow. Nobody can compare Tuesday’s paste with Monday’s, and a colleague with slightly different text gets a slightly different answer. That isn’t governing the AI’s input. It’s privatizing it, one chat session at a time.
Treat context instead as a governed setting: captured once in your own words, reviewed like any change, and read by every run. So an afternoon spent sharpening what your organization means by a customer is the cheapest AI improvement you’ll ever buy. It lifts every proposal and review that follows. A sharp frame gets you proposals in your language, not plausible answers about somebody else’s business.
The metadata contract has seven items
So what must generation be able to read? It needs seven kinds of metadata. Each is a strand of governed AI context rather than a prompt, and each ends on a question for your next vendor demo.
Figure 8.1: the contract, enumerated. Seven inputs, one generation step, a review gate, and the platform downstream of all of it.The conceptual model. It’s your agreed business language, written down before anything is stored, with its approvals. Where does the generator read what my business means by a customer, and who approved that definition?
The source register. It’s one entry per source, with its owner, how and when it delivers, and what it can and cannot tell you. Beside the register sit the rulings you promoted from each source’s profile. Does generation know how my sources behave, or only how they’re declared?
The mappings. They pair each table and column with what it means, with who decided, when and why. Can the generator read each pairing, who decided it, and which columns nobody has mapped yet?
The shape decision. It’s the structure you chose to integrate your sources into, written down with the rulings that keep it consistent and every exception you allowed and why. Where is it recorded, and how does the generator learn the exceptions?
The conventions. They’re naming rules, system columns and their roles, hashes and type mappings, stored as data the generator’s patterns read, never inside them. Are my conventions inputs the generator reads, or opinions compiled into its code?
What your team already wrote down. Much of your business language lives in standards, glossaries, requirements documents and meeting transcripts. Paste a summary into a prompt and the generator reads a paraphrase. Keep them instead as governed, versioned inputs, extracted and addressable, so a run reads the relevant passage in your words, and they’re the knowledge documents. Can I hand over my team’s documents, and will the generator read what they say or a paraphrase?
Where each object runs, and in what order. A generated load can be right in every column and still fail, because it targets the wrong platform or runs before the table it reads exists. So the contract records which platform each layer runs on and what loads before what. Those are the environment and dependency facts. Does the generator know which layer it’s writing for, on which platform, and in what order?
Score yourself against that list today. Most teams find a few items captured, a few scattered across wikis and heads, and at least one that exists nowhere. That isn’t a failing grade. It’s the backlog.
Self-sufficiency is the test
How do you know a contract is complete? Borrow template engineering’s sharpest test. If an author, human or machine, can’t produce the artifact from only the context it was declared to read, the contract is incomplete. The gap gets filled by guessing.
Picture a generator that infers a column’s role from its transformation code. It breaks silently the day that code changes, say when someone wraps it in a time-zone conversion. It was borrowing a fact nobody agreed to supply, and a borrowed fact fails without an error message on the day it moves.
That’s why sniffing and inference are contract debt.
So could a competent stranger produce a correct artifact from what your team has written down? If not, the machine can’t either. And unlike the stranger, the machine won’t ask follow-up questions on its way to being wrong.
Generation needs receipts
Generation that’s part of your method needs the discipline of any production process, which leaves two receipts. The first is the prompt. A generator’s instructions are where its opinions live. So they belong under change control like any source file: versioned, readable, testable before publication, and changed only on purpose. If you can’t read a generator’s instructions, you can’t review its opinions, and you’re shipping them anyway.
The second is a record of every generation run: what was asked, what context it was given, what came back and who approved the result. When somebody asks three weeks later why the model proposed a concept nobody remembers discussing, that record is the difference between an answer and a shrug.
That record also makes machine-written changes governable at all. When a proposal passes the same permission checks and lands in the same audit log as a human edit, “what did the AI change” has the same answer as “what did your colleague change”.
Neither receipt helps if nobody tends the contract. Stewards, who answer for what the data means, and architects own the contract’s definitions, conventions and choice of documents, and that work never finishes. It compounds in the review seat. A decision on one proposal becomes context the next run reads.
Treat review as a formality and the generator stays as wrong as on day one. Treat it as curation and the generator improves every week without a model upgrade.
The contract is buildable this quarter
None of the seven items waits on a platform feature or a model release. Each is metadata your team can capture now. The platforms will keep shipping smarter assistants, and each will make the same trade: it reads what it can see.
Widen what’s captured and every generator you own improves at once, whichever vendor ships it.
| The people part | Stewards and architects own the contract, and each review decision becomes context the next run reads. |
| Metadata to capture | Capture the contract’s seven items, keep every prompt under change control and record every generation run. |
| Regardless of stack | A language model, a template engine and a contractor all need the same seven items, and all three guess without them. |
In DeltaVault today
In DeltaVault, our metadata catalog, every AI capability is a skill: a versioned configuration that declares its prompt, its inputs and the context it reads. A draft stays private while it’s tested, and production runs use the published version. On the AI Skills page in the Toolkit, an administrator can customize a built-in skill for your organization.
Every run records the resolved prompts, exactly what context was sent and what was dropped, and the model’s output. A skill that writes stages its changes for you to review item by item, and what you approve lands in the same audit log as a person’s edit. Administrators see every skill run in your organization on the AI Activity page, even runs a member cleared from their own panel.
