Scope kinds
An entry's scope is one of four strings:
org— everyone in the workspace.team:<id>— members of a specific team.role:<id>— anyone holding a specific role.user:<id>— a single person.
The grammar is org | (team|role|user):<id>. Each entry carries one scope — pick the narrowest one that is correct (a team convention is team:<id>, not org).
The <id> segment is the ULID of the team, role, or user — the same id the app assigns when you create one (26 characters, e.g. 01JQZ9F7X2K3M4N5P6R7S8T9VB). Concrete examples, matching the shape of the seeded Acme workspace:
org— a company-wide rule every agent must follow, like “always cite entry ids.” Visible to everyone in the workspace.team:01JQZ9F7X2K3M4N5P6R7S8T9VB— a convention scoped to the Engineering team (the id is that team's ULID). Only Engineering members retrieve it.role:01JQZ9FKB7YH3F0N5D6WMR8XZ2— guidance for anyone holding the Engineer role, regardless of which team they sit on.user:01JQZ9FC2M9P4R6T8V0X1YB3DQ— a single person's preference (e.g. Alice's own default), visible only to them.
What an agent sees
Reads are filtered to the caller's scopes automatically, enforced at the database with row-level security — not in application code. A request only ever sees entries in org, the teams the caller belongs to, the roles they hold, and their own user scope. Both lore_search and the bootstrap pack are scoped this way, so an agent never has to reason about other teams' rules — it simply cannot retrieve them.
Narrow-first precedence
When guidance overlaps, precedence runs narrow-first:
user > role > team > org
This ordering is how retrieval renders results, so the most specific guidance appears first. The bootstrap pack is compiled in exactly this order (user, then role, then team, then org), and within a scope, MUST entries come before SHOULD. A personal user: preference therefore sits ahead of a broader org default in the pack an agent loads.
Grants, teams, and roles
Two different mechanisms combine to decide what a person can do:
- Team & role membership determines which scopes you can read — being on a team adds that
team:<id>scope to your visibility, and everyone can readorg. - Access grants determine what you can write and approve. A grant has a level —
viewer,editor, oradmin— and is either org-wide or attached to a single scope.
Write and approval access resolve like this:
- An admin grant can write and approve every scope in the org.
- An org-wide editor grant (no scope attached) can write and approve every scope.
- A scoped editor grant can write and approve only its exact scope.
- Viewers, and editors acting outside their scope, cannot write or approve.
You can only ever target a scope you can already read — attempting to write to a scope outside your visibility is rejected. Call lore_whoami to see your teams, roles, and the scopes you may write to.