Most memory systems store facts: retries needed an idempotency key, the schema changed, the deploy failed. What they don't store is the relationship between facts — whether one caused another, blocked it, followed from it, or flatly contradicts something already on record. Echo Memory does, and it does it without pretending to know more than it actually does.
Four relation types, set by the agent that wrote them
Every edge in the graph carries a relation_type: caused_by, led_to, blocked_by, or contradicts. The type is set by the calling agent's own read of the conversation — not inferred statistically from embeddings after the fact. That is a deliberate, and fairly unusual, honesty constraint. It would be easy to ship a model that guesses causal relationships from text similarity and call it causal typing. It would also be wrong more often than an agent that was actually in the conversation and decided caused_by was the right call.
A concrete shape
The interactive graph on the homepage is illustrative, not a live customer graph, but the shape is representative of what shows up in practice: a service node like checkout-api connects to retries via caused_by (a retry storm without backoff caused a spike), retries connects to idempotency keys via led_to (the storm led to adopting them), and a second, unrelated project — mobile-app — later connects to that same idempotency keys node through its own offline queue work. Nobody wrote "these two projects are related." Entity resolution matched the node by name, and the relationship exists as a structural consequence of two independent sessions mentioning the same concept.
A contradicts edge does something more specific: it marks a fact as superseded without deleting it. If a consumer's assumption about an event schema turns out to be wrong, the old assumption doesn't vanish — it stops being drawn as current, but stays reachable from its node with full history. That distinction, between "wrong" and "gone," is the whole point of typing the edge instead of just overwriting the fact.
Every edge explains itself
Typing the relationship is half of it. The other half is that every edge in the graph carries a full audit trail: what was said, when it became valid and when (if ever) it was superseded, which agent wrote it in which session, which project it came from, and — for entity resolution specifically — why the node at either end resolved the way it did. Running echo-memory why <fact_id> prints that same trail in a terminal. Memory that consolidates and edits itself is only trustworthy if you can see why it made the call it made; the audit log is what makes that check possible instead of theoretical.
What causal typing is for, and what it isn't yet
Today, in v1a, causal-typed edges are recorded and auditable — the data model is real and the trail is real. What they don't yet do is drive retrieval. Personalized PageRank over the typed graph, the mechanism that would let a query like "what led to the outage" walk caused_by and led_to edges specifically rather than search by similarity, is v1b, gated behind v1a first proving that basic recall earns its keep. Causal typing exists so that work has somewhere real to attach to when it ships, not as a feature that already changes what you get back from a query.
The honest version of "causal memory" is a system that tells you exactly which part is the agent's judgment, which part is structural fact, and which part hasn't been built yet. Echo Memory tries to be that system rather than the one that claims more than the graph currently does.
Try the click-through version of this on the homepage's patch bay — click a jack to see what it connects to, click a cable to see its full provenance, the same trail echo-memory why prints in a terminal.