How to Build AI-Ready Data From Day Zero in a New Data Stack

---

Building AI-ready data from day zero means writing each model’s meaning, owner, sensitivity and lineage into the code that creates it, scoped to your first agent use case, then proving fitness with a known-answer eval before the agent ships. Seven build-time steps make that concrete; three can block a merge or a release. Atlan’s context layer reads the descriptions, owners, certificates, tags and glossary terms you write in your dbt project, so the first agent works from owned, reviewed context.

---

A new stack has one advantage an old one never gets back: you can ask the person writing a column what it means before anyone depends on it. According to Gartner’s Rita Sallam, Distinguished VP Analyst, in AI-ready data essentials (Gartner): “There is no way to make data AI-ready in general or in advance. The readiness of data for AI depends on how the data will be used.” Day zero works with that, as long as the use case is named before the models are written.

Step	What you build	Where it lives	Tier	Blocks
1	The use case and its questions	Use-case spec in the repo	Scope	Nothing yet
2	Minimum context on every model	dbt YAML plus CI	1	The merge
3	Column tags with policy bound to the tag	dbt post-hook plus warehouse policy	1	Unmasked reads
4	Lineage from the first run	dbt plus OpenLineage	1	Nothing
5	Contracts, terms and certificates on agent-facing models	dbt contract or ODCS, Atlan keys in dbt	2	The build
6	Context delivery through MCP	Agent runtime config	2	Nothing
7	A known-answer eval, then certification	CI plus owner review	2	The release

---

Why build AI-ready data into a new stack instead of retrofitting a context layer later?

Building context into a new stack is easier than reconstructing it later, because at creation the author knows what each column means. That knowledge is the gap between AI-ready and analytics-ready data: analytics-ready data often left the last piece of meaning to an analyst who knew the business.

Forrester analysts wrote in Build Meaning Before Machines (Forrester, 2026): “Data without meaning is unusable for autonomous systems.” According to Rumiantsau and Fokeev (2026), a 4 KB business-semantics document raised text-to-SQL accuracy by 17 to 23 percentage points across three frontier models on 100 questions. Within each condition the three models were statistically indistinguishable.

Dimension	Day zero	Retrofit (existing estate)
Who supplies meaning	The model author, in the model file	Reconstructed from analysts, dashboards and owners
When the owner is set	At first commit	Assigned after the fact
Where context lives	In the repo, next to the code	In a catalog or wiki, added later
Sensitivity	Tagged at creation, policy bound to the tag	Found by scanning, then remediated
Lineage	Emitted by the pipeline	Mapped from logs and query history
Scope	The first use case’s models	The sources an agent already touches

Start here for a new warehouse, domain or first agent. For an estate already in production, preparing enterprise data for AI agents and extending your data catalog for AI readiness fit better.

According to Gartner (2026), “Gartner advises data and analytics (D&A) leaders to establish a context layer as a core component of their D&A infrastructure.” Atlan’s documentation (Atlan docs) builds readiness “asset by asset, use case by use case, starting with the specific domain an agent works on first.” On a new stack, that layer can exist the day the tables do, an early answer to the AI agent cold-start problem.

---

What do you need before you start building?

You need one funded agent use case, models in version control, a warehouse that supports object tags, and a named owner for each domain the first use case touches.

Requirement	Why it matters
One agent use case with a business sponsor	Readiness is judged against a job
A domain owner who can certify	Someone signs for meaning
Models in git, CI on pull requests	Context gets reviewed like code
Warehouse object tags and masking	Policy follows the tag
A lineage emitter and a way to serve context to the agent	Context reaches the agent

The team is four roles: an AI lead who owns the eval, an analytics engineer who writes Tier 1, a domain owner who signs, and a platform engineer for CI and context delivery. According to McKinsey (2026), the aim is to “define what “good enough” means for each use case based on business needs and the risk profile of the data and related business processes”. Who owns the context layer, AI-ready data owners and stewards and AI data architecture cover the roles and platform.

---

Step 1: Name the first agent use case and the questions it must answer

You finish this step with one named agent use case, its business owner, and a set of real questions, each with a reference query and its expected result. That list is the scope gate: a model gets Tier 2 controls only if one of these questions reads it.

Effort: Low. It scales with stakeholder availability.

1. Pick a use case tied to a funded need, such as a talk-to-data agent for finance or text-to-SQL for the enterprise.
2. Collect questions from the people who will use the agent, for example “What was net_revenue for EMEA in Q2 2026?” Pin each to a fixed period so the answer does not drift.
3. Store the reference as SQL plus its result, and set the “good enough” bar for this use case’s risk. With 20 questions, each failure moves the pass rate by 5 points, so also mark the few that must always pass.

Check: questions and reference queries sit in the repo. The talk-to-data agent blueprint and preparing data for natural-language analytics show good question sets. Take questions from users, since the data team tends to test what it already knows.

---

Step 2: Require a minimum context block on every new model

You finish this step with a rule: no model merges without a description, an owner, a domain group and a sensitivity class in its YAML, checked in CI.

Effort: Low. A few lines per model, plus a one-time CI setup.

Mature dbt teams already enforce a block like this; on a new stack you can require it before the first model merges. According to dbt’s documentation on groups (dbt), “Groups are named, and every group has an owner.” The table is the two-tier context gate: what every model carries, and what only agent-facing models add.

Context element	Tier	Where you write it at build time	What enforces it
Model and column descriptions	1	dbt description, persisted with persist_docs	CI check
Owner and domain	1	dbt group owner and meta owner	CI check
Sensitivity class	1	Column meta in YAML, applied as a warehouse tag by a post-hook	Tag-based masking (Step 3)
Lineage	1	dbt graph; OpenLineage for other pipelines	Emitted by the run
Glossary term	2	Atlan keys in dbt meta	Owner review
Contract	2	dbt contract: enforced: true or ODCS	Build fails on mismatch
Certificate	2	Draft at build, Verified after the eval	Owner, through a pull request
Known-answer eval	2	Question set from Step 1	Release gate (Step 7)

The YAML follows dbt’s current meta reference (dbt), which places meta under config (changed in v1.10 and backported to 1.9).

models/marts/finance/_finance.yml

groups:
  - name: finance
    owner:
      email: [email protected]

models:
  - name: fct_orders
    description: "One row per order line, net of returns and discounts."
    config:
      group: finance
      meta:
        owner: "[email protected]"
        sensitivity: "financial"
    columns:
      - name: net_revenue
        description: "gross_revenue - returns - discounts, in USD, at order date."
      - name: customer_email
        description: "Email address of the ordering customer."
        config:
          meta:
            sensitivity: "pii"

dbt_project.yml

models:
  my_project:
    +persist_docs:
      relation: true
      columns: true

1. Add the Tier 1 fields to your model YAML template.
2. Turn on persist_docs (dbt), off by default, so descriptions land as warehouse comments.
3. Add a CI check over dbt’s manifest.json (dbt), which holds every model’s configuration, and fail any pull request where a new model lacks a description, a group, an owner or a sensitivity class.

Check: a model without an owner fails CI. Descriptions state the business rule behind each column and feed the semantic layer, the dbt Semantic Layer and your KPI definitions and business glossary.

---

Step 3: Tag sensitive columns at creation and bind access policy to the tag

Every personal or restricted column ends this step tagged on each build of its table and protected by a tag-based masking policy.

Effort: Low to medium. It scales with the number of sensitivity classes.

According to Snowflake’s tag-based masking documentation (Snowflake), when the policy’s data type matches the column’s, “the tagged column is automatically protected by the conditions in the masking policy.” Each tag takes one masking policy per data type. A tag set on a schema also covers columns in newly added tables, but it masks every column there whose data type matches, so keep schema-level tags for schemas that hold only sensitive data.

CREATE TAG governance.tags.pii;

CREATE MASKING POLICY governance.policies.pii_string_mask AS (val STRING) RETURNS STRING ->
  CASE WHEN IS_ROLE_IN_SESSION('PII_READER') THEN val ELSE '***MASKED***' END;

ALTER TAG governance.tags.pii SET MASKING POLICY governance.policies.pii_string_mask;

models/marts/finance/_finance.yml, added to the fct_orders entry

    config:
      post_hook:
        - "ALTER TABLE {{ this }} MODIFY COLUMN customer_email SET TAG governance.tags.pii = 'email'"

1. Define a short sensitivity set, such as pii, financial and public, as Snowflake object tags (Snowflake).
2. Apply column tags in a dbt post-hook (dbt), which runs after each build of the model, so the tag is set again whenever dbt rebuilds the table. Snowflake recommends IS_ROLE_IN_SESSION (Snowflake) when a policy must respect role hierarchy.
3. In Atlan, turn on tag propagation (Atlan docs), off by default, so downstream columns carry the tag in Atlan through lineage. Warehouse masking still depends on the Snowflake tag on each table the agent can query.

Check: a role without PII_READER sees masked values in every table the agent can reach. Handling PII in AI pipelines and access control for AI agents cover policy design.

---

Step 4: Emit lineage from the first pipeline run

Lineage for every model the first use case reads should come from the tools that build the data.

Effort: Low for dbt models; medium for pipelines outside dbt.

Lineage is the path Step 3’s tags travel in Atlan, and the trail an owner follows when an eval answer comes back wrong.

1. Let the dbt graph define model lineage. Atlan crawls dbt Core (Atlan docs) models and sources with their descriptions and tags, and builds column-level lineage for dbt models and the tables they materialize.
2. For pipelines outside dbt, emit OpenLineage (OpenLineage) events, an open standard for lineage metadata; OpenLineage with Airflow shows the setup.
3. Trace each Step 1 question back to its sources.

Check: no orphan tables sit in the use case’s path. Data lineage for AI and AI-ready data lineage go deeper.

---

Step 5: Promote agent-facing models with a contract, glossary terms and a Draft certificate

You finish this step with the models the first use case reads moved to Tier 2: an enforced contract, glossary terms on business columns, and a Draft certificate.

Effort: Medium. It scales with the number of agent-facing models.

The strongest objection to day-zero governance lives here. dbt’s model contracts documentation (dbt) warns: “Introducing governance while models are still changing can complicate future changes.” The same page recommends contracts for models others rely on downstream, and the first agent is exactly that consumer. Staging models stay free to change.

1. Set contract: enforced: true on agent-facing models. dbt runs a preflight check, and the model fails to build if column names and types do not match.
2. If contracts must travel across tools, use the Open Data Contract Standard v3.2.0 (Bitol); Bitol’s 2026 release (Bitol) says it “brings context for AI systems”.
3. Add owners, terms and a Draft certificate through dbt meta, which Atlan reads from dbt (Atlan docs).

The keys are copied from Atlan’s dbt examples for certificates (Atlan docs), owners (Atlan docs) and terms (Atlan docs). ownerUsers takes Atlan usernames; use ownerGroups for a team.

models:
  - name: fct_orders
    meta:
      atlan:
        attributes:
          ownerGroups: ["finance-data"]
          certificateStatus: DRAFT
          certificateStatusMessage: >-
            Agent-facing for the EMEA revenue agent. Verified after the eval passes.
    columns:
      - name: net_revenue
        meta:
          atlan:
            termNames:
              - "Finance@Net Revenue"

Atlan’s examples put meta directly on the model, while dbt’s current docs nest it under config. Confirm which placement your Atlan dbt connection reads before you merge these keys into the Step 2 template. Keep the certificate in one place: if dbt meta sets it, move Draft to Verified with a reviewed pull request, so the YAML and Atlan never disagree.

Assets that still lack descriptions can be drafted by Context Agents, which, per Atlan’s documentation (Atlan docs), enrich only assets missing the attribute and leave values a person or source system wrote, including warehouse comments from persist_docs. The owner reviews each draft, the pattern behind context bootstrapping.

Check: a type change breaks the build, and every business column on the surface has a term. Never bulk-accept AI drafts.

---

Step 6: Deliver the context to the agent through MCP

The goal here is an agent that pulls context from one service at query time and runs its SQL as the user who asked.

Effort: Low to medium.

An agent with a schema-introspection tool can read warehouse comments and tags. Owners, terms, certificates and cross-tool lineage need a service, and a copy pasted into each AI tool drifts. Per the Atlan MCP overview (Atlan docs), Atlan MCP is “a hosted server, available on every Atlan tenant with nothing to install,” its tools cover “search, lineage, metadata, glossary, governance, and data quality,” and “every action respects the permissions you’ve already set in Atlan.” Those permissions decide what context the agent sees. Snowflake roles and masking decide what data its SQL returns.

1. Connect the agent runtime to the MCP server; see what is Atlan MCP and an MCP server for dbt.
2. Run the agent’s SQL under the end user’s warehouse role rather than a shared service role, so Step 3’s masking applies to each person.
3. Point the eval environment at Draft models and production at Verified ones. Context Engineering Studio (Atlan docs), available by enablement, assembles a context repository for one use case from your catalog and glossary.

Check: asked about fct_orders.net_revenue, the agent returns the Net Revenue definition and owner, and a user without PII_READER who asks for customer emails gets masked values. Context engineering, an AI agent harness, a semantic layer for AI agents and AI-ready data over MCP cover the runtime side.

---

Step 7: Gate the agent release on a known-answer eval, then certify

You finish this step with an eval that runs the Step 1 questions on every agent-facing change, blocks the release below the “good enough” bar, and tells the owner which models can move to Verified.

Effort: Medium, and recurring.

1. Run the question set in CI when an agent-facing model or its context changes. Compare result sets, not SQL text, and run each question more than once, since agent output varies.
2. Fix the layer that failed. If the agent joins orders to customers on account_id instead of customer_id, declare the key with dbt primary_key and foreign_key constraints (dbt), which dbt lists as not enforced on Snowflake, then fix the column description and glossary term. Leave the prompt alone.
3. Release only above the bar. The owner then moves the models the passing questions read from Draft to Verified.

Check: the pass rate is recorded per release, and each failure is traced to retrieval, context, SQL generation or execution. Avoid tuning prompts until the eval passes, and testing only at launch. See context testing for AI agents, context evals vs data quality testing and data quality for AI agents.

---

What are the most common mistakes when building AI-ready data from day zero?

Day-zero programs usually fail in one of two opposite directions: governing everything before the first agent exists, or governing nothing because the stack is “still new”.

Governing everything up front slows every change, which is dbt’s warning about models in flux. Governing nothing is the more common gap. According to Gartner (2025), “Sixty-three percent of organizations either do not have or are unsure if they have the right data management practices for AI”, from a survey of 1,203 data management leaders.

Context kept in a wiki or spreadsheet drifts from the code as soon as models change. Keep it in the model file and fix data quality problems at the source. An agent that ships with no eval gate gets judged on its first wrong answer in front of a business user.

---

How does Atlan help you build AI-ready data from day zero?

Atlan’s context layer reads the context your team writes at build time and serves it to agents. One dbt project feeding one agent can start from dbt’s own artifacts and warehouse comments. The layer earns its place once owners sit outside dbt, lineage crosses tools, certification needs a workflow, or a second agent needs the same context.

• Your dbt meta sets descriptions, owners, certificates, tags, terms and domains on dbt assets and the assets dbt materializes, per Atlan’s dbt documentation (Atlan docs).
• Column-level lineage comes from the dbt crawl, and tag propagation carries tags along it.
• Context Agents draft what is still blank and leave written values alone.
• Atlan MCP serves it all to agents under the permissions set in Atlan; Context Engineering Studio, available by enablement, packages it per use case.

Implementing an enterprise context layer for AI, data catalog vs context layer and what is a context graph explain the architecture.

---

How do you keep day-zero context current after the first agent ships?

Day-zero context stays useful only if the same checks run on every change and the next use case reuses what the first certified.

• Keep the CI checks and eval gate on, and watch for context drift when sources or definitions change.
• Track two numbers: the share of agent-facing models with complete Tier 2 context, and the eval pass rate per release.
• Start use case two from the certified terms and owners, and promote only the new models it reads.
• Before each new use case, re-run the AI-ready data checklist or an AI readiness assessment; what makes data AI-ready and the AI readiness guide set the baseline.

Measure the payback: how long use case two takes to reach its eval bar, against how long use case one took.

---

FAQs about building AI-ready data from day zero

1. What does AI-ready data from day zero mean?

It means each model’s meaning, owner, sensitivity and lineage are written into the code that creates it, scoped to the first agent use case. Readiness is then proved with a known-answer eval for that use case, because Gartner defines AI-ready data by fitness for a specific use, not as a general property.

2. How is building AI-ready data from day zero different from preparing existing data for AI?

On day zero, the person who writes the model supplies its meaning and owner in the model file, and the checks run inside the build. Preparing existing data means reconstructing that meaning after the fact, for an estate that already has consumers.

3. Do you need data contracts on every model in a new data stack?

No. Put enforced contracts on the models your first agent reads and leave staging models free to change. dbt’s own documentation warns that introducing governance while models are still changing can complicate future changes.

4. How much effort does day-zero context add to a new data stack?

The minimum context block adds a few lines per model. Contracts, glossary terms, certification and evals scale with the number of agent-facing models.

5. What tools do you need to build AI-ready data in a new data stack?

You need models in version control with CI on pull requests, a warehouse with object tags and tag-based masking, a lineage emitter such as OpenLineage, and a way to serve context to agents, such as a context layer with an MCP server.

6. Can AI write the metadata for a new data stack?

AI can draft descriptions for columns that are still blank, and the owner reviews them before certifying. Wretblad and colleagues found that generated column descriptions consistently improved text-to-SQL, while ambiguous columns still needed manual expert input.

---

Sources

1. AI-Ready Data Essentials to Capture AI Value, Gartner
2. Lack of AI-Ready Data Puts AI Projects at Risk, Gartner (February 26, 2025)
3. Gartner Says Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending, Gartner (May 11, 2026)
4. AI data readiness: The key to scaling impact, McKinsey (June 23, 2026)
5. Build Meaning Before Machines: Why Semantics, Ontologies, And Knowledge Graphs Matter For Agentic AI, Forrester (June 2, 2026)
6. Semantic Layers for Reliable LLM-Powered Data Analytics: A Paired Benchmark of Accuracy and Hallucination Across Three Frontier Models, arXiv:2604.25149 (April 28, 2026)
7. Synthetic SQL Column Descriptions and Their Impact on Text-to-SQL Performance, arXiv:2408.04691
8. Add groups to your DAG, dbt Developer Hub
9. meta, dbt Developer Hub
10. persist_docs, dbt Developer Hub
11. Manifest JSON file, dbt Developer Hub
12. pre-hook & post-hook, dbt Developer Hub
13. Model contracts, dbt Developer Hub
14. constraints, dbt Developer Hub
15. Tag-based masking policies, Snowflake Documentation
16. Introduction to object tagging, Snowflake Documentation
17. IS_ROLE_IN_SESSION, Snowflake Documentation
18. Open Data Contract Standard v3.2.0, Bitol
19. Data Contracts & Data Products for AI, Bitol (September 8, 2026)
20. OpenLineage documentation, OpenLineage
21. AI-ready data, Atlan Documentation
22. Enrich Atlan through dbt, Atlan Documentation
23. What does Atlan crawl from dbt Core, Atlan Documentation
24. Certify assets, Atlan Documentation
25. Manage asset owners, Atlan Documentation
26. Link terms and assets, Atlan Documentation
27. Tag propagation, Atlan Documentation
28. Understand context agents, Atlan Documentation
29. Atlan MCP overview, Atlan Documentation
30. What is Context Engineering Studio?, Atlan Documentation