The Roles Behind "Who Can Edit This Article"
Knowledge's read/write/manage capability model recurs across nearly every feature in the product — one explainer of how it actually works, instead of a dozen implicit mentions.
Role-based access control is a standard checklist item in any enterprise evaluation of a collaborative content tool, and it's easy to answer that checklist vaguely. Knowledge's answer is specific and consistent enough to deserve one canonical explanation, because the same three-tier model shows up, unstated, across nearly every feature this platform has.
The three capabilities
Access in Knowledge is checked against three levels — read, write, and manage — via a consistent requireCapability(auth.role, ...) check used across the product's route handlers. It's not a different permission scheme per feature; it's the same three-tier check, applied with different thresholds depending on how consequential the action is.
What actually requires what
The pattern, once you see it, explains a lot of behavior that otherwise looks like inconsistency between features:
readis the lowest bar — previewing an unpublished site (see the guide on previewing before you publish) only needsread, because looking at your own space's content isn't a change to anything.writecovers day-to-day authoring — creating or updating a reusable snippet requireswrite, since it changes content but doesn't affect anything structural about the space itself.manageis reserved for decisions with wider blast radius — applying a template, restoring an old version, or claiming a custom domain all requiremanage, because each of those actions affects the space's structure or its public-facing footprint, not just a single piece of content.
Why this matters more than it looks like it should
Once you know the three-tier model, a lot of "why can't I do this" questions answer themselves without needing to check documentation for each individual feature. If someone on your team can create snippets but can't claim a domain, that's not a bug or an inconsistent permission setup — it's the same write-versus-manage boundary applied predictably. The model being consistent is what makes it trustworthy: you can reason about a feature you've never used yet based on how consequential the action is, rather than needing to memorize a separate permission rule for every route in the product.
Setting up your team with this in mind
When assigning roles, think in terms of the two real questions the model is actually answering: who should be able to change content day to day (write), and who should be able to change what the space itself looks like or where it lives — templates, versions, domains (manage)? Most teams have more people who need the first than the second, and Knowledge's model is built around exactly that asymmetry rather than treating every permission as equally sensitive.