Context LatticeBy Private Memory Corp
System blueprint

Layered architecture for long-horizon memory, retrieval, and learning.

Context view shows boundaries. Container view shows responsibilities and protocol flow. Runtime view shows execution order.

Back to overview Install guide
Context Lattice architecture overview poster for web viewing
Architecture Poster (Web): high-level map of ingress, control, memory, evolution, event stream, and egress lanes.
Quick Path

How to read this architecture set

  1. Start with System Context (C4 Level 1) to understand boundaries and external dependencies.
  2. Use Service Map to see the single ingress orchestrator and subsystem relationships.
  3. Review Write + Retrieval Flows for runtime movement of data and learning feedback.
  4. Finish with Task Coordination + Ops for agent orchestration, messaging surfaces, and reliability controls.
C4 Level 1

System Context View

System Context Diagram: Context Lattice Context Lattice System Boundary [A] External Actors Apps + agents MCP tools Messaging hooks [B] Orchestrator Control Plane HTTP-first APIs + auth + policy [C] Memory Plane stores + retrieval [D] Ops + Safety queue + retention + security [E] Task Coordination + Agent Communication [F] Dependencies Model runtimes Tool providers Optional BYO cloud Legend Request flow

Context view keeps boundary and interaction semantics clear before implementation detail.

Legend + Roles

What each context block means

  • [A] External Actors: clients submitting memory writes and search requests.
  • [B] Orchestrator: single control plane for ingress, auth, validation, and routing.
  • [C] Memory Plane: durable stores used for fanout and retrieval synthesis.
  • [D] Ops + Safety: reliability controls for queue, storage, and policy.
  • [E] Task Coordination + Agent Communication: orchestrator-managed task routing for internal/external agents plus messaging ingress/egress.
  • [F] Dependencies: pluggable model/tool providers and optional cloud BYO services.
C4 Level 2

Service and Flow Views

Service map showing orchestrator, memory plane, and external dependencies
Service Map: the single control plane and every core system it coordinates.
Write flow showing ingest, validation, persistence, outbox, and async fanout
Write Flow: reliable writes under burst load via durable outbox and worker fanout.
Retrieval flow showing parallel recall, rerank, response, and learning loop
Retrieval + Learning Loop: faster context recall that improves quality over time.
Task coordination workflow showing orchestrator planning, agent worker fanout, and messaging communication surfaces
Task Coordination + Communication: orchestrator-managed task routing, agent execution, and bidirectional human messaging.
Container Notes

How to read these diagrams quickly

  • Panel 1 (Service Map): where each subsystem lives and who depends on it.
  • Panel 2 (Write Flow): how writes move from ingress to durable fanout sinks.
  • Panel 3 (Retrieval Flow): how recall/rerank returns context and captures learning signals.
  • Panel 4 (Task Coordination): how the orchestrator plans tasks, fans out workers, and communicates through messaging channels.
  • HTTP-first ingress: orchestrator remains the single write/search entrypoint.
  • Messaging surfaces: can operate bidirectionally (human ingress + response egress).
  • Local-first default: local stores first, cloud BYO remains optional.
Runtime Ownership

Which language runs what, and why

Python: compact hooks and development utilities

  • Runs: bounded hook glue and optional repo-local development scripts, not an application service.
  • Why: keeps portable lifecycle hooks and one-shot tooling lightweight without owning live routes.
  • Boundary: no Python process or fallback ingress is launched by the active public runtime.

Rust: memory and retrieval hot path

  • Runs: codec, memory engine, retrieval engine, and staged retrieval proxy paths.
  • Why: lower-latency execution, predictable memory behavior, and safer high-throughput concurrency.
  • Efficacy impact: smaller p95/p99 tails and better retrieval throughput under sustained load.

Go: ingress and orchestration services

  • Runs: primary external ingress on :8075, staged retrieval policy, scheduler/gateway services, batching, retries, and backpressure control.
  • Why: efficient long-running service concurrency and operational simplicity for scheduling workloads.
  • Efficacy impact: lower user-visible latency with more predictable tail behavior.
Current Runtime Default

Rust+Go own the active application runtime

  • Default posture: Rust+Go runtime path is enabled for performance-critical execution.
  • Ownership posture: strict native-route audits reject accidental Python hot-path ownership.
  • Verification endpoint: query GET /migration/runtime to confirm active runtime mode.
  • Efficacy focus: optimize for correct outcomes per request, not raw benchmark numbers alone.
Release Boundaries

Public operator modes

Lite default

  • Primary interface: CLI workflows for agents and operators
  • Ingress: gateway-go on :8075
  • Runtime boundary: no Python service is launched; hook glue remains outside the application path
  • Fast memory: topic rollups, Qdrant, graph neighbors, and bounded context packs
  • Slow-source handling: async continuation by default for tail-latency control
  • Objective: stable local memory with clear operational behavior

Optional adapter lab

  • Mode: gmake mem-up-lite-advanced
  • Purpose: public, opt-in adapter testing without changing quickstart defaults
  • Boundary: not a paid/private lane and not automatic promotion
  • Proof: use runner-quality, recall quality, and live operator checks before adopting a lane
  • Objective: make experimentation observable without surprising normal users

Runtime lane flow

flowchart TD A["Caller"] --> B["gateway-go :8075"] B --> C["Rust retrieval + staged policy"] C --> D["Fast default: topic_rollups, qdrant"] C --> E["Slow async: mindsdb, mongo_raw, letta, memory_bank"] E --> F["Continuation events + cache warm"] B --> G["Strict native ownership audit"] B --> H["Optional adapter lab"] H --> I["Bounded telemetry + operator review"] I --> J["Promote only with hard gate evidence"]
Dynamic View: Write Flow

Write Flow

Order of operations

  1. Authenticate and normalize write payload.
  2. Persist raw event for replay durability.
  3. Append async outbox fanout jobs.
  4. Dispatch sink writes with retries/backpressure.
  5. Record queue and sink telemetry.
Dynamic View: Retrieval Flow

Retrieval Flow

Order of operations

  1. Receive scoped query (project/topic aware).
  2. Run parallel retrieval across sinks.
  3. Merge and rank candidates for retrieval egress.
  4. Prompt for context-quality feedback when useful.
  5. Write feedback signals to improve future ranking.
Dynamic View: Agent Coordination

Session Package Flow

Order of operations

  1. Bootstrap a typed agent session for the active profile and project.
  2. Attach checkpoints, handoffs, source coverage, and risk signals during work.
  3. Compute a rollup with objective state, confidence, and missing evidence.
  4. Emit a bounded context package before the next hard model call.
  5. Preserve contract metadata so CLI, HTTP, MCP, and dashboard surfaces agree.
Ops + Safety

Controls that keep long-horizon operation stable

  • Queue durability: retries, deadletters, and replay workflows.
  • Write pressure management: backpressure + coalescing under burst load.
  • Storage hygiene: retention sweeps and external cold-path handoff.
  • Security posture: strict API-key auth and secrets redaction/block controls.
  • Operational confidence: health probes, telemetry, and update automation.