Read an Ability’s risk classification
Classification exists so risk is visible before a decision is made rather than after. It informs your decision; it never makes it.
- Abilities & permissions
- 5 min read
The dimensions
- Action
- Read, create, update, or delete.
- Risk
- Low through critical, based on the consequence of a successful call — not the likelihood of failure.
- Reversibility
- Whether the effect can be undone, and by whom.
- Scope
- What the action reaches: one object, a type, or site-wide configuration.
- Bulk
- Whether a single call can affect many items.
- Exposure
- Whether the result is visible to the public.
Read the combination, not one field
A low-risk update that is bulk-capable and public-facing deserves more caution than its risk label alone suggests. The combination that should always give you pause is irreversible + public-facing + bulk: one call, permanent, and visible to your customers.
Treat that combination as an approval candidate from the start, rather than as a recovery problem later.
Conservative by design
Where classification cannot be established with confidence, the Ability is treated as higher risk rather than lower. A conservative default costs you one approval; an optimistic default costs you an incident.
An Ability the plugin cannot classify is still subject to default deny. It appears in the Explorer with whatever evidence exists so you can make the call yourself.
The contextual risk engine
Beyond the static classification, the risk engine reads the request itself — its inputs, its target, its scope. It can only make a decision stricter, never weaker. An Ability you set to allow can still be escalated to review by the context of a specific call; a blocked Ability is never de-escalated by it.
Abilities & permissions
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.