Library · Data Practice OS
Context engineering for decisions
Reference guide · Published · Source reviewed
Short answer. Context engineering is deciding what goes into the model's context for a task, from where, and under whose permission. For a decision, the rule is simple: assemble what this decision needs, no more, under this user's permissions, and record what was assembled. The mechanics (retrieval, tools, MCP) are covered in RAG and enterprise search and Agents and MCP. This page covers the decision view: what to assemble and how to know it is enough.
Status. Proposed practice. Not an agreed decision. It applies the context sufficiency gate in the AI readiness assessment to a single decision.
Start from a context specification
For each decision type in the Decision inventory, write a short context specification. It is the contract between the decision and the data practice.
| Element | Example: licence renewal recommendation |
|---|---|
| Facts (live query, as at now) | Licence class and status; suspensions; medical condition flags |
| Meaning | The glossary definition of "eligible"; resolved customer identifier |
| Knowledge (retrieved, with version) | Current renewal procedure; applicable exceptions |
| Rules (evaluated, not retrieved) | Eligibility decision table, version effective today |
| Process state | Documents received; checks outstanding |
| Authority | The officer's delegation |
| Must not include | Other customers' records; health details beyond the flag; superseded procedures |
| If missing | Stop and escalate. Never recommend on a missing medical flag |
The worked example in AI readiness assessment tests this specification with missing data, conflicting rules and an above-delegation case. Those tests become the evaluation set.
Five rules for assembling context
- Facts by query, knowledge by retrieval, rules by evaluation. Changing facts come from a live query on the system of record or a fresh data product. Documents come from retrieval. Rules are run (a decision table or rule service returns the answer and its version) and the result goes into context. Do not ask a model to read a fee schedule and work out the fee.
- The user's permissions, not the service's. Every query and retrieval runs with the requesting user's identity or an equivalent scope (Identity propagation). If the officer cannot see a record in the core system, the assistant cannot put it in context. Tool calls go through the Tool gateway.
- Version everything that enters. Each item carries its source, version or as-at time, and classification, so the Decision record can cite it (Decision provenance).
- Precedence is explicit. When a procedure document and a rule card disagree, the specification says which wins, and the assistant flags the conflict rather than choosing silently.
- Less is more. Irrelevant context lowers answer quality and raises cost and exposure. Use the Semantic layer to fetch the metric, not the table; retrieve the paragraph, not the manual.
Memory is context too
Conversation history and agent memory are context sources with their own retention and permission rules. Treat a fact remembered from an earlier session as stale until re-queried, and never as authority for a decision (Agent memory, Agent memory).
Is the context enough?
The context is sufficient when the evaluation set passes, including the cases where the right answer is "I cannot decide; escalate". Measure:
- Coverage: for each case, was every required element present?
- Leakage: did anything in the "must not include" list appear?
- Citation: does every claim in the output trace to an item in the assembled context?
- Escalation: did missing or conflicting context lead to a stop, not a guess?
These sit alongside answer-quality measures in Evaluating AI systems.
Not when
- For an open-ended exploration tool with no decision attached, a lighter retrieval design is fine. Use RAG and enterprise search directly.
- Do not hand-assemble context in prompts per use case. Build the context specification once per decision type and reuse the same governed tools (Agents and MCP).
- Do not use a large context window as a substitute for a specification. Putting "everything" in context breaks rules 2, 3 and 5 at once.
Related: Decision modelling with DMN, Decision records and provenance, When a knowledge graph earns its place.
Source links: Data Practice reading list.