A protocol for organising an AI assistant's long-term memory so it stays useful as it grows: an index of your work streams, a backlog of what's next, a dated log of what happened, a register of ideas already considered, and links from every entry back to the exact chat turn it came from.
If you find it useful, a ⭐ helps others discover it.
It was built on Claude's memory and Projects. Everything is plain Markdown, so the structure carries over to any assistant with file-based memory; Claude-specific parts are named as such in the spec.
Assistant memory tends to turn into a pile. Status is repeated in several places and drifts apart. You can't tell which decisions you made and which the assistant suggested. Ideas you rejected come back as new. Cleaning up risks deleting the one fact that wasn't recorded anywhere else.
The catalog is built on five principles:
- One fact, one home. Status lives only in the backlog, history only in the log. Detail that a repository already holds stays there, with a pointer to it. (SPEC §3 ,§11 )
- You adopt, the assistant proposes. Anything from the assistant's analysis is filed only after you confirm it. (SPEC §5 , the adoption gate)
- Provenance. Every entry carries a checkpoint such as
⟨a1b2c3d4 t13→t20⟩: proposed at turn 13 of that chat, accepted at turn 20. Verbatim anchor phrases let the link be verified or repaired if the chat is edited. (SPEC §6 ) - Nothing is lost silently. Ideas you declined, and ideas raised but never discussed, go into an "already considered" register so they don't come back as if new. (SPEC §5a )
- Proof before removal. A cleanup removes nothing that can't be proven to exist elsewhere, and you get a byte-verified backup first. (Safety rule S2,SPEC §13 and§16 )
The five safety rules (S1–S5) that protect your data are in SPEC §13. New to the vocabulary? See Terms, SPEC §0.
Requirements, checking the installation, updating and removal are in INSTALL.md. The short version:
The catalog. Open a new chat outside any Project, attach SPEC.md and send:
Set up the catalog system from this spec. Show me what you'll create before writing anything.
The assistant proposes the catalog files and how your existing memory is sorted into them, asks a few questions, and writes only after you approve. Check it worked with status digest.
A Project board (optional). Open a chat inside the Project and send:
set up the board
Until the nightly sync exists, a board shares status only between chats of that Project. To bring a Project's news into your main catalog, say "read the Project name board and update the catalog" in a main chat. (SPEC §7)
Say these in plain words; exact wording doesn't matter. Where: MAIN = a chat outside any Project · PROJECT = a chat inside a Project · ANY = either. This table is copied from SPEC §12, which is the source of truth.
| Say | Where | What happens | You get back |
|---|---|---|---|
| Set up the catalog system from this spec. Show me what you'll create before writing anything.(attach SPEC.md) | MAIN | Stores the spec as /catalog/protocol.md , proposes the catalog files and how your existing memory is sorted into them, asks questions |
A proposal, then the list of files created after you approve |
| Update the catalog protocol to this version. Show me what changes before writing.(attach the new SPEC.md) | MAIN | Compares with /catalog/protocol.md |
The differences, then the update after you approve |
| Delete the catalog files. | MAIN | Whole-file deletion on explicit request (rule S2); a backup is offered first | Confirmation of what was deleted |
| set up the board | PROJECT | Creates _board.md ,_feed.md ,_inbox.md ,_considered.md in that Project (section 7) |
The list of files created |
| export the catalog spec | MAIN | Generates this document from the protocol (rule S1) | The file |
| clean up* file* /slim* area file* | MAIN | The rule S2 procedure (section 16) | A backup file and a cut list; nothing removed until you approve |
| catalog this chat | ANY | Section 5 (inside a Project it writes only that Project's files) | Candidates and questions, then the three-part report |
| catalog my past chats /catalog chats about* topic* | ANY | Section 5, one chat at a time (for many chats, section 18); only reaches chats in the same scope | The same, per chat |
| what's next /backlog for* stream* | ANY | Reads the backlog | The matching task lines |
| park* task* /taskis done /drop* task* | ANY | Status change + log line; "done" needs evidence (section 4) | Confirmation of the change |
| status digest | ANY | Reads the index and backlog | A plain text summary |
| was* ideaconsidered? /what was left undiscussed about stream* | ANY | Reads the register | Matching lines with status and checkpoint |
| verify checkpoints | ANY | Section 6 | Each anchor's result |
| read the* Project name*board and update the catalog | MAIN | Brings a Project's news into main memory until the nightly sync exists (section 7) | Candidates, then the usual report |
| File | Holds |
|---|---|
index.md |
Every work stream, its status, where its detail lives |
backlog.md |
Open tasks by stream: the only place task status lives |
log.md |
Dated history, older months rolled up |
principles.md |
Rules of thumb you've adopted, with checkpoints |
considered.md |
Ideas declined (with your reason) or raised but not discussed |
checkpoints.md |
Chat keys, turns and anchor phrases for provenance |
quotes.md |
Planned. Exact key sentences, append-only |
Alongside the catalog, each work stream has an area file (/areas/<stream>.md) holding its current state. Each Project gets _board.md, _feed.md, _inbox.md and _considered.md. Full reference: SPEC §2.
SPEC.md the full specification (install this)
INSTALL.md how to install, check, update and remove it; how to run the tools
CHANGELOG.md spec versions
templates/catalog/ empty starter files for main memory
templates/project/ empty starter files for a Project
templates/area.md empty starter file for a work stream
examples/ a worked example with a fictional user
tools/ checks used by the safety rules (bash)
CONTRIBUTING.md how to suggest changes
CLA.md contributor licence agreement
LICENSE, LICENSE-DOCS, LICENSE-TEMPLATES the three licences (see Licence below)
NOTICE copyright notice and reservation of text-and-data-mining rights
The tools prove that a cleanup lost nothing, that a backup is complete, and that nothing personal is published. What each proves: SPEC §15. How to run them: INSTALL.md.
Specification v0.15. The index, backlog, log, principles, checkpoints and "already considered" register are in daily use. The quotes file, Project feeds and inboxes, and the nightly sync are specified but not yet running. See the changelog.
If Memory Catalog is useful to you, please leave a star ⭐ at the top of this page. It helps other people find the project and shows that it's worth continuing to develop.
Copyright (C) 2026 Donald Dominko. Different parts use different licences:
| Part | Licence | You may |
|---|---|---|
tools/ and.github/ (code) |
AGPL-3.0-only | Use, change and share it. If you distribute it, or run a changed version as a service for others, you must publish your source under the same licence. |
SPEC.md ,INSTALL.md ,CHANGELOG.md , READMEs and other documentation |
CC BY-SA 4.0 | Use, adapt and share it, including commercially, with credit to Memory Catalog and under the same licence. |
templates/ andexamples/ |
CC0 1.0 | Anything, with no conditions. Your own catalog files built from the templates are yours. |
Commercial licences for the code, without the AGPL conditions, are available from AI Partner Solutions Ltd. To ask, use the contact form at www.aipartner.london.
Text and data mining, including AI training, is reserved: it is permitted only under the terms of the applicable licence or a separate licence. See NOTICE.
Versions up to and including spec v0.14 (commit e32b809) were released under the MIT licence and remain available under it.