Context governance at scale
TL;DR
One AI feature's context pipeline is a product-design problem. Twenty AI features' context pipelines, sharing policies, retrieval corpora, and memory stores across teams, is a governance problem — and it fails in ways a single-feature review never catches. The same refund policy gets encoded three different ways in three different prompts. A retrieval corpus gets updated for one feature and silently goes stale for another that shares it. Nobody can answer, after an incident, exactly what a specific model call saw six weeks ago. Context governance is the organizational layer that keeps context consistent and auditable across features, not just correct within one.
🎯 For the product leader
Why it matters — At small scale, context problems are a support ticket. At multi-team scale, an inconsistent or stale shared context source is a compliance exposure, a legal discovery problem, or a customer-facing contradiction between two different AI features.
What it changes in your decisions — You treat shared context sources — policy documents, retrieval corpora, org-level memory — as owned, versioned assets with a single source of truth, the same way you'd govern a shared database, instead of letting each feature team maintain its own copy.
Ask yourself — "If two of our AI features gave a customer contradictory answers about the same policy today, could we find out why within an hour?"
Risk if ignored — Every team's AI feature quietly drifts from every other team's, until a customer notices the contradiction before anyone internally does.
The mental model: one source, many consumers
One source, many consumers · governance answers "who re-syncs, and how do we know?"
Sources always eventually change. The failure is each consumer copying it at a different point in time.
The failure isn't the source going stale — sources always eventually change. It's that each consumer copied the source at a different point in time, with no mechanism telling them a newer version exists. Governance is the answer to "who re-syncs, and how do we know when they haven't?"
What this covers, and what it deliberately doesn't
This lesson is scoped to shared context sources across features and teams: policy documents, retrieval corpora, and org-level memory stores that more than one AI feature draws from. Two adjacent governance questions already have dedicated, deeper treatments elsewhere, and this lesson spokes out to them rather than restating them: user-facing memory trust — staleness, leakage, and the right to be forgotten for an individual user's data — is covered in When memory goes wrong. Knowledge-asset governance — provenance, permissions, and quality metrics for a structured knowledge graph specifically — is covered in Governance, quality & trust.
The three governance moves that actually scale
- A single source of truth, versioned. Every shared policy or corpus lives in one place with a version and a changelog, not copy-pasted into each feature's prompt. A policy change becomes one edit, not a hunt across every team's codebase.
- A registry of consumers. For every shared source, know which features read from it. Without this, "we updated the refund policy" can't be followed by "so we notified the three features that use it" — because nobody knows there are three.
- A staleness SLA. Decide, per source, how old is too old — a policy doc reviewed quarterly, a retrieval corpus refreshed daily — and alert when a consumer falls behind its source's SLA, not just when the source itself goes untouched.
Trust and permissions: what may enter the context
Governance also decides which content is allowed into the context, and how much the model may trust it. Two problems come with scale.
- Not all context is equally trusted. Your own instructions are trusted. A retrieved web page, a customer email, or a tool result is not. Any of them can contain text written to look like an instruction. That is indirect prompt injection. Keep untrusted content clearly separated from instructions, and never let it grant new permissions. Delimiters help but do not solve it. The layered defence is in the security module.
- Retrieval must respect access rules. If the retrieval step can fetch a document the current user may not read, the model can repeat it. Apply the user's permissions when you retrieve, not after the model has answered. Shared corpora make this harder, because one index may hold content for many audiences.
Add both to the source registry. For each shared source, record who may read it and whether its content is trusted or untrusted. Then a review can ask a concrete question: which untrusted sources reach which features, and what can those features do?
Failure modes
- Policy drift — the same rule encoded independently in multiple features, updated in one and silently left stale in the others.
- The untraceable answer — after an incident or a compliance request, nobody can reconstruct what a specific past model call actually saw.
- Governance theater — a governance document exists, but no registry connects a shared source to the features that consume it, so the document can't actually be acted on when something changes.
- The over-permissive index — retrieval searches everything and filters later, so a user's question can surface a document they should never see.
- Untrusted text with authority — a retrieved page or tool output is placed next to the instructions with no separation, so text inside it is treated as a command.
Practitioner checklist
- For each shared context source (policy, corpus, org memory): do we have a version, a changelog, and a list of which features consume it?
- If a shared policy changed today, is there a step that notifies every consuming feature, or does each team have to notice on its own?
- Could we reconstruct, for a specific past model call, exactly what context it was given — for an audit, an incident review, or a legal request?
- For each shared source: is it marked trusted or untrusted, and does retrieval apply the current user's access rights before anything reaches the model?