Memory Lifecycle
The core memory operations stay stable across local, hosted sync, and BYODB modes. Locally, Coppermind now separates immutable episodes from promoted truth records and groups truth into canonical clusters.
Coppermind keeps the same core memory operations across every storage mode:
- ingest
- search
- inspect
- stats
- delete
That consistency matters more than the underlying backend.
The five core operations
Ingest
Ingest always records an episode first.
Typical cloud route shape:
{
"userId": "default",
"data": [
{
"content": "Ship 0.7.3 after doctor/install fixes.",
"tags": ["release", "ops"]
}
]
}
Locally, Coppermind now makes a second decision after episode append:
- keep the episode as audit-only
- promote it into the truth layer
- link it into an existing canonical cluster
- hold it as pending review
That is the key quality boundary: raw capture is preserved, but retrieval is built from promoted truth rather than every raw episode.
Search
Search retrieves the most relevant current-truth fragments for a question, task, or prompt.
Use it when you know what you are looking for.
Inspect
Inspect gives a broader view of stored memory for a scope. Use it when you want the current record set, not just the best semantic matches.
Internally, Coppermind now keeps canonical clusters so a topic can hold:
- one active truth row
- superseded historical rows
- supporting source episodes
That makes "what is true now?", "what was true before?", and "what changed?" first-class local questions.
Stats
Stats is intentionally lightweight. It answers:
- how many records exist
- roughly how many tokens are stored
- how old the stored data is
Delete
Delete removes records by episode or record identifier. It should be treated as destructive unless the route explicitly documents tombstoning or archive semantics.
How the same operations map across modes
The product contract is that backend choice does not redesign the memory API.
What the retrieval path is trying to do
At a high level, retrieval tries to:
- scope the request correctly
- find candidate records
- rank them
- trim them to a useful result set
That can happen against local storage, hosted sync, or BYODB, but the goal is the same: useful memory, not raw record dumping.
Optional local AI assist
If local AI assist is enabled, it helps improve memory quality. It does not become the authority for whether memory exists or what the current truth is.
Think of it as a helper for:
- triage
- compression
- background contradiction review
not as a replacement for the actual memory store.
Common failure classes
Runtime failure
The local Coppermind runtime is unhealthy or unreachable.
Typical next step:
coppermind doctor
Registration failure
The client never loaded the integration correctly.
Typical symptom:
- the expected memory tools never appear
- the plugin or patch never activates
Cloud auth failure
The request reached a cloud path, but the account, token, or plan state is wrong.
Storage failure
The runtime is up, but the active memory backend is not ready.
Typical symptoms include backend-unavailable or backend-not-configured errors.
What a healthy path looks like
- ingest stores data in the expected scope
- search retrieves relevant matches
- inspect returns the expected record set
- stats reflects what is actually stored
- delete behaves clearly and does not silently succeed