BreethDocs v0.1
Concepts

Projects & Teams

How Breeth isolates memory across customers.

Breeth has two levels of isolation. Both are hard boundaries — no read or write ever crosses them.

team Acme Corp
  └─ project: candidates
  └─ project: competitors
  └─ project: playbooks

Team

A team is what Clerk calls an Organization — the top-level tenant. One team has one billing relationship, one tier, one set of caps. Members can be admins, managers, or developers. Team ↔ company is 1:1 in normal use.

Project

A project lives inside a team. It's a namespace for memory that lets one team keep distinct workstreams separate without spinning up a new account.

Every team has at least one project — default — created automatically at signup. You can create more from the dashboard (subject to your tier's max_projects cap; Pro and Enterprise are unlimited).

How isolation is enforced

Every node and edge in Breeth's graph is stamped with a composite partition key:

t_<team_uuid>_p_<project_uuid>

Every read filters on that key. Two different teams writing to a group_id named "default" see disjoint data because their partition keys differ. Inside a team, two projects do the same.

Who is allowed to write

Authentication happens at two layers:

  • REST API: a Bearer ck_live_… key. The key is minted in the dashboard against a specific (team, project). The key's project is what every write of that key lands in.
  • MCP / Dashboard JWT: the active team and active project from the session. The dashboard lets users switch active project; the active project is what their writes land in.

Member roles

Within a team there are three roles:

RolePowers
adminEverything — billing, project create/delete, role changes, member invites
managerInvite/remove members, create projects, no billing access
developer (member in Clerk)Write/read in projects they have access to. Cannot create projects or manage members.

Audit trail

Every node and edge is also stamped with the member_id of the writer. Members don't gate reads — the whole team sees the whole project's memory — but you can always answer "who wrote this fact?" from the stamp.

What does NOT scope memory

  • The user-supplied group_id on a write (e.g. "default", "candidates") is a sub-namespace inside a project. It's a query convenience, not a security boundary.
  • The cardholder name / billing email — never used for access decisions.

The only security boundaries are (team, project). Everything else is metadata.

On this page