Scopes & domains

A correction you make in one project shouldn’t leak into a different one. PLUR uses two orthogonal mechanisms: scope controls where an engram applies; domain controls what topic it covers.

Scope

Scope is a hierarchical namespace. Examples:

global — always loaded
project:my-app — only loaded for my-app
cluster:prod — only loaded when working against the prod cluster
service:api — only loaded for the api service
group:acme/platform — Enterprise team scope (details)

Recall filters by the current scope but always includes global. So if you’re in project:my-app and ask “what do I know about deploys”, you get project:my-app engrams + global engrams, not project:other-app.

Setting current scope

Adapters detect scope automatically from the active project:

Claude Code / Cursor / Windsurf: PLUR reads .plur.yaml from the project root if present.
CLI: plur init --scope project:my-app writes .plur.yaml.
Programmatic: pass scope to any MCP tool.

`.plur.yaml`

scope:  project:my-app
domain: backend          # default domain when learning

Hooks pick this up automatically — corrections made in this project get tagged with scope: project:my-app and domain: backend unless you override.

Domain

Domain is a topic tag. Examples:

software.deployment
software.git
plur.brand
infrastructure.agents
firm.miles.heartbeat

Conventional separator is . — feel free to invent. Domain is soft routing: recall doesn’t strictly filter by domain, but the embedder weights it heavily, so an engram with domain: software.deployment ranks higher when you ask deploy questions.

How scope and domain combine

Scope	Domain	Behaviour
`global`	unset	Always considered.
`project:x`	unset	Considered when current scope = `project:x`.
`global`	`software.git`	Always considered, but ranks higher on git topics.
`project:x`	`software.git`	Considered for `project:x`; ranks higher on git topics inside `project:x`.

The rule: scope is a hard filter, domain is a soft signal.

Enterprise group scopes

In PLUR Enterprise, you also get team scopes:

group:acme — anyone in the acme org
group:acme/platform — only the platform team
group:acme/platform/api-service — service-level

These resolve against your identity (OIDC, SAML, GitHub, GitLab) and the team membership recorded in the admin dashboard. Permissions are enforced server-side — see Permissions & scopes.

Next: Activation & decay →