Govern the knowledge: what your product is allowed to read

Everything that connector reaches is a candidate answer, because retrieval does not distinguish a signed policy from an abandoned draft: it matches text to a question, and the model composes an answer from whatever it is handed. Freshness and conflicts: govern the knowledge you answer from built the system side: shelf lives, tiebreaks, and the recall runbook. This chapter is the organizational side: who decides what may enter the index, and where that decision is written down.

AI Overviews: the failure and the fix were both eligibility policy

In May 2024, Google turned on AI Overviews for US users: model-composed answers above the classic search results. Within days the screenshots were everywhere:

• Asked how to keep cheese from sliding off pizza, the product suggested adding "about 1/8 cup of non-toxic glue to the sauce", traced to an eleven-year-old Reddit comment written as a joke.
• Asked how many rocks to eat, it recommended at least one small rock per day, lifted from a 2021 story in The Onion that a geology software company had republished on its own site.

Notice what did not fail: retrieval matched the passages closest to each question, and the model summarized them faithfully. Almost nobody writes seriously about how many rocks to eat, a gap Google calls a data void, so the satire was the best available text, and the best available text was eligible.

The fix confirms the diagnosis. On May 30, Google's head of Search, Liz Reid, published "AI Overviews: About last week", describing more than a dozen changes, and the load-bearing ones were all corpus policy: "better detection mechanisms for nonsensical queries" that trigger no Overview, limits on satire and humor content, tighter limits on "user-generated content in responses that could offer misleading advice", and restrictions on query classes where Overviews were not helping. Google did not announce a smarter model that week; it announced new rules about what the product may read and when it may speak.

Whatever your product is allowed to read, it will eventually say.

The curation policy fits on one page

If Google's corpus is a governed decision, yours is too, and the governing document is short: what may enter (eligibility), who re-verifies each source and how often (freshness), which source wins when two disagree (conflicts), and what leaves and when (removal). Here is the policy the opening scene's support assistant should have had:

The conflict rule is one line. The policy doc outranks the marketing page, and between two versions of the same document, the newer dated version outranks the older.

The removal rule is one line too. A source whose review is missed twice, or whose owner leaves without a successor, loses eligibility, and eviction clears the index and its caches within one business day.

Owners are people rather than teams, the same discipline Ownership: one name on every model behavior applies to behaviors, and the date stamps and expiry flags that make each cadence cheap already live in your freshness SLAs. The rows marked not eligible earn their keep, because without them the connector's defaults decide for you: a connector pointed at "the wiki" reads the drafts too, unless someone writes down that it may not.

The decision record: who approved this source

New sources keep arriving after launch: a new connector, a reorganized wiki, a teammate who pastes a folder into the index to fix one unanswered question. Treat each arrival the way your codebase treats a pull request: someone proposes the source, the owner of its class reviews it against the eligibility rules, and the decision lands somewhere findable. Change control: ship prompt and model changes like releases already gives prompts and model swaps this treatment, and a new source changes your product's answers as surely as a new prompt does. When your head of support asks who approved the draft page, this record is the difference between an answer and a shrug. It looks like this:

A source enters your corpus the way code enters main: reviewed, owned, and revocable.

Curation never finishes: owners change roles, cadences come due, and the connector you added for one team quietly starts reading another team's folders. A policy written once and filed away governs nothing, so run it as a loop:

"Index everything and rank it" deserves a real answer

Your best engineer will make the opposite case: a corpus curated down to a handful of blessed documents answers "I don't know" for half of what users ask, and search engines solved this long ago by indexing everything and letting ranking put the authoritative source on top. The coverage half is right: a dozen approved documents will fail your users. The ranking half gives away your only hard guarantee, because ranking is probabilistic: it reorders whatever candidates exist, and where the authoritative candidate is missing, the data void again, the joke ranks first because nothing outranks it. Eligibility is the one deterministic control in the pipeline: an ineligible source cannot appear no matter how the ranking falls.

The two mistakes cost differently:

• A coverage gap shows up as a line in your unanswered-question log, and you close it next week with a table row and an owner.
• An ingestion mistake shows up as a screenshot of your product giving bad advice that no later fix recalls, which is why Google restricted entire query classes rather than trust ranking to bury the satire.

Widen the corpus as fast as you can review, never faster.

Try it now

This drill takes about fifteen minutes and spends no tokens. Your product's retrieval configuration is the new input, and the class-and-shelf-life rows of the Knowledge Charter you started in Freshness and conflicts: govern the knowledge you answer from supply the refresh cadences; if you skipped that drill, draft the cadences fresh and reconcile later.

Open what the product actually reads. Pull up the retrieval config: the connector list, the wiki spaces, the folders, whatever feeds the index. If you ship no retrieval yet, use the folder or wiki your team treats as its reference library.

Inventory the source classes. Write down every class the config reaches, including the ones nobody mentions: drafts, archived spaces, forum threads, shared drives, exported chat logs.

Fill the table. Mark each class eligible or not, and give each eligible class one owner by name, a refresh cadence, and a conflict rank.

Write the two rules. One conflict line (which class outranks which, and newer dated versions beat older ones) and one removal line (what costs a source its eligibility, and how fast eviction happens).

Scale it down: if the config reaches hundreds of spaces, write rows for the ten classes retrieval cites most and mark everything else "not yet eligible" as one batch row; a small governed corpus beats a large accidental one.

The page you just wrote is your curation policy: the companion to the system-side Write your Knowledge Charter and ship a product that knows its facts, and the knowledge section of the charter you assemble in Write your Operations Charter and run the operating review.

Chapter Summary

• Whatever your product is allowed to read, it will eventually say, so the reading list is an organizational decision, not an ingestion default.
• Google's AI Overviews recommended glue on pizza and a daily rock because a Reddit joke and an Onion satire were eligible sources, and the fixes Google announced were eligibility rules, not a smarter model.
• A curation policy fits on one page: an eligible-sources table with an owner, a refresh cadence, and a conflict rank per class, plus a one-line conflict rule and a one-line removal rule.
• Owners are people, not teams, and the "not eligible" rows matter most because connectors default to reading everything they can reach.
• A source enters the corpus the way code enters main: proposed, reviewed by the class owner, recorded where anyone can find it, and revocable.
• Ranking is probabilistic and eligibility is deterministic, so widen the corpus deliberately instead of indexing everything and hoping the authoritative source ranks first.
• A coverage gap costs you a log line you can fix next week; an ingestion mistake costs you a screenshot you cannot recall.
• The system mechanics behind the cadence column, the freshness SLAs, tiebreaks, and recall runbook, live in Freshness and conflicts: govern the knowledge you answer from.
• What the product reads is now governed; who may see what it says comes next, in Govern access and safety: decide who may see what.

Sources

• Reid, E. (2024). AI Overviews: About last week. Google, The Keyword blog, May 30, 2024.
• The Onion (2021). Geologists Recommend Eating At Least One Small Rock Per Day.
• Hart, R. (2024). Google Restricts AI Search Tool After 'Nonsensical' Answers Told People To Eat Rocks And Put Glue On Pizza. Forbes, May 31, 2024.
• Futurism (2024). The Reason That Google's AI Suggests Using Glue on Pizza Shows a Deep Flaw With Tech Companies' AI Obsession.