Documentation

Read the source code of your memory.

Docs / core-concepts / knowledge-graph

Knowledge graph

Auto-extracted entities, typed relationships, and graph-powered retrieval.

The knowledge graph is the third signal in Orion's retrieval pipeline. Every brain.think call extracts entities and relationships from natural language, links them into a typed graph, and makes them available for traversal during search.

How the graph builds itself

When you write "We switched from Flask to FastAPI for better async support", Orion:

  1. Extracts entities: Flask (technology), FastAPI (technology)
  2. Extracts relationship: FastAPI REPLACES Flask
  3. Creates or updates entity nodes (fuzzy-matched against existing entities)
  4. Creates a weighted edge (incremented on re-observation)
  5. Creates backlinks from the stardust record to each entity

No manual tagging. No configuration. The graph emerges from use.

Entity extraction

Entities are extracted using zero-LLM regex patterns (~40 patterns covering code symbols, technology names, CamelCase identifiers, URLs, file paths, and natural language patterns). Coverage: ~60% of entities in typical engineering knowledge.

An optional LLM pass (Ollama by default) pushes coverage to ~90% at a cost of ~130ms per call. The LLM pass is skippable — the graph works without it.

Entities are tiered by importance:

Tier Threshold Retrieval weight
1 — Mentioned Default Normal
2 — Referenced 5+ mentions Boosted
3 — Core 15+ mentions Highest

Relationship types

Type Extracted from Example
USES "X uses Y", "X with Y" FastAPI USES Pydantic
REPLACES "switched from X to Y" FastAPI REPLACES Flask
DEPENDS_ON "X depends on Y", "X requires Y" Auth DEPENDS_ON Redis
WORKS_WITH "X works with Y", "X alongside Y" Redis WORKS_WITH PostgreSQL
PART_OF "X is part of Y", "X within Y" Alembic PART_OF database layer
INFORMS "X informs Y" User research INFORMS product decisions
EVALUATES "X evaluates Y" Load testing EVALUATES API performance

Edges carry confidence scores and strength counters. Strength increments each time the relationship is re-observed in new stardust.

Graph operations

Neighborhood — explore entities within N hops:

orion graph query PostgreSQL -d 2

Path finding — BFS shortest path between two concepts (max 6 hops, cached 1 hour):

orion graph path FastAPI Redis

Hub detection — entities ranked by degree centrality:

orion graph hubs -n 10

Unlinked mentions — stardust that mentions an entity by name but has no formal backlink (Obsidian-style detection):

orion graph unlinked

Transitive inference — the weekly audit infers indirect relationships:

A USES B + B DEPENDS_ON C → A INDIRECTLY_DEPENDS_ON C

Inferred edges are marked inferred=True with lower confidence. Useful for discovery, but don't pollute the primary graph.

Contradiction detection

When brain.think stores knowledge that conflicts with existing records, Orion flags a contradiction. The weekly audit also scans for conflicts in batch.

Type Meaning Resolution
FACTUAL Direct conflict ("We use JWT" vs "We use session tokens") Supersede: one wins, the other gets valid_until set
CONTEXTUAL Both true in different contexts ("REST for public, gRPC for internal") Coexist: both preserved, tagged with context
TEMPORAL Was true, no longer is ("We use Flask" → "We use FastAPI") Supersede: newer wins, SUPERSEDED_BY edge created

Superseded records are never deleted. They remain in the graph with valid_until set, preserving the full decision history.