The Missing Layer Between Your Data and Your AI

Ask an enterprise assistant a straightforward question: “Can we approve this request?”

The answer might depend on a transaction in the finance system, the current delegation policy, a project commitment in an email and an external requirement. Connecting the assistant to more documents gives it more material. Someone still has to establish which evidence applies.

This is the context problem. It sits between the information we hold and the judgement we expect AI to support.

Decide where the answer should come from

The Microsoft Frontier training I took had discussions about Work IQ, Fabric IQ, Foundry IQ and Web IQ that were useful because they brought different kinds of context into the same conversation.

For architecture purposes, I find four categories helpful: authoritative business records, organisational work context, approved institutional knowledge and current public information. They are conceptual categories here; a particular product may support several of them.

A question about an invoice balance should be grounded in the relevant business record. A question about a meeting commitment may require the correspondence. An external regulatory question needs an appropriate current authority. An internal document should never outrank a regulator merely because it is internal.

Source priority follows the question and the authority behind the information.

Route by purpose and source authority, then check permission, freshness and provenance.

Agree on a context contract

I would give a consequential AI workflow an explicit agreement about its evidence.

The agreement should establish what decision is being supported, who defines the applicable rule, which information the user may access, how current the evidence must be, how its origin is retained and what happens when the evidence is incomplete or contradictory.

Take a procurement assistant. An old email says a manager can approve a purchase. The current delegation register says a different role holds that authority. A useful assistant should identify the discrepancy and apply the agreed authority rules, or refer the case for clarification. Blending both sources into a smooth answer conceals the problem.

The same applies to dates. “The latest policy” needs a reliable meaning. Upload time, document-modified time and policy-effective date can tell different stories.

Define the evidence conditions before relying on the answer.

Test retrieval as well as the response

A polished answer can be based on the wrong document. A correct document can be retrieved for a person who should never have seen it. A valid citation can support only part of the claim beside it.

Evaluation needs to examine those separate questions. Did the system retrieve the right material? Was access authorised? Did the response accurately reflect it? Could a reviewer follow the evidence? Did the system expose a material conflict?

Microsoft's grounding guidance discusses data quality, access, freshness and lineage. Those are useful design concerns, but the organisation still has to define what they mean for its own workflow.

There is a practical ownership issue here. Data teams cannot independently decide the meaning of every business rule. Business owners cannot independently implement every access control. Architecture can help make the agreement between them explicit.

Before connecting another source, ask what question it will help answer, why it has authority and how its limitations will appear to the user. That conversation often uncovers more than another round of prompt tuning.