AI Governance · Evolved from Context Engineering / Information Architecture
The Context Contract
Treat the information environment an agent operates in as a product surface. Every production agent gets a written contract for allowed sources, freshness SLAs, forbidden corpora, memory scope, citation requirements, and a named owner of the context pack. A strong prompt in a weak context still fails.
Executive Guidance
How to hold this framework as a leader
The model is not the room. The context is. An agent with the right tools and the wrong corpus will still act confidently on stale, incomplete, or contaminated information. The Context Contract is the written product definition of what an agent may see, remember, and cite.
Pair it with Agent Autonomy Tiers and The Tool Contract. The tier is the ceiling of action. The tool contract is the inventory of verbs. The context contract is the inventory of knowledge. A T1 agent reading unscoped PHI is not T1 in practice.
When to Apply
- Before shipping any retrieval-augmented or multi-agent workflow to production
- When agents can read tickets, email, EMR/EHR notes, CRM records, or private docs
- When hallucination, stale policy, or cross-tenant leakage is a material risk
AI-Era Notes
Prompt engineering is a subset of context engineering. Product owns the context architecture: which sources are in-scope, how they are selected and compressed, how memory persists across turns, and what must be cited. Re-attest the contract when sources, embeddings, chunking, or memory policies change — those are product launches, not infra tweaks.
Key Trade-off
Richer context raises task success and leakage risk together; unsigned context packs become shadow product.
Operating Sequence
The order in which to install the framework
- 01Inventory every source, corpus, memory store, and retrieval path the agent can currently use.
- 02For each, write a one-page contract: purpose, allowed source classes, freshness SLA, forbidden corpora, isolation boundary (tenant/case/user), citation requirement, compression/selection rules, named owner, kill or quarantine path.
- 03Forbid sources that lack a product owner, freshness rule, or isolation boundary. Default is deny.
- 04Bind the contract into the PRD + eval spec. A new corpus, embedding refresh, or memory policy is a new ship, not a hotfix.
- 05Re-attest when models, chunking, retrieval ranking, or memory scope change.
Key Artifacts
The documents this framework produces
Context Inventory
Complete list of sources and memory stores with owners.
Owner: Product + Security
Context Contract
One page per source pack: classes, freshness, isolation, citation, kill path.
Owner: Product
Provenance Log
Durable record of what was retrieved and cited per consequential answer.
Owner: Product + Engineering
Operating Checklist
What "good" looks like when installed
Inventory
- Every production source is listed with a named owner.
- Memory stores declare tenant/case/user isolation.
- Cross-tenant or cross-case retrieval is explicitly forbidden unless justified.
Contract
- Allowed source classes are named (not "all docs").
- Freshness SLA is numeric.
- Citation is required for consequential answers.
- Forbidden corpora are listed.
Ship gate
- Eval cases cover stale, missing, and contaminated context — not just the happy path.
- Quarantine or kill path for a poisoned source is documented and tested.
- Context pack changes are logged as product launches.
Common Antipatterns
- Dumping entire corpora into the window and calling it RAG
- Shared memory across tenants, cases, or customers without isolation
- No freshness SLA (agents citing expired policy as current)
- Citation optional for consequential answers
Boardroom Questions
- Can we name the owner of every corpus our production agents can retrieve?
- Which answers require citation, and which of our agents currently skip it?
- When did we last remove a source rather than add one?
Pairs With