Understand the knowledge graph

The knowledge graph connects the things your memories describe. Brain extracts entities, such as features and decisions, and relations, such as a feature depending on an integration. Use memory search to read what was said; use the graph to trace how those things connect.

The graph is read-only. You shape it by storing memories, not by manually adding nodes or links.

How the graph is built

Brain extracts entities and relations from recent facts in the background. It accepts only the 15 entity types and 20 relation types below. A relation is stored only when both endpoints already exist or are extracted in the same pass; unsupported types and missing endpoints are discarded.

Mentions of the same thing are combined into one entity, with alternate names kept as aliases. Each fact contributes once. Later memories can add aliases, evidence, and relations to existing entities. An entity’s evidence count is the number of memories it was extracted from.

Extraction follows the write, so a new memory can appear in search before the graph. Text that states no product entities may add nothing to the graph. You see the product’s shared knowledge plus your own agent’s private knowledge, according to the memory visibility rules; the web app shows shared knowledge.

Explore and check the evidence

In the web app, open Brain’s Knowledge page. The list view has Entities and Relations tabs. In the graph view, node size indicates connectedness, colors group related types, and the legend lets you filter types. Select a node to inspect its relations and supporting memories, then follow a relation to its other endpoint.

Large graphs are shown in part, retaining the most connected entities. A missing node in that picture does not prove the entity is absent from memory.

Agents can use these MCP tools with product-scoped read access. The same operations are available over the Brain REST API.

Question	Tool and boundary
Which entities match a name, alias, or type?	`brain_knowledge_search`; page with `offset`, and `limit` up to 100. Results include type, name, aliases, description, and evidence count.
What connects to this entity?	`brain_knowledge_neighborhood`; give `entity_ref`, expand 1–3 hops, and optionally filter relation or entity type. At most 200 neighbors per request.
Which relations have this type or endpoint?	`brain_knowledge_relations`; filter `relation_type`, `source_entity`, or `target_entity`. At most 200 relations per request. Each relation names both endpoints and its recorded reason.
Which memories support this entity?	`brain_knowledge_entity_memories`; give an ID, name, or alias in `entity_ref`. Memories are newest first; default 50, maximum 200 per page.
What does the graph look like overall?	`brain_knowledge_graph`; up to 5,000 nodes, keeping the most connected when capped.

For example, start at an integration and follow depends_on to inspect the features that rely on it. Open the supporting memories before treating that structure as a complete account of the product. The graph reflects what Brain extracted from stored statements.

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

Type	What it is
`Product`	The product itself — exactly one per graph, used as the anchor for product-level competition or targeting
`Feature`	A capability or piece of functionality the product offers, including modules and components
`Requirement`	A constraint or property the product must satisfy — functional, non-functional, legal or technical
`Decision`	A deliberate choice already made about the product, the stack or the business, ideally with its rationale
`Goal`	A higher-level product or business objective — the outcome behind the features
`Hypothesis`	An open belief about the product or market that is still under test
`Risk`	A potential problem, threat or uncertainty that could harm the product or the business
`Milestone`	A dated or otherwise significant target marking progress
`Metric`	A measurable indicator tracked to gauge product or business health
`Technology`	A build-time technology or stack choice used to build the product
`Integration`	An external system, API or service the product connects to at runtime
`CustomerSegment`	A target group of users or buyers, a persona, or a market niche
`Competitor`	A rival product, company or alternative the customer might choose, including the status quo
`Channel`	A marketing or customer-acquisition channel
`PricingPlan`	A monetization model, plan or tier

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.

Relation	From → to	Meaning
`part_of`	Feature → Feature	A sub-feature belongs to a larger feature or module
`depends_on`	Feature → Feature, Integration	One thing needs another to function or to be built
`satisfies`	Feature → Requirement	A feature fulfills a requirement
`built_with`	Feature → Technology	A feature is implemented using this build-time technology
`integrates_with`	Feature → Integration	The product connects to an external service
`mitigates`	Feature, Decision, Requirement → Risk	Something addresses or reduces a risk
`blocks`	Risk, Requirement, Milestone → Feature, Milestone	Something impedes the progress or release of another item
`motivates`	Goal, Metric, Risk → Feature, Requirement	An abstract driver behind building something
`requested_by`	Feature, Requirement → CustomerSegment	Explicitly asked for by a customer group
`targets`	Feature, PricingPlan, Goal → CustomerSegment	Aimed at a particular customer group
`measures`	Metric → Feature, Goal, CustomerSegment, Milestone	A metric quantifies the success of something
`affects`	Decision, Feature, Integration, PricingPlan → Metric, Feature, Milestone	Broad influence or impact on another item
`informs`	Hypothesis, Metric, Risk → Decision	Evidence or input that drove a decision
`tests`	Feature, Metric → Hypothesis	Work that probes or validates a hypothesis
`validated_by`	Hypothesis → Metric, CustomerSegment	Evidence that supports or refutes a hypothesis
`chosen_over`	Decision, Technology → Decision, Technology	The source was picked, the target is the rejected alternative
`supersedes`	Decision, Feature, PricingPlan, Requirement → same	Replaces a prior version of the same kind of thing
`competes_with`	Product, Feature, PricingPlan, Competitor → same (undirected)	Market rivalry
`acquires`	Channel → CustomerSegment	A channel reaches or acquires this customer group
`promotes`	Channel → Feature, PricingPlan	A channel promotes this feature or plan

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.

Choose graph or memory search

You want to know	Where to look
What someone recorded about a decision	Memory search, then the full record.
Which features, plans, channels, and metrics connect to a customer segment	The segment’s neighborhood.
What informed a decision	Incoming `informs` relations, followed back to supporting memories.
Which parts depend on an integration	`depends_on` and `integrates_with` relations, expanded through relevant neighbors.
How knowledge is distributed across the product	Entity types and the most connected nodes.

A connection outside the fixed vocabulary can still be described in memory. Search the text when the graph has no relation that expresses it.

Was this page helpful?