Spaces and projects

Notarium draws a line between two units of organization: the space — an isolated knowledge base and a security boundary — and the project — a tagged folder inside a space. These are different things with different jobs: a space isolates, a project organizes.

The space — the unit of isolation

A space is a self-contained knowledge base: its own index, graph, search, tree, history log, and its own set of members. Spaces don't overlap: the notes, search, and links of one aren't visible from another. A space plays two roles at once — organization ("personal" / "work" / "archive") and a security boundary: it's at the space level that who-sees-what is decided.

• Each space is served by exactly one engine instance — isolation comes from the architecture itself.
• A space's identity is a stable internal space_id; the slug (URL-safe: lowercase Latin letters, digits, hyphens, and underscores — [a-z0-9_-]) is a renameable address and URL handle, while displayName is a human-readable label. Renaming a slug is safe: the old name moves into alias history and keeps resolving (/s/<old> redirects to the current one).
• Addressing: /s/<slug> in the interface and /api/s/<slug>/… in REST.

For more on roles and privacy, see Access model.

The personal space

Every user is guaranteed to have a personal space — their default home:

• it's created when the account is provisioned, and it can't be deleted;
• it serves as the default landing page and holds agents' private memory about you and your profile;
• it's a full-fledged workspace: you can start taking notes and tagging projects right away, without setting anything up separately.

The project — a tagged folder

A project is a lightweight, optional entity: an ordinary folder subtree inside a space that has been tagged as a project. Content doesn't have to live in projects — an untagged folder stays just a folder.

The tag is a dot-file .notariummeta at the folder's root (JSON with a stable id). It travels with the folder through any move, including an external one (git, a file manager) — a project's identity is anchored in the folder itself, not only in the database.

myspace/
├─ research/
│  └─ .notariummeta      ← tagged folder = project
├─ inbox/                ← plain folder (not a project)
└─ ...

• Addressing is a handle (space, slug), on GitLab's group/project model. A project's slug is unique within a space; same-named projects across spaces are told apart by the space field. The root project collapses to just <space> (e.g. main, not main/main).
• A project's slug is a transliterated kebab-case form of displayName or the last path segment (not the whole path).
• Tagging a folder, removing the tag, or creating a "New project" are human actions (the space:write permission). An agent doesn't create containers: it owns the content, the human owns the structure.
• Creating a space auto-tags its root as a project — so the agent can write to <space> right away, with no manual tagging.

A project is a scope and an address, but not a security boundary: the access decision always rests with space membership. For how an agent addresses projects, see Intent tools.