---
title: "Note types"
description: "A note's class is a bundle of visibility and indexing policies the system infers from where the note is stored — not a free-form field you fill in."
---

# 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.

> [!note] Memory is visible to you, but it belongs to the agent
> 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](/docs/agents/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](/docs/concepts/spaces-and-projects/).