Search the knowledge graph

Copy page

Memories are text. The knowledge graph is the structure Brain derives from that text: the things your memories talk about, and how those things relate to each other.

Memories are text. The knowledge graph is the structure Brain derives from that text: the things your memories talk about, and how those things relate to each other.

Brain builds it for you. Nothing is declared, tagged or maintained by hand — as memories are processed, the product-relevant things they mention become entities, and the stated links between those things become typed relations. Every entity keeps a trail back to the memories it was extracted from, so anything the graph tells you can be traced to what was actually written.

The graph is derived, not authored: you shape it by what you store in Brain, and it is read-only for everyone else.

How the graph is built

Brain processes new memories in the background, shortly after they are written. Part of that work reads the facts distilled from your recent memories and asks one question: which product entities and relations does this text state? What comes back is checked against a fixed vocabulary — the product ontology below — and anything outside it is discarded.

Three rules govern what lands in the graph:

• Only the vocabulary. An entity whose type is not one of the 15 listed types is dropped. So is a relation whose type is not one of the 20.
• Both ends must exist. A relation is stored only when both of its endpoints are entities Brain already knows or extracted in the same pass. A link to something that was never extracted is discarded rather than invented.
• One entity per thing. Entities are canonicalised by name: a second mention under a different surface form merges into the existing entity, and the new form is kept as an alias. Checkout, checkout flow and Stripe Checkout end up as one entity, not three.

Extraction is incremental. Each fact feeds the graph once, and later memories extend what is already there — adding aliases, adding evidence to an entity that already exists, adding new relations. An entity’s evidence count is how many memories it has been extracted from so far, which is a fair proxy for how often you have talked about it.

Because this runs after the write rather than during it, a brand-new memory shows up in the graph a little later than it shows up in search. Extraction is also best-effort: a memory that states nothing about the product contributes nothing, and that is the normal case for a lot of everyday text.

The graph respects the same visibility rules as the memories behind it. What you see is what you are allowed to see — the product’s shared knowledge plus your own private memories. See what a memory is for how those scopes work.

The product ontology

The vocabulary is fixed and product-oriented: it describes a product being built and the business around it. Both lists below are complete.

Entity types

Two distinctions decide where things land:

• Technology is what the product is built with; Integration is what it calls at runtime. Something that is both is classified as an Integration.
• A Hypothesis is still open. Once it is acted on it is recorded as a Decision; once it threatens the business it is a Risk.

Relation types

Relations are directed unless marked otherwise, and each type only accepts certain kinds of entity at each end.

competes_with is the only symmetric type — it reads the same in both directions. Everything else has a source and a target, and the direction carries meaning: chosen_over points from the option you picked to the one you rejected, supersedes from the newer thing to the older one.

There is deliberately no generic “relates to”. If a connection does not fit one of the twenty types above, it is not recorded as a relation — the memories still hold it, and plain search still finds it.

What you can do with the graph

Four capabilities, available to the people and the agents working in your product. The platform publishes the tools that call them — see look up a Brain tool.

• Find an entity. Search entities by name or by any of their aliases, or list everything of one type — every Decision, every Risk, every Integration. Results carry the entity’s type, its display name, its aliases, its short description and its evidence count, and they page.
• See its neighbourhood. Given one entity, expand outwards to everything connected to it: the neighbouring entities and the relations that hold them together. The expansion goes up to three hops, and can be narrowed to a single relation type (“only what this depends on”) or a single kind of neighbour (“only the risks around it”). An entity can be named directly — its own name or an alias works, no identifier required.
• Follow relations. List relations across the whole graph instead of around one entity: everything of one relation type, everything leaving a given entity, everything arriving at it. Each relation names both ends, and carries the reason recorded when it was extracted.
• Get back to the memories. Every entity lists the memories it was extracted from, newest first. This is the answer to “why does Brain think this?” — the graph never asks to be taken on trust.

The same graph reads two ways: as lists — entities on one side, relations on the other — and as a picture, where node size shows how connected an entity is, colour groups related entity types, and a legend names each type and filters it in or out. Selecting a node shows that entity’s relations and the memories behind it, and any relation there can be followed to the entity at its other end.

Very large graphs are drawn in part rather than in full. When that happens the most connected entities are the ones kept, so the picture stays a map of the hubs rather than an arbitrary slice.

Some of what the graph connects was never submitted by anyone: Brain writes memories of its own when it consolidates what it holds. See how memory maintains itself.

When the graph answers what search cannot

Plain memory search answers questions about text: it finds the memories that talk about a thing. The graph answers questions about structure — questions whose answer is a set of connections, not a passage.

• “Everything connected to this customer segment.” Search returns the memories that happen to mention it. The neighbourhood returns the features they asked for, the plans aimed at them, the channels that acquire them and the metrics that measure them — including the ones no single memory ever mentions in the same sentence.
• “Which decisions touch this component.” The connection between a decision and a component is often stated once, months ago, in wording you no longer remember. Following relations finds it without you having to guess the words.
• “Why did we choose this?” informs makes rationale a first-class link: from a decision, back to the hypothesis, metric or risk that drove it, and from there to the memories that recorded it.
• “What breaks if this integration goes away?” depends_on and integrates_with traversed a couple of hops out give the blast radius. No search phrasing produces that list, because it is not written down anywhere as a list.
• “What is the shape of what we know?” Counting entities per type, or looking at which entities are the hubs, describes a body of knowledge that has grown too large to read through.

The rule of thumb: use search when you want to read what was said, and the graph when you want to see how the pieces fit. They draw on the same memories.

Next steps

• How memory maintains itself: the background work that connects memories and fills the graph.
• Add, search and correct memories: read what was said, and fix what is wrong.
• What a memory is: scopes, source authority, and where memories come from.
• Look up a Brain tool: the tools your agents call to search entities and follow relations.
• What Brain meters and which limits apply: what the processing behind the graph consumes.