Read the source code of your memory.
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:
- Extracts entities: Flask (technology), FastAPI (technology)
- Extracts relationship: FastAPI
REPLACESFlask - Creates or updates entity nodes (fuzzy-matched against existing entities)
- Creates a weighted edge (incremented on re-observation)
- 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.