The LLM is allowed to respond. It should not decide what is true.

You sit on the Steering Committee. Someone asks: “How did the contribution margin develop in the second quarter – and why?” The dashboard shows a number. The AI ​​assistant provides an explanation in eight seconds. The room nods. Controlling later realizes: It was DB II, not the management view. The scope was too wide. The justification came from the model knowledge, not from a released evidence base. The answer sounded correct. The decision was not defensible.

This is not a prompt problem. It's an architectural problem.

A language model can convincingly explain an incorrect number. It can also give a correct number with the wrong reasoning. In both cases, the cause is rarely just the model. It lies in an architecture that gives the model too many responsibilities: meaning, calculation, access and formulation. Evidence-first AI therefore does not start with the better prompt. It starts with the separation of mandates - and with an evidence pack before the LLM is formulated.

The management question is never just a question

The contribution margin question sounds clear. It's not her. Before a system can answer them reliably, it must clarify, among other things:

• Which contribution margin definition is meant?
• Which calculation logic is binding?
• Which period and which dimension apply?
• What data can the person making the request see?
• Which source provides the value?
• What evidence supports the explanation?

A classic AI assistant often tries to solve all of this within a model. The LLM interprets the term, looks for information, combines numbers, takes supposed authorizations into account and finally formulates the answer. The result can seem completely plausible - and still be based on the wrong definition, use an inadmissible amount of data or add a justification for which there is no reliable source.

Linguistic plausibility is not yet a reliable basis for decision-making.

Corporate questions connect several levels: technical meaning, calculation logic, data access, decision context and responsibility. Finance often defines a key figure differently than sales. Controlling works with a cleaned management view. The operational system knows a current status, the reporting knows a completed period status. None of these perspectives have to be wrong. They just answer different questions.

An LLM can recognize and summarize these differences. However, it does not yet have a mandate to determine which perspective is binding for a specific business decision. That's exactly why:

Meaning is not calculation. Calculation is not access. Access is not formulation.

These separations are not an abstract manifesto. They are the same contract that the context layer builds in five layers: data platform, glossary, semantic layer, ontology and agent context. The LLM comes afterwards.

Without a data platform as an authoritative source and enforced scope, the glossary and semantic layer remain declarations of intent. The platform provides the evidence; the layers above say what they mean and who can see them.

1. Meaning must be defined outside the model

A term such as “contribution margin”, “active customer” or “sales” rarely has a universal meaning in a company. Its meaning depends on the business process, the addressee, the time, the organizational unit and the specific decision.

A language model can suggest possible definitions or compare existing ones. However, it should not decide for itself which of these is binding. This requires a technical context in which it is visible:

• what definitions exist,
• for what purpose they apply,
• who is responsible for them,
• which exceptions are known,
• how they relate to other terms and metrics.

In the context layer this is the second layer: the glossary - on the data platform as the foundation. An interpretation generated by the model is initially a hypothesis. It does not become a business rule simply because it has been convincingly formulated.

2. Calculation needs binding logic

Definition and value are not the same thing. Even if it is clear which key figure is meant, the question remains: which formula applies? What data flows in? Which aggregation and which period? What corrections or exclusions?

An LLM should not reconstruct this calculation on the fly. Even freely generated SQL does not solve the basic problem. It simply shifts the interpretation into a technical query, the logic of which may not be approved or reproducible.

Decision-relevant key figures need a defined and controlled calculation level - in the context layer of the semantic layer (third layer). The model is allowed to explain the determined value. It shouldn't invent it yourself.

3. Access must be technically enforced

Many AI applications treat permissions like an instruction in the prompt: Show this person only data from their area of ​​responsibility. That sounds like governance. At first it's just a sentence.

If the underlying system can still access all data, security depends on the model correctly interpreting the instruction and consistently following it. This is not robust access control.

The amount of data allowed must be determined before information enters the response pipeline. An advisor, a division manager, and a member of senior management can ask the same question and get legitimately different results. The difference should not arise from the politeness of the model. It must be enforced through the data and permissions architecture - in the data platform and in the context layer through the agent context (fifth layer).

4. The LLM should formulate, not produce truth

This leaves the language model with an important but clearly limited task: it formulates an understandable answer from a controlled evidence base.

This is no small role. A good model can explain complex relationships, highlight relevant differences, put numbers into a business context, make uncertainties visible, and adapt the answer to the reader's level of knowledge. But it should only be allowed to use statements for which there is a permissible basis.

In practice, we therefore work with Evidence-first AI:

Evidence first. Compose second. Critic last.

First, it determines which definitions, values, dependencies, and access information are allowed for the question. Only then will an answer be formulated. A separate gate then checks whether the statements are actually based on the existing evidence and whether known limitations have been correctly addressed.

The evidence basis becomes the contract

The crucial difference to a free chatbot is not just the quality of the data. It lies in the transition between data and response.

For every request, a controlled evidence base is created - an Evidence Pack. This may include, for example:

• the dissolved technical meaning,
• the binding key figure definition including version,
• the calculated value,
• relevant dependencies,
• the permitted amount of data,
• known gaps or conflicts,
• the technical owner of the underlying rule.

Every factual statement must be traceable to some part of this basis. If the necessary evidence is missing, there are only a few permissible results: a query, a limited answer, a transparent gap or a block. The most likely addition from the model knowledge is not permitted.

This is the same standard that a decision template for the board places on the factual basis: Does the same question lead to the same number next week, and who in the room can explain the derivation?

When systems contradict each other

Finance, sales and controlling can use the same term and still provide different, understandable figures. None of them have to be wrong. An LLM that silently chooses one variant and leaves out the others is making a technical decision without a mandate.

A resilient system treats such conflicts as visible objects: competing evidence, scope, owner, status. Where a shared precedence rule exists, it applies it. If not, ask back or escalate. Silent winner picks by the model are not a feature. They are an architectural error.

This is especially true when relationships and meanings cross multiple systems. This is exactly where the Knowledge Graph in the company comes in: relationships are modeled and accounted for, not left out of line. The ontology is the fourth layer of the context layer.

«Clarification required» is not an error

Let's take the question: What was the contribution margin in the second quarter?

A system could deliver value immediately. But contribution margin I, II and III may exist. Perhaps an area also uses its own management definition. The quick answer would then not be efficient. It would be an unnoticed decision about the meaning of the question.

A resilient system asks back: What contribution margin level do you mean?

From a chatbot demo perspective, this seems less impressive. From the perspective of a real business decision, it is significantly more valuable. A system that recognizes ambiguity is often smarter than one that smoothly glosses over it.

Evidence-first AI therefore does not need to be optimized for the largest possible number of answered questions. It must be optimized for the largest possible number of responsible answers.

How this changes for companies

The most important quality indicator of an evidence pack-based system is then no longer: How convincing does the answer sound? But rather:

• What definition was used?
• Where does the value come from?
• Which access scope applied?
• What evidence supports the statement?
• Which uncertainties were identified?
• Who is responsible for the underlying rule?
• Can the decision be understood later?

This also changes the development of AI applications. Teams don't just have to design models, prompts and interfaces. You need to clarify:

• which systems are authoritative for which statements,
• how professional conflicts are handled,
• which statements may be released automatically,
• when human judgment is required,
• how responses can be limited or revoked.

This is the transition from AI chatbot to operational decision system. Fewer answers can generate more trust - not as an unintentional disadvantage, but as a conscious quality feature. The system can say: The term is not clear. The required value is not available. The person making the request does not have the necessary access. The existing evidence is only sufficient to make a limited statement. The conflict requires a professional decision.

This may result in less AI theater. But more clarity about what the company actually knows, who can decide about it and which actions are responsible.