Teams and Roles
What a team is
capability grants on resources and cognitive maps, and gate who can read and modify what. A
team is the unit of shared reach: membership confers read access to everything the team owns
or is granted, automatically, through nested teams.
personal-<handle>) automatically — soyou always belong to at least one team, and your personal contexts live under it.
The role ladder
| Role | Can do |
|---|---|
owner | Everything, plus delete the team and transfer/reassign resources. Only owners can invite at any role. |
maintainer | Manage membership (invite, remove, change roles), update team metadata. |
member | Read and contribute to the team's shared work. |
watcher | Read-only visibility into the team's shared resources. |
offboarding). Invitations top out at
maintainer.Nested teams
--parent <ref> at creation). Child teams inherit theparent's read reach while the parent stays active. This is how a large organisation models
sub-teams without granting write across boundaries: the child reads up, the parent does not
write down.
What membership grants — and what it does not
needs to administer the context (or be an instance admin). To share one of your own contexts
with a team, you use
context share — which grants the team read access, not write. Theonly path to shared authorship is transferring ownership.
access to the shared body of work, but writing is a separate, explicit grant. A new member is
never silently able to modify something they just gained read access to.
Further reading
Contexts and Refs.
temperkb.io/operating/governance-and-administration.
Modified at 2026-08-20 02:05:41