Feed

Who sees what, and who decides.

A Space is a team or project area, and it is the narrowest thing knowledge can be scoped to. Five roles decide who reads it, who approves it and who holds the credentials, and the same answer is enforced in the webapp, the CLI, the MCP server and Slack alike.

A Space is the narrowest scope there is

A Space is a team or project area inside your workspace: Backend API, Mobile, Infrastructure, Design System. Every rule, skill, memory and document is scoped either to the whole workspace or to one Space, and there is no third rung. An atom cannot be scoped narrower than a Space, which is a deliberate floor rather than a gap: a per-repo or per-person scope is a permission question nobody can answer on their own behalf.

The scope is what keeps the brain focused rather than merely private. A convention that applies to the backend should not be served to somebody working on the mobile app, and the cost of getting that wrong is not a leak, it is a prompt full of rules that do not apply and an agent that starts ignoring all of them.

You choose the scope where the knowledge comes in: approving a proposal, uploading a document, or attaching a connector unit. See sources for the connector half, which has one trap worth reading before you connect anything.

The five roles

Roles are presets over capabilities rather than the other way round, which is why the interesting question is never “what is a curator” but “which of the thirteen powers does this person hold, and where”.

Workspace roles, strongest first.
Role	Holds	Who it is for
Owner	Everything, including deleting the workspace and transferring ownership.	One person. Ownership moves through Transfer ownership, which is its own confirmed action, because the column that stores it holds one id.
Admin	Everything except transferring ownership: connectors, members, billing, Spaces, and all of the knowledge powers.	The people who run the account.
Curator	Publish, curate, distribute and bind repos at their scope, and see which connectors feed the brain.	A senior engineer who should approve rules for their team and touch nothing about the company account. No members, no billing, no credentials, no Spaces.
Member	Read the brain, and propose a learning into Review.	Everybody who uses Harbor. They cannot approve their own proposal or anybody else’s.
Viewer	Read, and nothing else.	Guests, auditors and trials. The only difference from a member is that a viewer cannot capture.

The thirteen capabilities

This is the matrix the product itself renders on the roles page in settings, so you never have to take a docs table’s word for it. Each row is one hard boolean about one button or endpoint.

Capability	What it grants	Answerable at
`knowledge.read`	See rules, skills and memories at a scope	Space or workspace
`knowledge.capture`	Propose a learning — it lands in Review	Space or workspace
`knowledge.publish`	Approve or dismiss a proposal, resolve a conflict	Space or workspace
`knowledge.curate`	Edit, archive or re-scope a published rule, skill or memory	Space or workspace
`knowledge.distribute`	Connect a document or skill to repositories and people	Space or workspace
`repo.bind`	Re-point, unbind or pause sync on a repository	Space or workspace
`source.read`	See connectors and what they cover	Workspace only
`source.manage`	Connect, configure or disconnect a connector	Workspace only
`space.manage`	Create, rename or delete a Space and manage who is in it	Workspace only
`member.manage`	Invite or remove people, and change workspace roles	Workspace only
`billing.manage`	Plans, seats and invoices	Workspace only
`workspace.manage`	Rename the workspace and change its settings	Workspace only
`workspace.transfer`	Delete the workspace or transfer ownership	Workspace only

Owner holds all thirteen.
Admin holds twelve: everything but workspace.transfer.
Curator holds seven: knowledge.read, knowledge.capture, knowledge.publish, knowledge.curate, knowledge.distribute, repo.bind and source.read.
Member holds two: knowledge.read and knowledge.capture.
Viewer holds one: knowledge.read.

Why a curator can see connectors but not change them

source.read without source.manage is deliberate, and the rung does the rest of the work. A curator needs to know what is feeding the brain they are curating. They must not be able to re-point it at a different Slack. And because source.read is workspace-rung, a curator of one Space does not get it at all.

This pair is the answer to the request that has no answer in most products: this senior developer should approve rules for his team, but must not touch billing, members or our Slack credentials. Before curator existed, approving a learning and paying the invoice were the same grant.

What reaches into a Space

A workspace role and a Space role are two different facts, and your effective role in a Space is the stronger of them.

Workspace role	Reach
Owner	Every Space, without being added to any of them.
Admin	Every Space, without being added to any of them.
Curator	Every Space, without being added to any of them.
Member	Only the Spaces they are explicitly added to.
Viewer	Only the Spaces they are explicitly added to.

Inviting people

Invite people sits at the bottom of the sidebar, and the members and access pages in workspace settings are where roles change afterwards. Spaces themselves are created, renamed and deleted in settings under Spaces.

Start with one or two Spaces

Not five. A Space earns its existence when a rule in it would be wrong somewhere else, and until you have seen that happen, a workspace-wide scope is both simpler and more useful. You can re-scope a published rule later, which is what knowledge.curate is for.

The one thing worth doing early is making somebody a curator for their own area. The failure mode for this whole product is a review queue nobody clears, and the fastest cause of that is one admin being the only person allowed to approve.

Next, the numbers that tell you whether any of the scoped knowledge reached an agent: served versus cited.