The short version
Put in what a general model does not already have. It has read every product management book and blog; what it lacks is a position on any of it, and a position is the only thing that changes an answer. Load three kinds of material: claims you are willing to defend, artifacts it can fill in with your situation, and canonical links it can fetch when a decision turns on a detail. Leave out definitions, framework explainers, and glossaries, which spend your context window reproducing the consensus you were trying to escape.
The test that sorts it
Before a document goes in, ask whether any line in it would change an answer the model would otherwise give.
"RICE scoring weighs reach, impact, confidence, and effort" fails the test. The model knows. It will produce that paragraph on request whether or not you uploaded it.
"We kill anything that has not produced a measurable outcome within two quarters, and the person who proposed it writes the postmortem" passes. That is a rule with a failure condition, and a model carrying it will stop suggesting you keep instrumenting a thing you should be shutting down.
Most knowledge bases I see are made almost entirely of the first kind. They feel substantial and they change nothing.
The three kinds worth loading
Positions. Claims with enough specificity to be wrong. Five is plenty. The corpus on this site carries exactly five, including that agent count is a vanity metric and that what matters is how many agents still complete production work after ninety days. An assistant carrying that claim pushes back when you ask it to write a board slide about how many agents you deployed, which is the entire value.
Artifacts. Templates it can fill in rather than describe. A decision log with your fields, a kill-review rubric, a brief structure. The difference between an assistant that explains what a good PRD contains and one that hands you yours, half-drafted, is entirely in whether the template is in the project.
Links. Every summary should carry a canonical URL. This is the part people skip, and it is what lets a small file behave like a large one: the assistant works from the summary until a decision depends on the detail, then fetches the full argument. It also means you can tell where an answer came from, which matters the first time it confidently tells you something you never wrote.
What I actually ship
The Falkster Corpus is this exact structure, built from 30 years of practice and regenerated from the site on every deploy: five claims, 41 handbook chapters, 44 agent blueprints, 113 templates, and the whole answer library, each entry a summary with a canonical link. About 194 KB, which is roughly 50 thousand tokens, and that size is the constraint doing the work rather than an accident of what fit.
Start with it if you want something to react to. Then cut what does not match your org and add the three PRDs that do, which is the part nobody else can write for you.
Sources: The Falkster Corpus.