Context Is Not a Prompt: Introducing the Context Contract

For: AI platform engineers and enterprise architects. The decision: how to specify what an agent may know for a given purpose, before it starts to reason.

The launch note in this series, Why Enterprise AI Needs a Deterministic Shell, made one structural argument: let the model interpret and propose inside a Probabilistic Core, and keep identity, authority, schema, state and commitment deterministic in a shell around it. This note takes one part of that shell, the part that decides what the core is shown in the first place.

Correct context can still be the wrong context

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

Consider a national retailer with stores in every state and an employee-relations team that now works with an AI case assistant. An investigator opens case ER-2291: a store manager in Townsville says her long service leave request was refused on the wrong basis. She asks the assistant to summarise the applicable entitlement and the facts in the file.

The answer is fluent, cited and wrong. The assistant retrieved the Victorian long service leave procedure, because the employing entity is registered in Melbourne and that document was the closest semantic match. For most employees, the Fair Work Ombudsman notes, long service leave entitlements come from the laws of each state or territory, so the jurisdiction is not a detail. It decides the answer.

The second problem is quieter. Among the eight passages the assistant used was a note from a separate bullying investigation involving the same area manager. The investigator is allowed to open that file. She is not investigating it, and the note’s author had been told it would be used only for that case.

Neither item was false. Both were current, approved and within the investigator’s access. They belonged to another purpose.

More retrieval and longer prompts do not fix this

The usual responses treat this as a quality problem. Retrieve more passages. Buy the larger context window. Add a line to the system prompt: “Use only the policy for the employee’s state and never refer to other cases.”

Each one moves the decision to the wrong place. More retrieval raises the chance that the Victorian document and the other case both arrive. A prompt instruction asks the model to enforce a boundary it has no reliable way to check, and a model upgrade can quietly change how well it obeys. The instruction is a request, not a control.

The subtler fix is a permission filter on the results. Here it is applied after the ranker has chosen its top eight across the whole employee-relations library. By then the ranking service has already seen every restricted item, the slots have been spent, and the filter asks only “may this person read this?” The investigator may. What nothing asks is “does this purpose need it?”

Least privilege, as Saltzer and Schroeder framed it for access to resources, applies to knowledge too: a component should receive only what its task requires. A context window is simply the newest place that principle has to be enforced.

The CAE reading: context is a governed interface

The Context Contract is an author-proposed model within the Contextual Agentic Enterprise (CAE), the vendor-neutral architecture the book sets out. It is a declared, versioned and testable specification of the context a given agent purpose may receive: on whose behalf it acts, which domains and tools it may draw on, what state and history it sees, its budgets, the provenance it must carry, how sensitive material is handled and what shape its output takes.

The shift is from context as a pile of strings to context as an interface with an owner. The contract sits on the deterministic side of the shell. The model still interprets the Queensland procedure and the facts of ER-2291. It does not decide which jurisdiction applies or which case files are in scope; those are resolved before it sees anything.

A minimal public example for the case assistant might look like this. The field names are illustrative, not a schema.

contract: er-case-assistant
revision: 2026-09.2
purpose: support-one-er-investigation
acting_for:
  role: er_investigator
  scoped_to: current_case_only
sources:
  allow: [er-policy-library, current-case-file]
  jurisdiction_from: employee.work_location.state
  effective_on: case.event_date
  each_item_carries: [source_id, source_version]
never_include: [other-case-files, medical-certificates]
evidence_limit: 10
answer_shape: finding-with-citations-and-open-questions

Two lines do most of the work for ER-2291. jurisdiction_from makes the state a property of the case, derived from the employee record, not a semantic guess. never_include and scoped_to turn “another case” from a judgement into a rule. The revision number means that, months later, anyone can say which contract produced the summary.

This example is deliberately incomplete. The book gives the complete contract, including the tool, state, history and compression elements left out here, and the ordering in which permission filtering happens before selection during context assembly.

Assemble context in a fixed order

The contract is only as good as the pipeline that honours it. A practical procedure for any agent purpose:

1. Resolve purpose and principal first. Before retrieval, bind the request to a named purpose, a principal and, where relevant, a case. No purpose, no context.
2. Derive scope deterministically. Jurisdiction, effective date and tenant come from authoritative records, not from the text of the question.
3. Filter before you rank. Remove everything outside permission and purpose before any ranker or model sees a candidate.
4. Select within budget. Rank what remains, and stop at the evidence limit rather than at the size of the window.
5. Carry provenance. Every passage keeps its source identifier and version into the model’s input and into the output.
6. Stamp the revision. Record the contract revision with each response, so the output can be tied to the rules that shaped it.
7. Test the contract, not just the answer. A Townsville case must never retrieve the Victorian procedure. A request under ER-2291 must never return a passage from another case file, even when the investigator can open it.

The last step matters most. Context assembly can be tested on its own, without judging the model’s prose. If the tests pass only when the model happens to know Queensland law from training, the pipeline is broken and the model is covering for it.

How Context Contracts fail

Correct but belonging elsewhere. The ER-2291 failures in miniature: true, current content that serves a different purpose or jurisdiction. Contracts that describe access rather than purpose miss it entirely.

Filtering after selection. Removing restricted items from a ranked list leaves the ranker exposed to them and the budget spent on them. It can also leak through side channels such as caches keyed only on the question text.

No version. A contract edited in place cannot explain last quarter’s answers. When the store manager disputes the outcome, the organisation needs the revision that applied then, not the one in force today.

A contract that nothing enforces. A YAML file in a repository that the retrieval code never reads is documentation. This is the context form of the shell drift the launch note described.

Over-tight scope. Starve the model of a needed source and it may fill the gap from its training data, which looks like an answer and cites nothing.

What the contract does not solve is worth saying plainly. It does not make the model interpret a policy correctly. It does not stop an instruction hidden inside a permitted document from influencing the model. It does not repair a policy library where the Queensland procedure was never loaded. And it grants no authority to act: reading the right context is not the same as being allowed to change a leave record, which is the subject of next week’s Field Note, The Commit Boundary.

Who does what

Executives decide that every production agent has a named purpose and an owner for its context rules, and that “the assistant can see everything the user can see” is not an acceptable default for sensitive domains such as employee relations.

Architects design context assembly as a service with a fixed order: purpose, scope, permission and purpose filtering, then selection. They make jurisdiction, effective date and case scope resolvable from authoritative records, and keep the contract outside the prompt.

Engineers implement and test the contract as configuration that the pipeline reads at run time, with its revision logged on every call. They write negative tests for wrong-state and cross-case retrieval, and run them on every change to the index, the ranker or the model.

One case, four places to put the control

Key takeaways

• Most serious context failures involve true, current material that belongs to a different purpose, jurisdiction or case.
• A Context Contract, as CAE proposes it, declares and versions what a given agent purpose may receive, and belongs to the Deterministic Shell rather than in the prompt.
• Scope such as jurisdiction and effective date should be derived from authoritative records before retrieval, never inferred from the wording of a question.
• Permission and purpose filtering must happen before selection, because a filter applied to ranked results is too late and asks the wrong question.
• Context assembly can and should be tested separately from the model’s answer.

Sources and further reading

• The Contextual Agentic Enterprise, Chapter 5 (context engineering and the Context Contract), Chapter 6 (permission-aware retrieval) and Chapter 7 (scope, time and competing policies).
• Saltzer, J. H. and Schroeder, M. D., “The Protection of Information in Computer Systems”, published in Proceedings of the IEEE 63(9), 1975. https://doi.org/10.1109/PROC.1975.9939
• Fair Work Ombudsman, “Long service leave” (accessed 22 September 2026). https://www.fairwork.gov.au/leave/long-service-leave

Where the book takes this further

The book gives the complete Context Contract, the permission-before-selection ordering of context assembly, and the context tests that check a pipeline independently of the model’s output. Next week, The Commit Boundary looks at the other end of the shell, and the week after, Evidence-First Decision Records looks at how a contract revision becomes part of what the organisation can later reconstruct.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.