AI-Ready Data: Source Ownership, Definitions and Freshness

Reviewed and updated October 8, 2026.

Data is ready for an AI use case when the application can obtain the right authorized facts, interpret them consistently and identify who corrects them. That may require an approved folder of documents and a scheduled export. It does not automatically require a new streaming platform or a company-wide knowledge graph.

Decide what the first workflow needs before redesigning the data estate. A policy assistant needs authoritative versions and applicability. A sales explanation needs a defined metric and a reporting period. A workflow agent needs identifiers and current state from the system that owns the action.

Write a data contract for the question

For each source, record its owner, purpose, authoritative fields, update frequency, permission rules and correction route. Preserve source identifiers and timestamps through transformations. Reconcile how the same customer, product or employee is identified in different systems. If two sources disagree, specify which governs the decision rather than asking the model to choose a plausible value.

Use tests for known invariants. dbt's data test documentation describes checks such as uniqueness, non-null values, accepted values and relationships. These can detect broken records, but a passing test does not establish that a business definition is correct.

An illustrative renewal question

Suppose an account team asks, “Which contracts renew next month, and what is their recurring value?” This is a worked design example, not an observed client outcome. The CRM stores opportunities; the contract system stores signed renewal dates; billing records contain invoices.

Define recurring value with the finance owner before building the answer. Decide whether credits, one-time fees and cancelled contracts are included. Use the renewal date recorded in the signed contract, a stable account mapping for joins and the agreed recurring-value calculation. Return the reporting cutoff and links to the governing records.

A nightly approved export may meet the decision's freshness requirement. If users need changes made minutes ago, test an authorized live lookup for the relevant fields. Streaming every source would add operational work without resolving an ambiguous metric. A language model can explain the selected records; it should not invent the missing joins or decide the accounting definition.

Freshness needs a rule and an owner

Distinguish when a source was modified, when ingestion succeeded and when the application checked it. dbt source freshness is a documented way to compare source timing with configured limits. Set limits according to the decision, and describe the response when a source is late.

Test deletion, access changes, duplicate identifiers and an interrupted refresh. A removed document must not remain available through an old chunk or cached answer. A failed refresh should preserve a known version or mark the result unavailable, rather than silently presenting stale information as current.

Limit preparation to the first useful scope

Start with a bounded source set when it supports the workflow. Expand after tests reveal a specific missing fact, relationship or freshness need. Measure unanswered questions and source defects separately from model mistakes so the next change addresses the actual failure.

For source ownership and definitions, see data strategy and development. For assembling these sources at request time, read context engineering. Request a project review with a real question, its sources and the decision it informs.