Memory Types

The daemon stores canonical memory_type values as lowercase strings. Claude Code skills pick one of these values in local memory mode; model-equipped daemon paths can classify on the daemon side.

Use the type that best explains why the memory should matter later, not merely the first label that seems plausible.

Use decision for a concrete choice with rationale. Use preference for a recurring user habit or style. Use lesson when the work produced a reusable insight.

Use gotcha for traps and warnings. Use fact for durable knowledge about people, projects, tools, or the work itself. Use identity only for durable facts about the user.

A correction is a kind of capture intent, not a canonical memory_type. When a fact changes, capture the corrected statement and include what it supersedes.

Origin can then surface revision or supersession behavior while keeping future recall pointed at the current fact.

Origin treats identity and preference as protected because they describe the user. Standard work memories can still be important, but they are easier to supersede when new work changes the current record.

Missing or invalid types are treated as ephemeral at the stability boundary. Good captures should avoid leaving the type ambiguous when the agent can classify confidently.

Some high-level or legacy labels can still appear at API boundaries. They exist for compatibility or classification flows, not as the six user-facing values agents should prefer.

For new captures, choose one of the canonical values unless the daemon or skill explicitly handles the alias.

memory/store accepts memory_type as an optional field. If you provide it, use the canonical lowercase value.

If you are building a Rust local tool, prefer origin-types so invalid values fail visibly instead of drifting through untyped JSON.