Memory and the vault
Two kinds of “memory” get jumbled together: what you know, and rules for how the assistant should behave. imprnt keeps one store for knowledge and one strict rule about what loads on its own, so you can always say where a fact went and whether the assistant sees it right now.
Two jobs people keep mixing up
A store does one of two jobs. The trouble starts when one store tries to do both, or several do the same one.
What you know about your world: people, policies, decisions, numbers. You want to find it when it matters and keep it out of the way the rest of the time.
lives in the vault
How the assistant should act: a house style, an anti-slop ruleset, a standing instruction. You want it applied every time without asking.
lives in the assistant config
Knowledge should be searchable and fetched on demand. Behavior should be small and applied every time without asking. Knowledge wants to be big and quiet, behavior tiny and loud, and forcing them into one bucket turns the bucket into a junk drawer.
A house style or an anti-slop ruleset is a behavior plugin: a fixed chunk of text you wire into your assistant with one import line in CLAUDE.local.md, your per-machine on-off file. It loads because you added the line, and it leaves when you delete it. See plugins. The vault holds zero behavior and force-feeds nothing.
One store, three doors
The vault is the only place knowledge lives: plain files on your disk, readable in any editor, and nothing about them pushes itself into a session. Everything crosses through one of three doors, each opened on demand.
the assistant you talk to
the pointer: the vault exists, how to search it, run imprnt context before writing
plain files on your disk, readable in any editor
Nothing crosses on its own. Open a door and watch the one thing it brings back.
recall is the everyday door. It searches the vault with BM25 ranking and hands back the best hits (how it works). imprnt hot is the “where was I” glance: the short primer in hot.md plus anything that needs review. imprnt context prints the full filing rules, and the assistant runs it right before it writes a note, so outside the vault project the heavy rules are paid only by the sessions that write. A session inside the vault project, like imp lair, loads the contract natively from its CLAUDE.md.
An imp session loads almost nothing on its own: your behavior plugins, plus a small pointer (~150 tokens) saying the vault exists, how to search it, and to run imprnt context before writing. A day of reading costs that pointer, never the whole vault.
| Surface | What it holds | Auto-loaded | Reached by | Who writes it |
|---|---|---|---|---|
vault/ notes | your knowledge | no | recall | you, through the model at filing |
hot.md | the primer plus needs-review | no | imprnt hot | the model, as you work |
| the vault contract | the filing rules | in the vault project only | imprnt context | imprnt ships it |
| the session pointer | ”the vault exists, search it” | yes | injected by imp | imprnt |
raw/ | untouched source copies | no | never searched | code, at filing |
vault/ notes recall hot.md imprnt hot imprnt context imp raw/ Your assistant has its own memory, so keep it thin
imprnt usually runs under Claude Code, which writes itself a MEMORY.md about each project as it works. The first stretch of that file auto-loads every session and lives outside vault/, so recall never sees it. That makes it a second always-on store you cannot search, and one rule keeps it from turning into a parallel mess:
World and project knowledge
where recall finds it
A standing behavior or preference
in CLAUDE.md or its auto-memory
The same fact never lives in both. Two copies drift, and one is invisible to search.
The easy mistake is parking searchable knowledge in the store that cannot be searched. While building imprnt, project facts about the website and a plugin landed in the assistant’s memory and had to be moved into the vault to be findable. Keep the assistant’s memory down to a few behavior facts, and let the vault carry everything you will look up later.
Where each thing goes
| You want to keep | Put it in | Auto-loaded | Found by recall |
|---|---|---|---|
| A fact about a person, policy, or decision | a vault note | no | yes |
| A number, table, or record | a vault note, in full | no | yes |
| A primer of where things stand | hot.md, via imprnt hot | no | no - control file |
| The filing rules | the vault contract, via imprnt context | in the vault project only | no |
| A writing style or anti-slop ruleset | a behavior plugin in CLAUDE.local.md | yes | no |
| A standing instruction | the assistant’s CLAUDE.md or its memory | yes | no |
| Source transcripts and documents | a raw/ copy | no | no |
hot.md, via imprnt hot imprnt context CLAUDE.local.md CLAUDE.md or its memory raw/ copy The mess imprnt set out to avoid
imprnt grew out of PAI, which pointed the way and also showed where several memory stores blur together. PAI carried at least three, and every one of them read like “memory”:
Each store loaded differently, and the jobs overlapped. USER and KNOWLEDGE both answered “who am I and what am I working on”. The two MEMORY stores sat at opposite ends, one curated and permanent, one a raw timestamped stream. The result: you could rarely say where a fact lived or whether the assistant would see it.
imprnt collapses that into one knowledge store with three on-demand doors, plus the assistant’s small always-on behavior layer. One question routes anything you want to keep: knowledge goes to the vault and is found by search, behavior goes to the config and loads every time. The longer record of these calls is in design decisions.