A team asks an AI assistant how many active customers it has. Sales counts accounts with open opportunities. Finance counts customers with revenue this quarter. Customer success counts live service plans.
All three answers can be grounded in real data. More retrieval may find every definition without resolving which one belongs in the report.
The missing information is a decision: what does “active customer” mean for this use, and who owns that definition?
More Evidence Does Not Settle a Disagreement
Relevant context helps. A model with the contract, reporting history and source records has more to work with than one reading a single row.
But evidence and authority answer different questions. A frequently used spreadsheet may encode an outdated rule. A recent Slack message may be a suggestion. A column called revenue may contain billings rather than recognised income.
The problem becomes visible when two answers cite genuine sources and still disagree. Adding another source will not necessarily tell the model which interpretation the business intends.
Start With the Decision the Report Supports
A definition is useful within a purpose and scope. There need not be one universal meaning of “active customer” across sales, finance and service operations. There does need to be an explicit meaning for the decision being made.
For a quarterly finance report, settle the questions that change the number:
- Does activity mean recognised revenue, an invoice or a live contract?
- Which reporting period and legal entities are included?
- How are refunds, credits and dormant accounts treated?
- Which customer identifiers join the sources?
- What happens when a required source is missing or stale?
The result should be a definition people can inspect and systems can apply consistently. A model may help propose it. A plausible proposal alone is not authority to use it in a board report.
Build on the Definitions You Already Have
A warehouse, semantic layer or knowledge graph may already contain valuable definitions, ownership and approval history. Preserve that work. The issue is not whether it lives in a particular category of software; it is whether the agent is bound to the right version when it answers.
A schema describes structure. A relationship map connects records. Neither, on its own, establishes that a particular interpretation is permitted for this task. The surrounding governance can supply that decision.
Ask whether the current stack can name the applicable definition, enforce its query boundary and show which version produced an answer. Those are concrete requirements to address before adding another layer.
What the Twin Publishes
The MLX Twin turns source evidence and business definitions into versioned view contracts, also called Twin products in earlier articles. A contract states what each row represents, which fields and calculations are available, and the evidence supporting its use.
The current authoring path checks source coverage, compiles and executes the proposed definition, evaluates it independently and applies admission policy before activation. Human review belongs where policy requires it or the business meaning needs a decision. Automated publication does not remove the organisation's responsibility for how a definition is used.
This keeps two claims separate: the system has enough evidence to publish a contract, and the business accepts that contract for a particular purpose.
How an Agent Uses the Definition
On the governed query path, the model requests permitted fields, filters or aggregates. The runtime validates that request and compiles a read-only query against the published data. The model does not supply arbitrary SQL for that route.
Exploratory analysis is a separate surface. It can help investigate a question before a suitable definition exists, but its result should not silently become the company's recurring metric.
An answer can identify the published definition, version and freshness it used. A colleague asking through another enabled interface can use that same contract rather than rebuilding the calculation inside a different prompt.
Approval Is Accountability, Not Proof of Truth
An approved definition can still be wrong. The source may be incomplete, a join may duplicate records or the rule may no longer fit the decision.
Validation and evaluation test specific claims. Provenance identifies where an answer came from. A freshness watermark tells you how current the source is; it does not establish that the source meets every use case's requirements.
Transaction-level drill-down also depends on preserving the relevant source references. A product citation does not create lineage that the definition never retained.
These limits make review useful. The team can see what changed, test the consequence and publish a new version while retaining the identity of earlier answers.
Make the Agreement Reusable
Start with one contested metric. Write down its purpose, settle the choices that affect it, test the implementation and give the definition a stable version.
Then let authorised agents use it through a bounded interface. The payoff is less reconciliation: another model or chat window does not have to become another interpretation of the business.
A few practical questions.
Do we need a Twin if we already have a warehouse and semantic layer?
Start by checking the controls you already have. Existing tools may contain definitions and approval history. The requirement is to bind the agent to the permitted version and query boundary, with evidence showing what it used.
Can the model write SQL through the governed Twin query route?
No. That route validates typed requests and compiles read-only queries against published data. Exploratory SQL is a separate surface with separate controls.
Does approval prove a definition is correct?
No. It records an accountable decision for a purpose. Source coverage, implementation validation and answer evaluation remain necessary, and transaction-level drill-down requires preserved source references.