Document Architecture — retrieval plane
Version v0.4 · 2026
Audience Technical evaluators
Sections §01 — §07
§00 · Architecture How it works

Two planes. One substrate.

The mesh is the data plane — sources, retention, materialization, what gets pulled in and how thick the strand. The engine is the retrieval plane — typed knowledge graph, memory network, deterministic router, what gets returned and how fast. This page is about the second; the first lives at /connectors.

§01 Two substrates p. 01

§01The two retrieval substrates.

A typed graph (entities + edges + provenance + confidence + temporal validity) for “who/what/when” questions. An associative memory network (Zettelkasten / A-MEM) for “trace how my thinking evolved” / “what was I working on when I last met X” questions. Both live behind a deterministic router that picks the right one (or both) per query.

§02 Materialization tiers p. 02

§02Materialization tiers.

Four tiers, applied per-rule, per-account, per-source. The mesh resolver hydrates Tier 1 / 2 / 3 on demand from source — unless you've told it not to.

# Tier 0 — full body
artifact.body          = "the literal document, stored on your disk"
artifact.body_purged   = false

# Tier 1 — hollow (TL;DR + entity graph)
artifact.tldr          = "model-generated summary"
artifact.body_purged   = true   # body removed after harvest

# Tier 2 — metadata only
artifact.metadata      = "sender, subject, timestamp, source URL"
artifact.body          = null   # body never landed

# Tier 3 — dark
artifact.tombstone     = true   # reference only; no body, no metadata

# Mesh URI used by the resolver to re-hydrate on demand
mesh://gmail/account=nick/msg-id=<hash>     # T1/T2/T3 hydration target
§03 Provenance p. 03

§03Provenance — three columns.

source_kind (extracted / inferred / ambiguous), confidence (0..1), provenance (a JSONB bag of evidence). Every edge carries them. Retrieval can filter by min_confidence. The default formatter annotates non-extracted edges with [inferred 0.62]-style suffixes.

§04 Retention p. 04

§04Retention semantics.

Three layers — workspace default, per-account cap, per-rule cap — tightest wins. Stamped at ingest as an immutable decision snapshot. Cascade-purges through derived rows (LLM TL;DRs, visual assessments, emitter rollups) via derived_from_artifact_id. By default, post-purge the engine will not re-fetch from upstream.

§05 HITL curation p. 05

§05HITL curation queue + agent-in-loop.

The Review surface. Five suggestion kinds — bridge_edge, alias_merge, role_enrich, memory_candidate, edge_inference. Workspace flags hitl_curation_enabled and curation_agent_enabled control rollout; curation_agent_auto_accept_threshold (default 0.85) gates auto-accept of high-confidence corroborated verdicts.

Default · §05
Nothing speculative escapes review by default. Accept (canonical), reject (soft-deleted), or silence (don't ask about this pair again).
§06 Speed p. 06

§06Speed is the first architectural choice.

A deterministic router across six substrates: a typed knowledge graph for relationships, a semantic index for meaning, a metadata index for time and source, an entity resolver for names, a hypothesis verifier for claims, and an associative memory network for sense-making. Postgres, pgvector, GIN indexes, and a graph traversal each do their job in single-digit milliseconds. The LLM is summoned explicitly when you want reasoning — not snuck into the hot path.

§07 Two substrates, not one p. 07

§07Why two substrates, not one.

Types preserve structured-fact discipline — temporal validity, supersession, audit. The memory network preserves associative sense-making — HippoRAG-style PageRank walks. They aren't alternatives; they're complementary lenses. Most queries hit one; interesting queries hit both, and the router decides.

The data plane is yours. The retrieval plane runs over it.

Request early access →
Substrate Postgres + pgvector Memory A-MEM / HippoRAG-style v0.4