Core Concepts

Memory Types

MemorySync does not have a single "type" field. It has four overlapping classifications, each populated at a different stage of the pipeline. This page lists every one, every value it can take, and when each one is set.

Why there are multiple type fields

The same row can be described in four ways: what kind of statement it is (a preference vs a fact), what category the statement is about (food, occupation), what document it came from (a meeting note vs a blog), and what extraction shape the pipeline used. Each axis answers a different question, so each one has its own column.

Axis 1 — <code>extracted_type</code>

Set by the LLM-driven extraction pipeline. Columns: extracted_type on the memory row.

Value	Means
`preference`	A persistent like/dislike or stylistic choice.
`fact`	A verifiable, time-stable statement.
`intent`	A goal or planned action.
`relationship`	A link between entities.

Direct writes via POST /memory/add leave this column null unless the extraction path was triggered.

Axis 2 — <code>memory_type</code> in responses

Surfaced on read models when the platform classifies the row at recall time.

Value	Typical content
`fact`	Time-stable statement.
`event`	Something that happened at a specific time.
`decision`	An outcome chosen between alternatives.
`insight`	A derived observation from other memories.
`narrative`	A summarised story or sequence.
`analysis`	Quantitative or evaluative content.
`reference`	Pointer to external material.

Axis 3 — extraction candidate categories

Before promotion to a memory, raw extraction produces a MemoryCandidate. That candidate carries one of these categories:

FACT
EVENT
STATUS
RELATIONSHIP
POLICY
DECISION
ENTITY
SUMMARY

Only candidates that pass validation are promoted into the memories table.

Axis 4 — <code>content_type</code>

Describes the document the memory came from, not the statement type. Examples include report, pitch_deck, blog, technical, meeting. Used to compute freshness rules: a meeting note ages faster than a reference doc.

<code>extracted_key</code> — the category slug

A single short slug naming what the memory is about. Examples observed in the codebase include food, occupation, and other domain slugs produced by the extraction model. extracted_key is independent of extracted_type: a row can be extracted_type=preference and extracted_key=food.

How the axes combine on a real row

JSON

{
  "id": 1804,
  "text": "User prefers spicy food and avoids dairy.",
  "extracted_type": "preference",
  "extracted_key": "food",
  "memory_type": "fact",
  "content_type": "meeting",
  "tags": [
    "food",
    "preference",
    "diet"
  ]
}

Choosing types when you write directly

If you control the input, set tags and source — the platform will fill in the other axes.
Do not set extracted_type or extracted_key from the client; they are server-managed.
memory_type is read-only on responses; it is not accepted on writes.

← Previous

Memory Record Structure

Memory Lifecycle