The handoff meeting for the assistant you now own runs long. You ask the questions any new owner would ask: what does the product answer from, who keeps those sources current, what does it remember about users, and how do we know the answers are grounded. Five people give you six different answers, because the platform engineer and the support lead disagree with each other, and the founding engineer disagrees with himself halfway through. Nothing is on fire. Retrieval works, the dashboards are green, and customers renew. But every decision that makes the product work lives in somebody's head, two of those heads have already given notice, and there is no page you can read, which means there is no product you can defend.
Why hallucinations are context failures, not model failures opened this part with the knowledge supply chain, a fact's route from source to index to retrieval to window to answer. Every chapter since has settled a decision at one link of that chain, and right now each decision lives wherever it was made, in a planning thread, a config file, or someone's head. This chapter moves them onto one signed page.
One page that answers the handoff questions
The Knowledge Charter makes the product's knowledge someone's signed responsibility: every source owned, every memory consented, every answer traceable.
The charter ships as a fillable PDF with six sections, each one compressing a chapter of this part into fields you can complete in an afternoon. It stays short because it only works if the next owner can read it in minutes and you can amend it in fewer.
Filled in, it answers the handoff questions in writing, and the rest of this chapter walks it section by section.
Write the source inventory and the freshness rules
The first two sections carry the decisions from Freshness and conflicts: govern the knowledge you answer from.
Sources and owners. One row per source the product answers from: the help center export, the pricing table, the CRM fields, the release notes. Each row carries a named owner, the person who hears about it when the source rots, and a content class, which groups sources by how fast they go stale (policy and pricing in weeks, reference material in years). A source with no owner in this table is a source you have already decided to let go stale; the table just makes that visible before a customer does.
Freshness SLAs and conflict rules. Each content class gets a shelf life, written as a freshness SLA (a service-level agreement, meaning a promised maximum age the class is never allowed to exceed). Then come the rules for the day the inventory fails anyway: the tiebreak, which source wins when two disagree (the system of record beats any export of it), and the recall path, the steps that pull a fact out of the index once it is found wrong, the way a defective part gets recalled from shelves.
Record the retrieval choices and the memory policy
Retrieval choices. This section compresses two chapters into a short table of question types. From Retrieval: let the product look things up before it answers: which questions get answered from the prompt alone, which get a one-shot lookup, and which get the agentic loop. From The search stack: match the retrieval method to the question: which method serves each question, keyword search for exact words, embeddings for meanings, a structured query for fields, and hybrid where prose mixes them. The section closes with the decline rule: when the lookup comes back empty, the product says it cannot answer instead of falling back on training data, because a declined answer costs you one conversation and a fabricated one costs you trust. The tools and prices behind these choices move too fast for a signed page, so the charter records the decisions and points at the Retrieval Stack Sheet for the current stack.
Memory policy. The one-page policy you drafted in Memory: decide what your product remembers drops in whole: the quadrant rules for what may be stored (durable inferred memory is confirmed by the user or absent), the visibility rule that the user can see, edit, and delete every record, and the retention table whose deletion path removes the record, its index entry, and everything derived from it.
Set the context budget and the grounding bar
The context budget. From Context budgets: fit the right facts into a finite window: the per-request split, roughly what fraction of the window goes to instructions, retrieved passages, memory records, and conversation history, and the squeeze order, which allocation gives way first when a request runs over. Write the squeeze order down, because the unwritten version gets decided by whichever line of code truncates last.
The grounding bar. From Grounding evals: prove the answer stands on the facts: the two metrics, whether retrieval delivered the passages the answer needed and whether the answer stayed on them, each with its threshold, and the release gate they guard: no change to the model, the prompts, or the index ships while either number sits below its bar.
Sign it, review it, and pressure-test it before shipping
The last field is a signature. The person accountable for what the product says in production, usually you, puts their name and a review date on it, because a charter the team wrote but nobody signed stays a document nobody answers for. From then on it is reviewed on a cadence (quarterly is a reasonable default, plus whenever a content class gains a source) and amended in writing, so the page stays the record instead of drifting behind the product.
Before the signature goes on, pressure-test the page against three failures you should expect.
- A source goes stale. Pick a real row and assume its owner left last month with the shelf life lapsed. Does the inventory say who owns the row now, and does the recall path actually pull the stale facts from the index?
- A user demands deletion. Walk a real deletion request through the memory section. Does the path remove the record, the index entry, and every derived summary, inside the time the policy promises?
- An answer fails a grounding audit. Assume next week's sample puts one metric below its threshold. Does the grounding section say what stops shipping, who investigates, and which links of the supply chain they check first?
If the page answers all three without you in the room, it is ready to sign; wherever it cannot, the field is not really filled, whatever text sits in it.
You arrived at this part with a product that answers and a supply chain nobody could draw. You leave with the chain drawn, every link governed, and one page that says so over a signature, which is the difference between a product that answers and a product whose answers you can defend, to a customer, a regulator, or the next owner in the handoff meeting.
Try it now
The drill is filling the charter, so block an afternoon and bring your real product.
Get the charter. Download the fillable Knowledge Charter and gather the notes from this part's earlier drills, because most fields are already drafted there, from the inventory and shelf lives to the memory policy, budget split, and grounding numbers.
Fill every field end to end. Work in the order this chapter walked: sources and owners, freshness rules, retrieval choices, memory policy, context budget, grounding bar. Where a field has no answer, make the decision now rather than typing a placeholder, because an empty field is a decision deferred to whoever hits the problem first.
Run the three pressure scenarios. On paper, retire a source owner and let a shelf life lapse, walk a deletion request end to end, and fail one grounding metric. Note every field that had no answer or pointed at a person no longer there.
Amend what failed and sign it. Fix the fields the scenarios exposed, put your name and the first review date at the bottom, and store the page where the next owner will find it before their handoff meeting.
Scale it down: if the whole product is too much for one afternoon, fill the charter for a single feature and the sources it answers from. The sections do not change with size, and a signed page for one feature beats an unsigned draft for the whole product.
Chapter Summary
- The Knowledge Charter is one signed page that records every knowledge decision this part taught: sources, freshness, retrieval, memory, budget, and grounding.
- Every source gets a row with a named owner and a content class; a source without an owner is a source you have decided to let rot.
- Each content class carries a shelf life, and two rules cover the failures: the tiebreak says which source wins a disagreement, and the recall path pulls a wrong fact out of the index.
- The retrieval section maps question types to methods and ends with the decline rule: an empty lookup produces a refusal, never a guess from training data.
- The memory policy drops in whole: quadrant rules, user visibility with edit and delete, and a deletion path that removes the record, the index entry, and everything derived from it.
- The context budget records the per-request split and the squeeze order, so truncation becomes a decision instead of an accident.
- The grounding bar sets thresholds on the two metrics and gates every release on them.
- The charter is signed by the person accountable for what the product says, reviewed on a cadence, and amended in writing; pressure-test it against a stale source, a deletion demand, and a failed grounding audit before you sign.
- This closes the Context and Memory part of The Frontier; when you are ready to put fleets of agents to work on your own backlog, Why one agent stops being enough is where to go next.
Sources
- Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.
- European Union (2016). General Data Protection Regulation, Article 17: Right to erasure.
- Anthropic engineering blog (2025). Effective context engineering for AI agents.
- Anthropic and OpenAI retrieval, memory, and context window documentation (last verified July 2026).