Skip to content

Epistemic Graph

epistemic-graph is the unified, Rust-native "master-of-all" data & compute engine for the agent-utilities ecosystem. It collapses a graph database, vector index, SQL warehouse, triple-store + OWL reasoner, time-series DB, content-addressed blob store, and full-text index into one durable engine with one cross-modal RowSet planner, exposed to Python out-of-process over length-prefixed MessagePack on UDS/TCP (HMAC-authenticated, no PyO3) or embedded in-process on the edge.

It is durable by default (redb-authoritative — an acked write survives kill -9) and scales by configuration alone, from a Raspberry Pi single binary to a multi-node Raft cluster with cross-shard transactions.

North Star: Seamless — every cross-modal seam (a write→read path that crosses OWL/vector/graph/timeseries/relational) is implemented at every surface — RPC, all SQL wires, SPARQL, GraphQL — never merely flagged. Each surface is a thin parser/router onto the same committed seam. See the seam backlog for what is done vs. open.

flowchart LR
    EDGE["Pi / edge<br/>embedded or pi-tier binary"]
    NODE["single durable server<br/>node / full tier"]
    CLUSTER["HA cluster<br/>Raft + pgwire + cross-shard 2PC"]
    EDGE --> NODE --> CLUSTER

It also fronts many wire protocols and cross-cutting subsystems on that one substrate — a message broker, an observability stack, GIS, tensors, streams, and an LLM KV-cache — so the same durable store answers a Postgres, Neo4j, Redis, S3, AMQP, or PromQL client:

flowchart TB
    subgraph Wires["Wire adapters (one WireProtocol exec path)"]
        W["native · pgwire · sqlite · mysql · mssql · bolt · redis · s3 · amqp · mqtt · stomp · obs"]
    end
    subgraph Subsys["Cross-cutting subsystems"]
        BR["broker"]
        OB["observability"]
        MM["agent-memory"]
        KV["KV-cache"]
    end
    subgraph Modalities["Modality engines"]
        MOD["graph · vector · SQL · RDF/OWL · SHACL/ShEx · TSDB · text · GIS · tensor · stream · BLOB"]
    end
    CORE["one durable substrate<br/>GraphCore + redb-authoritative + unified RowSet planner"]

    Wires --> CORE
    Subsys --> CORE
    CORE --> Modalities

See the subsystems reference for how each composes on the substrate.

Honesty first. Every capability is tracked operation-by-operation in the capabilities & parity matrix with a status tag (✅ supported · 🔶 in-progress · 🗺 roadmap), and the parity roadmap names exactly which drop-in gaps are being closed. If a doc and the code disagree, the code wins.

Start here

Operate & deploy

  • One build, opt-in layers — the feature-composition map: the one main full-featured build plus the cluster (HA raft) and full-extras (GPU/ROS2) opt-in build layers.
  • Engine modes — the remote → shared-local → autostart resolver, the auto-bundled tiny engine, and the embedded in-process path.
  • Deployment (database) — Docker, prebuilt wheels, single-node, and HA-cluster recipes for every scale.
  • Service Mode — the wire protocol, authentication, multi-graph management, isolation policy, and Prometheus metrics.
  • Cost model & capacity — the per-tenant memory budget, autoscale signals, and Pi→cluster footprint planning.

Reference

Design principle: design for a network boundary

Every out-of-process invocation crosses a process boundary — serialize, socket round-trip, deserialize. A call is not a cheap function call. Batch, never per-element: ship work into a single round-trip over data already resident in the graph (one all-pairs op, not a Python loop), and keep tight per-element math in-process. The Rust Compute Guide explains how this shapes every caller.