# Your AI Doesn't Need More Context. It Needs Approved Meaning. > Bigger windows and more connectors do not settle what your business means. Approved meaning does, and that is what a governed interpreter publishes. Published: 2026-07-23T10:00:00Z Updated: 2026-07-24 Author: Archie Norman (Founder, MLX) Category: Twin Tags: twin, approved-meaning, governed-interpreter, semantic-layer, enterprise-ai, rag, data-governance Canonical URL: https://mlx.systems/blog/approved-meaning-not-more-context ## TL;DR - The bottleneck in enterprise AI is not access to data but access to approved organisational meaning, and more context can multiply disagreement rather than resolve it. - A schema describes structure and a knowledge graph maps relationships, but neither carries the human approval that turns a business definition into an answer you will stand behind. - The Twin is a governed interpreter: an approved proposal publishes a stable relation, a versioned contract, generated runtime context, and validation evidence that an agent binds rather than reinterprets. - Provenance is not semantic truth; runtime evidence shows which approved relation answered and how fresh it was, while only human approval certifies the definition and source-row drill-down exists only where lineage was preserved. --- The instinct, when an AI system returns a wrong or wandering answer, is to feed it more. A larger context window. More documents in the retrieval index. Another connector into another system. The logic feels sound: the model was missing something, so give it more of everything and it will settle on the truth. Inside a real organisation, more context often does the opposite. It does not resolve disagreement. It manufactures it, and it makes each version sound more credible than the last. ## The Context Reflex, and What It Misses Context is not worthless. A model that can see the relevant contract, the last four quarters, and a customer's support history will reason better than one staring at a single row. The problem is not the quantity of context. It is what the context is silent about. When you widen the window and index more sources, you increase the number of places where the same word is defined differently. The model now has three tables that all mention revenue, two dashboards that disagree on active customers, and a spreadsheet a regional team swears by. It will confidently assemble an answer from whichever fragments it retrieved. So will the next query, from different fragments. Both look grounded. Both cite real data. They contradict each other. More retrieval did not get you closer to a shared answer. It gave the model more raw material to be plausibly wrong with. ## Where the Real Argument Happens The disagreement is never really about access. It is about meaning, and it hides inside terms everyone assumes are settled. Take revenue. Is it billings or recognised revenue? Does it net refunds and credits? Does it include deferred amounts not yet earned? Take active customer. Signed in within thirty days, holding a live contract, or having spent money this quarter? Each definition produces a different number, and each has a constituency inside the business. Gross margin depends on exactly which costs land in cost of goods sold. Overdue depends on the due date, the grace period, the currency, and the close date you measure against. Utilisation depends on which hours count as billable and which calendar defines available capacity. Renewal risk is not even a stored fact; it is an assembled judgement built from usage, support load, and sentiment, and two teams will assemble it two ways. None of this is a data-access problem. The rows exist. The problem is that the organisation has never ratified which reading it will stand behind, and an AI cannot infer a ratification that was never made. ## A Schema Is Not Meaning. A Graph Is Not Approval. This is where two familiar answers fall short. A schema describes structure. A column named revenue in a warehouse table tells you a number of a certain type lives there. It does not tell you which of the five revenue definitions it encodes, whether finance blessed it, or whether it is safe to quote to a board. Structure is not meaning. A knowledge graph goes further and maps relationships: this invoice belongs to that customer, which belongs to that account. Useful. But a relationship is not a ratification. Knowing that two things connect says nothing about which definition of either the business has approved. A graph can be rich, current, and entirely unsanctioned. What is missing in both is a signature. Someone accountable has to say: this is what we mean by this term, this is the query that produces it, and this is what we will answer with. That act of approval is the artefact enterprise AI is actually short of, and neither a schema nor a graph carries it. ## The Twin as a Governed Interpreter The MLX Twin is built around that missing act. It is not a chatbot, a data dump, or a generic knowledge graph. It is a governed interpreter: the layer that turns organisation-scoped data into approved meaning, and enforces that meaning at query time. It begins with source-backed data. Connectors land organisation-scoped warehouse data that keeps its provenance, so every candidate definition is anchored to real records rather than to a model's paraphrase. From there, Twin discovery proposes definitions. It can run in automatic, guided, or explicit mode, from letting the system surface candidates to a person specifying exactly what they want. Discovery produces deterministic convergence proposals: concrete, repeatable statements of what a term means and how it is computed. Then the decisive step. A human reviews the proposal before anything is shared or promoted to production. The Twin does not decide what revenue means. A person does. The Twin's job is to record that decision, publish it, and hold the runtime to it. ## What "Approved Meaning" Actually Ships Approval is not a note in a wiki. When a proposal is approved, it publishes a set of connected artefacts. There is a stable `mlx_curated` relation: the concrete, queryable result the definition names, in a fixed place. There is a versioned product contract, so the definition has an identity and a version that can be referenced and changed deliberately rather than silently. There is a generated skill and routing snapshot, so agents know the product exists and when to reach for it. There is validation evidence produced against real data, and, where it is warranted, an evaluation suite attached to the product. The point is that meaning stops being an interpretation the model performs on the fly and becomes a published object with a version, a location, and a record of who approved it. ## Catalog, Manifest, Bound Relation Here is how an agent uses that, in plain terms. An agent does not go rummaging through the warehouse. It first reads an organisation-scoped Twin catalog: the list of approved products available to it. From that catalog it selects one published manifest, the specific product that answers the question at hand. It then queries only the relation that manifest names. That querying is typed and read-only. The runtime binds the approved relation and mechanically compiles the query. The model does not rediscover the schema, and it does not write arbitrary SQL against your systems. It asks a bounded question of a bounded, approved object, and the runtime does the binding. And the answer can carry its own paperwork. Product identity, version, the relation it came from, and freshness evidence can travel with the result, so a number arrives with a record of which approved definition produced it and how current it was. ## One Definition, Many Readers This is the quiet payoff. Because meaning is approved once and published as a contract, it does not have to be reinterpreted on every request or by every reader. Swap the underlying model and active customer does not drift, because the definition lives in the relation and the contract, not in the model's momentary reasoning. Point a different first-party interface at the same product and it reads the same relation. The definition is decided in one place and consumed in many, instead of being re-derived, slightly differently, everywhere it is used. That is the difference between an organisation that has approved its meaning and one that merely stores its data. Stored data can be read a dozen ways. Approved meaning reads one way, on purpose. ## The Honest Limits Two things must be said plainly, because overclaiming here is how trust is lost. First, provenance is not semantic truth. A result that carries its relation, version, and freshness proves the pipeline behaved and the data was current. It does not prove the definition is correct. Runtime validation and provenance are evidence of process, not of meaning. Only human approval certifies that a business definition is the right one, which is precisely why approval sits where it does. Second, lineage has limits. Exact drill-down from an aggregate to the individual source rows behind it is available only where a source reference or an explicit lineage mapping has been preserved for that product. It is not a universal, automatic property of every number the Twin returns. Where the lineage was kept, you can follow it. Where it was not, the honest answer is that you cannot, and a governed system should say so rather than fabricate a trail. ## What Earns Approval None of this works if approval is a rubber stamp. Meaning does not become trustworthy because someone wrote it down; it becomes trustworthy because it survived scrutiny. A proposal earns its approval by passing through a sequence of gates: checks that a definition is grounded, coherent, validated against real data, and owned by someone accountable before it is allowed to become an answer the business will stand behind. The next article walks through those five gates, and why each one exists. Enterprise AI does not need to be told more. It needs to be told what you mean, by someone with the authority to mean it. --- **Previous: *[You Are Not the Front Door](/blog/you-are-not-the-front-door).*** Why the governed Twin, not another chat window, is the company-side interface when people bring their own agents. **Next: *[Five Gates Between a Guess and a Governed Answer](/blog/five-gates-to-a-governed-answer).*** How discovery, review, validation, activation, and evaluation keep different kinds of evidence distinct.