---
title: "Spaces and projects"
description: "A space is an isolated knowledge base and a security boundary; a project is a tagged folder inside it that an agent reaches by a stable name."
---

# 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](/docs/concepts/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.

> [!important] You can't invite a second member into a personal space
> This is the only way a personal space differs from a regular one. Another member with read access would see your private memory and personal notes — so invitations to a personal space are forbidden on the server, not just hidden in the interface.

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

```md
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](/docs/agents/intent-tools/).

> [!note] Requirements and boundaries
> Projects rely on the metadata database and local tag storage — without them a project can't be opened.