Most teams end up with three piles of product knowledge that never talk to each other. The cost is not that answers are hard to find. It is that nothing can notice when one pile contradicts another, so nobody is ever asked.
A Product Brain is a single source of truth about a product that every agent reads from and writes to, with a human gate on the claims that actually need judgment. It is organised as The Three Layers of Product Truth, which is defined as the three distinct questions a product knowledge base has to answer, each with its own source and its own refresh cadence: what exists, derived mechanically from code and schema; how it is used, compiled from support content and delivered specifications; and what changed, extracted from merged pull requests. Teams reliably build one of the three and mistake it for the whole thing. The work that turns three layers into a brain is not merging the files. It is giving them a shared node identity, so that a new fact arriving in one layer can contradict an old fact in another and put the question in front of a person.
Walk into any company that has been shipping for a few years and you will find knowledge in at least three shapes, usually owned by three different people who have never compared notes.
| Layer | Question it answers | Where it comes from | Re-derivable? |
|---|---|---|---|
| Structure | What exists | Code reflection and live schema, at a pinned commit | Yes, mechanically |
| Usage | How it is used | Support articles, delivered specs, expert statements | Yes, from dated snapshots |
| History | What changed | Merged pull requests and the tickets they closed | No. It is history |
The temptation is to declare two of them redundant and consolidate. They are not redundant, and the sentence worth repeating until it stops being re-litigated is this one.
A changelog contains no base state, and no quantity of changelog entries ever becomes a manual.
The reverse is equally true. A manual cannot tell you what shipped last week, and a schema dump cannot tell you what any of it means. Each layer is necessary. The problem is never that one of them is wrong. It is that they have no edges.
In our engagements we consistently find the same anatomy. Each layer was built at a different time by a different person, so each invented its own vocabulary, its own taxonomy and its own status lifecycle. The structure layer is keyed on code module folders. The usage layer is keyed on whatever categories the support portal happens to use. The history layer is keyed on free-text tags, most of which appear exactly once. The three taxonomies overlap by almost nothing, and so there is no mechanical path from a question to an answer that spans them.
Here is what that costs, and it is not a filing problem. A team compiles a page on how a feature behaves, notices that two support articles disagree, writes to be arbitrated by a human and escalates. The answer had been sitting in the next folder for weeks, written the day the code merged, stating the resolution order precisely. Nothing connected the two. Worse in the other direction: the support article being quoted correctly and verbatim had been made obsolete by that same merge, and nobody raised it, because no channel existed through which a merged pull request could reach a support article.
A knowledge base that cannot contradict itself cannot tell you it is wrong.
This is the real argument for connecting the layers. Better search is a pleasant side effect. Contradiction detection is the payoff, because it is the only mechanism that can tell a human they need to look at something.
The common first attempt at a company brain is to map everything up front: mission, strategy, brand, deep cross-domain flows, all written before a single agent has shipped one validated piece of work. It reads beautifully. It collapses anyway, and it usually takes a quarter to admit it.
Calling that scope creep names the symptom. The cause is sharper and far more useful:
Content with no source has no owner, no expiry, and no possible approval act.
You cannot check a page against nothing. So nothing can ever invalidate it and nobody can ever sign it off. It is unfalsifiable by construction, which is why it rots silently rather than failing loudly. The rule that prevents it is one line: every claim in the brain is anchored, word for word, in a dated artefact a human produced somewhere else. A claim nobody can trace is a claim that does not enter.
That single rule does most of the work. It is what makes a lint possible, what makes an approval meaningful, what makes staleness detectable, and what keeps the brain a derived view rather than a second source of truth competing with the first. Two corollaries we now write into every engagement: quote in the source language, because a translated quote cannot be checked mechanically; and the brain never edits its own sources, because an agent that corrects the article it quotes has just created a competing truth.
A node is one concept. It is not a file produced by one layer. It sits above the layers and points at them, carrying one human-approved paragraph and nothing else of its own.
The instinct is to flatten all of that into one file per concept. Resist it, for three reasons that are mechanical rather than stylistic. First, refresh semantics: you cannot regenerate a file that also contains hand-written prose and historical facts without destroying them. Second, truth lifetime: a schema fact is true as of a commit, a usage fact until the interface changes, a history fact forever, and one status field cannot honestly describe three claims with three expiry rules. Third, checkability: a verbatim-anchoring lint cannot run over a file that also holds machine-derived tables, so you either get failures on content the lint has no business checking or you relax it until it checks nothing.
Keeping the facets separate also buys something you cannot get any other way: the ability to say the schema changed but the how-to is still correct, which is true far more often than not, and is the difference between a useful review queue and a noisy one.
None of this needs a graph database. Markdown files with links between them are already a graph. The Open Knowledge Format specification, published by Google Cloud in mid-2026, treats a link from one concept to another as a relationship assertion, supports many sources per concept with their own credibility signals, and carries an explicit staleness field. It also, tellingly, defines no contradiction handling and no approval workflow. Those two are what you build on top, and they are the defensible part of the work.
This is the decision that makes the whole thing tractable, and getting it wrong is how teams drown their reviewers in the first month.
| Class | Example | Gate |
|---|---|---|
| Machine-derivable facts | A column type, an enum's values, a route's permissions | None. Diff review on regeneration |
| Anchored quotes | A sentence lifted verbatim from a dated source | None. The lint checks the anchor |
| Interpretations and resolutions | Which of two contradicting sources wins, and what the rule actually is | Human, always |
Gate all three and a person spends their week ticking off varchar(255), learning nothing and signing nothing meaningful. Gate only the third and the queue becomes something a human can finish. The third class is by far the smallest: a typical first pass is fifteen to fifty resolution nodes sitting above several hundred generated facts. The approved surface of a Product Brain is small by design, and the bulk underneath it stays generated, linted and unreviewed. That is correct, not a gap to close later.
Two placements, and the difference between them is the most expensive thing to get wrong.
At publication. A reviewer, later, in a session, rebuilding context about a claim they did not write. High marginal cost per item. Worse, it scales inversely with agent usage: the more your agents produce, the more context-rebuilding per approval, so the review session silts up exactly as the system starts working.
At the moment of work. The agent that just shipped asks the engineer who reviewed the change, in the pull request, now, while they still hold the context. Near-zero marginal cost, and it scales with usage rather than against it.
The published evidence points one way. SAP's production system for coding-agent memory, documented in a 2026 deployment paper, puts human approval in the contributor's own client: the developer whose session produced the learning approves the diff before it leaves their machine, and everything downstream is automated. Their snapshot of 22 July 2026 is also a useful planning number for anyone building this: of 900 contributed learnings, 417 produced nothing at all. That is 46.3% waste, and it is normal. Budget for roughly half your queue to be noise and make discarding fast.
The same paper reports something that validates the structural argument above: 1,100 of their 1,144 curated memories, or 96.2%, carry at least one semantic link, with 7,863 links across 35 tools and frameworks. They arrived independently at the conclusion that isolated facts are close to useless. What they explicitly do not have, and say so, is a contradiction-resolution mechanism.
There is a shortcut that looks like autonomy: let agents propose claims and commit them automatically when a confidence score clears a threshold. It is the single most tempting design in this space and the evidence is against it.
The STALE benchmark tests precisely this capability: can an agent tell that something it already knows has been invalidated? Across 400 expert-validated conflict scenarios producing 1,200 queries, the best evaluated model reached 55.2% overall accuracy. The authors name the failure mode Implicit Conflict, where a later observation invalidates an earlier memory without contradicting it outright, and they find a gap between retrieving the updated evidence and actually acting on it. The agent can hold the new fact and still answer from the old one.
A second 2026 benchmark, TANGLE, gives the problem a taxonomy worth knowing: 541 instances across 40 personas, splitting conflicts into context-partitioned, behaviour-oscillation and source-contradiction. That third type is exactly what a Product Brain faces when a merged pull request invalidates a support article.
So detection must be structural rather than probabilistic. Give every claim a subject and relation key, which in this model is the node and the facet type. If an incoming facet shares the key of a stored one but asserts something different, the newer supersedes the older, independent of any similarity score. Flip the resolution to stale, open a conflict, and put one row in front of a person. Embedding similarity is the wrong tool here for a structural reason: retrieval has no model of time, so when a fact changes, a vector search returns the stale value and the current value at near-identical scores.
The mechanism is the easy part. Throughput is what kills these systems, and it kills them quietly. Four things we now insist on from day one.
An intake rate above the approval rate turns the queue into a backlog, the backlog into unverified content, and the unverified content into a brain nobody trusts. It looks like success for about six weeks.
This is the knowledge-layer instance of a rule we apply across the whole factory and wrote about in where human judgment actually sits: autonomy cannot exceed verification capacity. A brain that writes faster than anyone can confirm is not more autonomous. It is just wrong faster.
Steps one to three are days of work and are independently useful. A join key plus fifteen nodes would have caught the contradiction described earlier with no software at all. That is the minimum viable Product Brain. Everything after it makes the catch automatic rather than lucky.
The Product Brain is the operational layer underneath the framework we set out in the five levels of Company Brain. Level 2 is a flat wiki that degrades because it needs constant human maintenance. Level 4 is a structured graph agents can reason over. The Product Brain is how you cross that gap without the thing rotting on the way: the layers stay separate and re-derivable, the edges are curated rather than extracted, and the only human attention spent is on claims that genuinely need a judgment.
It also changes what the top of that ladder means. A fully autonomous brain is not one with no humans in it. It is one where the cost of human confirmation has stopped scaling with volume, because contradictions are detected mechanically, the right person is asked at the moment of work, and a claim nobody confirms expires instead of hardening quietly into fact.
A Product Brain is a single source of truth about a product that every AI agent reads from and writes to, with a human gate on the claims that need judgment. It is organised as The Three Layers of Product Truth: structure, usage and history. The layers are connected by a shared node identity, so a new fact arriving in one can contradict an old fact in another and raise the question with a person.
The Three Layers of Product Truth is defined as the three distinct questions a product knowledge base must answer, each with its own source and refresh cadence: what exists (modules, entities, fields and screens, derived mechanically from code and schema), how it is used (one page per question a human would actually ask, compiled from support articles and delivered specs), and what changed (one document per shipped change, extracted from merged pull requests). None substitutes for another.
Because an agent is unreliable at noticing that something it already knows has been invalidated. On the STALE benchmark, which tests exactly this across 400 expert-validated conflict scenarios, the best evaluated model reached only 55.2% overall accuracy, and the researchers found a gap between retrieving updated evidence and acting on it. Detection should be structural and mechanical. The judgment stays human.
At the moment of work, not at publication. A gate at publication asks a different person to rebuild context about a claim they did not write, so it scales inversely with agent usage. A gate at the moment of work asks the person who is already there. SAP's published production system puts approval in the contributor's own client, before the contribution leaves the machine, and automates everything downstream of it.
No. Markdown files with links between them are already a graph, and the Open Knowledge Format treats a link between concepts as a relationship assertion. The expensive part of graph-shaped retrieval is extraction, where a model derives entities and relations across a whole corpus and redoes it as the corpus changes. When your edges come from a curated mapping table and from file paths, you skip that cost and get better edges than extraction produces.
The join key and the first ten to fifteen nodes are days of work, and they are independently useful before any tooling exists. The conflict detector, the review queue and the apply step are roughly another week or two. We build this as part of an AI Transformation Sprint, where the team that will own it afterwards builds it with us rather than receiving it.
Above The Clouds runs the AI Transformation Sprint and the AI Product Studio. If your agents are already doing real work but nobody can say where the product truth lives, the Product Brain is usually the highest-leverage thing to build next, and it is smaller than it sounds. Get in touch to discuss your company or portfolio.