# Organizing memory

> Projects, tags, pages, and links — what each is for.

Four organizers keep memory navigable. They overlap in feel but not in job —
keeping them distinct is what stops memory from turning to mush.

| Organizer | What it is | Per memory |
|---|---|---|
| `project_id` | the one **home scope** — what an entry is about | one |
| **tags** | many cross-cutting **labels** for recall | many |
| **page** | the durable **synthesis** on a subject | — |
| **link** | an explicit typed **relationship** between two rows | — |

## Projects — the folder

A project is a topical scope inside one workspace (Health, the Acme launch). An
entry has one home project; a page can belong to several via `page_projects`. A
project's **`description` is a routing index** — it lets an agent choose which
project to open before spending tokens reading it, so keep it accurate.

```sql
insert into projects (workspace_id, name, description)
values (my_personal_workspace(), 'Health', 'Symptoms, labs, providers, meds.')
returning id;
```

Create one only when a coherent theme has formed and the user agrees. Retire one
by setting `status = 'archived'`; its entries simply fall back to unfiled.

## Tags — the labels

Tags are the emergent, cross-cutting vocabulary. Apply them with `apply_tags`;
fold duplicates with `merge_tags`, which repoints the labels and archives the
loser (no row is ever deleted). The same tag can span many projects — which is
exactly what `project_id` alone can't give you.

## Pages and links — the Dreamer's work

**Pages** are the consolidated wiki; **links** are the typed graph between them.
Your agent reads both but writes neither — consolidating entries into pages and
drawing links is the [Dreamer's](/docs/dreamer) job. At capture time you
insert entries only.

When you read, start at the pages (they're already synthesized and cited), then
follow `derived_from` links down to the source entries for provenance, and
`relates` or `part_of` links across to neighboring topics.