Note types
Every note has a class — it determines where the note is visible and how it is indexed. The class is not a free-form label in the frontmatter that you can set by hand: it is a bundle of policies that the system infers from where the note is stored and applies on its own. In an API response, the class is read-only.
The class is a bundle of policies
Behind each class sits a bundle of policies — yes/no on each one: whether the note is indexed, whether it shows up in the graph, the Feed, the tree, user-facing search, whether it is available to an agent's recall, whether it is versioned, whether it is replicated. The key point: visibility is checked in one place, not by a filter you have to remember to add to every query. "Hide from results" and "exclude from the index" are different things, and Notarium never conflates them.
A note's identity is its notarium-id, not its path. That is why moving or renaming it never silently changes the class or breaks the indexes.
The class registry
| Class | Status | Visibility |
|---|---|---|
user-doc | live | Visible everywhere: tree, Feed, graph, search. The default for all user content. |
agent-memory | live | Indexed and available to an agent's recall, but hidden from user-facing surfaces; visible to the owner in a separate section. |
attachment | carries policies | Attachments are full-fledged data, but they aren't indexed as knowledge: only .md files are searchable. |
derived | carries policies | Regenerable artifacts (previews, renders); they don't reach the index. |
profile | live | Hidden everywhere you search and browse notes; available only through Settings → Profile and to the agent in start_session. |
The two classes you work with
In practice, two classes stay active and keep filling up.
user-doc — your notes. The default class: freely organized in the tree, feeding into search, the graph, and the Feed. This is exactly what both a person (through the editor) and an agent (through create_note) write to.
agent-memory — the agent's memory. These are readable notes, not a hidden store: the agent appends observations to one file per category rather than spawning micro-files. Memory lives in a separate service folder, .notarium/memory/, so it doesn't mix with your tree and doesn't collide with your folders.
You read, edit, and delete the contents of memory — that's how you audit and control what may have made it into context (the history shows who wrote what). But you don't reorganize it: the layout belongs to the agent (a flat set of categories plus a derived index). Moving things is technically safe — the ban on reorganizing is a product decision, so the memory model stays predictable.
The memory index is derived: it is assembled from the summary field of each memory file and rebuilt with a full rescan. It loads right away in start_session, while the files themselves are pulled in on demand through recall. More in Agent memory.
profile — "about you"
A dedicated class for the profile note: human-authored content about you (written by you, not the agent). It is hidden everywhere you search and browse notes, and can be reached in only two ways — through Settings → Profile and by having start_session load it into the agent's context by identifier. This isn't the agent's memory; it's a context card that you curate.
The class is inferred from where the note is stored and set by the system — the agent picks neither the folder nor the class. For how this ties into isolation and addressing, see Spaces and projects.