Relationship memory
Package: @magpie/relationship-memory.
In plain language
A Solution that works with the same person or organisation over time should remember what it has learned — preferences, commitments, recurring priorities — and be able to say why it knows each thing. Relationship memory is a governed record system for exactly that: every memory item has a source, a basis (stated by the person, or inferred), a lifecycle, and can be erased. It is a record system, never a hidden intelligence.
The mechanism
Five categories of context, one authoritative home each (ADR-0038). Knowledge (what the organisation declares true — governed corpus); Memory (what this relationship has learned — lifecycle records); State (what the application is working on now — workflow state); Transcript (what happened — immutable history); Artifacts (what was produced). A fact may appear in several categories but has one authoritative home at any point. Memory is a projection of state history, never a replacement for state; fresher Knowledge outranks Memory, with the conflict disclosed.
Memory items and proposals. A MemoryItem carries a basis of
"stated" | "inferred", a status of "current" | "superseded" | "tombstone", and a provenance chain. Applications submit
MemoryProposals; applyMemoryProposals is the platform lifecycle engine
that accepts, supersedes or rejects them under fixed limits — an inference
never overwrites a statement. selectCurrentForRecall returns what a
Solution may recall; tombstone erases with a record. MemoryStore is the
port; the DynamoDB adapter lives in /server.
Invariants. Memory is a governed record system, not an intelligence system (INV-MEMB-001); it never becomes the working context store (INV-MEMB-002); retention and erasure are contractual behaviour (INV-MEMB-003).
Exposed through our API. Clients list current memory (or history including superseded items), submit proposals, and erase all memory for a relationship — tombstones plus a ledgered disclosure. See Our API.
Design notes
- Why this is platform, not application (ADR-0038). The semantics of durable memory — authority, supersession, provenance, isolation, erasure, audit — are trust semantics, not features. The forcing function was the second external consumer's readiness review: "make it excellent, and leave the platform materially stronger because we built it."
- Why Knowledge and Memory never merge (I-22, ADR-0030). Memory is "a governed projection of truth, never a second truth store": rebuildable from stores already trusted, inspectable by an operator, disclosed to the model, erasable on offboarding.
Sources
matterandgas-com/docs/adr/0038-context-taxonomy-and-relationship-memory.md.matterandgas-com/docs/adr/0030-conversational-memory-strategy.md.magpie/packages/relationship-memory/src/types.ts,lifecycle.ts,port.ts.