Knowledge Graph

Alongside the vector store, Cortex maintains a knowledge graph (FalkorDB) of the entities and relationships mentioned across your memories. It powers relationship-aware reasoning — who owns what, what superseded what, and when.

How the graph is built

Every time a memory is written, an LLM extracts up to a few (subject, relation, object) triples from its content — for example (Team → decided → migrate_to_Postgres) or (Alex → owns → billing_rewrite). Entities become nodes (MERGEd per org + name) and relations become edges, each carrying the memory's scope, clearance, and time interval, so the graph respects the same policy gate as recall.

Entity types the extractor recognises: Person, Team, Project, Product, Metric, Policy, Event, Artifact, Other.

Viewing it

Memories → Knowledge Graph renders two views:

• Memory relationships — the derived entity graph, with one colour per entity type so it reads as clusters of people / teams / projects / metrics. Use the legend to highlight a single type.
• Organization hierarchy — your team's reporting tree, built from each user's reportsTo (this view is not derived from FalkorDB). Nodes are coloured by role (CEO / Manager / IC / Contractor).

Rebuilding

Graph extraction is best-effort — if FalkorDB is unreachable (e.g. a free-tier instance that has hibernated), the memory still saves and recalls normally; only the graph edges are skipped. Once the graph is back, a CEO can repopulate it:

POST /api/graph/rebuild      # re-extracts triples for all active memories

or use the Rebuild graph button on the Knowledge Graph page.