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.

Two jobs people keep mixing up

A store does one of two jobs. The trouble starts when one tries to do both, or several do the same one.

knowledge

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.

bigquietsearchableon demand

lives in the vault

vs

behavior

How the assistant should act: a house style, an anti-slop ruleset, a standing instruction. You want it applied every time without asking.

tinyalways onapplied every time

lives in the assistant config

Force both into one bucket and it becomes a junk drawer.

A house style or an anti-slop ruleset is a behavior plugin: a fixed chunk of text you wire in 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 (plugins). The vault holds zero behavior.

One store, three ways in

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 reaches it one of three ways, each opened on demand.

three doors, all on demand

your session

the assistant you talk to

nothing from the vault in context

always loaded

your behavior pluginsthe pointer · ~200 tokens

the pointer: the vault exists, how to search it, run imprnt context before writing

recallsearch the notes

imprnt hotthe where-was-I glance

imprnt contextrun before writing

the vault

plain files on your disk, readable in any editor

person

holding

event

note

hot.mdthe primer + needs-review

CLAUDE.mdthe contract: the filing rules

Nothing crosses on its own. Open a door and watch the one thing it brings back.

recall is the everyday way in, ranking with BM25 (how it works). The assistant runs imprnt context right before it writes, so the heavy filing rules are paid for 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: your behavior plugins, plus a ~200-token pointer saying the vault exists and how to reach it. 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

Surface vault/ notes

What it holds your knowledge

Auto-loaded no

Reached by recall

Who writes it you, through the model at filing

Surface hot.md

What it holds the primer plus needs-review

Auto-loaded no

Reached by imprnt hot

Who writes it the model, as you work

Surface the vault contract

What it holds the filing rules

Auto-loaded in the vault project only

Reached by imprnt context

Who writes it imprnt ships it

Surface the session pointer

What it holds ”the vault exists, search it”

Auto-loaded yes

Reached by injected by imp

Who writes it imprnt

Surface raw/

What it holds untouched source copies

Auto-loaded no

Reached by never searched

Who writes it code, at filing

Your assistant has its own memory, so keep it thin

imprnt usually runs under Claude Code, which writes itself a MEMORY.md per project. The first stretch of that file auto-loads every session and lives outside vault/, so recall never sees it: a second always-on store you cannot search. One rule keeps it from becoming a parallel mess:

to the vault

World and project knowledge

where recall finds it

to the assistant config

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 to be findable. Keep that memory down to a few behavior facts.

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

You want to keep A fact about a person, policy, or decision

Put it in a vault note

Auto-loaded no

Found by recall yes

You want to keep A number, table, or record

Put it in a vault note, in full

Auto-loaded no

Found by recall yes

You want to keep A primer of where things stand

Put it in hot.md, via imprnt hot

Auto-loaded no

Found by recall no - control file

You want to keep The filing rules

Put it in the vault contract, via imprnt context

Auto-loaded in the vault project only

Found by recall no

You want to keep A writing style or anti-slop ruleset

Put it in a behavior plugin in CLAUDE.local.md

Auto-loaded yes

Found by recall no

You want to keep A standing instruction

Put it in the assistant’s CLAUDE.md or its memory

Auto-loaded yes

Found by recall no

You want to keep Source transcripts and documents

Put it in a raw/ copy

Auto-loaded no

Found by recall no

The mess imprnt set out to avoid

imprnt grew out of PAI, which pointed the way and also showed what happens when three stores all read like memory:

PAI: three stores, all read like "memory"

USER/ identity and life goals, auto-loaded every session

MEMORY/KNOWLEDGE/ a curated, typed entity graph, fetched on demand

MEMORY/LEARNING/ raw timestamped wins and failures, mined later

→ collapses into

imprnt: one store, one always-on layer

knowledge: the vault one store, three ways in on demand, found by search

behavior: the assistant config a small always-on layer, applied every time

Each store loaded differently, and the jobs overlapped: USER and KNOWLEDGE both answered “who am I and what am I working on”. The result was that you could rarely say where a fact lived or whether the assistant would see it.

One question routes anything you want to keep: knowledge goes to the vault, behavior goes to the config. The longer record of these calls is in design decisions.