mem-local — the graph shape

how-it-works-diagram shows the pipeline a fact travels through. This page shows the other half: what the graph itself actually looks like once a fact is in it — nodes, edges, and the fields each one carries.

What every node carries

Field	What it holds
`entity_id`	Minted at approval, not at proposal — e.g. `e47`, or `proj:ai-memory-system` for a project’s own node.
`entity_type`	Free (“kind”) axis — `project`, `decision`, `next_action`, `open_question`, `preference`, `decision-cluster`, and more. Paired with a mandatory `domain` unless it’s a project/area node.
`name`	A short label. Must be supplied — falls back to copying `content` if omitted, which reads badly, so it’s never actually skipped.
`content`	The assertion itself — the operative extract, not a copy of the source conversation.
`scope`	`project` \| `portfolio` \| `local_only`. `project` scope requires a real edge to a project node — no floating project-scoped orphans.
`domain`	Gated — nine fixed values. Required whenever `entity_type` isn’t `project`/`area`.
`provenance`	`chat:<project>-<date>` — where this came from.
`rationale`	Why this was proposed, grounded in what was actually said (never confabulated).
`valid_from` / `system_from`	The two independent bi-temporal clocks — see [[mem-local/theme-bitemporal-supersession
`confidence`	Exists in the schema, never written. Dead by design (AP-3) — see [[mem-local/theme-human-approval-write-gate

Edges are lighter — edge_id, source_id, target_id, relation_type — and just as append-only as nodes: a correction is supersede_edge_id (same edge_id, new content) or retract_edge_id (tombstone), never an in-place edit.

A real corner of the graph

Not a made-up example — this is the actual neighbourhood one hop out from the project node, pulled live from the store:

flowchart LR
    P["proj:ai-memory-system"]
    P -->|decision| E3["e3 · Approval-gated<br/>write path"]
    P -->|decision| E4["e4 · Per-chat<br/>separation"]
    P -->|decision| E5["e5 · Density<br/>over volume"]
    P -->|decision| E14["e14 · Write-path<br/>reachability"]
    P -->|next action| E2["e2 · Validate<br/>SKILL.md"]
    P -->|open question| E29["e29 · Does SKILL.md<br/>work elsewhere?"]
    E2 -.->|resolves| E29

A few things this makes concrete that are easy to miss when the graph is only described in prose:

A project node is just a node. proj:ai-memory-system has no special schema privilege — it’s an entity_type: project node like any other, and what makes something “belong” to it is a real edge, not membership in a table.
Decisions, next actions, and open questions are siblings, not a hierarchy. All three hang directly off the project by a typed edge; a next_action and the open_question it exists to close are cross-linked to each other too (e2 → e29), which a flat, similarity-ranked store has no way to represent at all.
Density over volume, visibly. Roughly 40 settled register decisions compress down to a dozen nodes like e3–e14 — each one a density-weighted cluster, not a decision-per-row transcript.

Sources: live mem-local store — traverse(proj:ai-memory-system, depth=1), queried 1 Sep 2026; theme-graph-not-vector-dump; 05-conventions-and-discipline (scope-binding rule).