Action Library — the (action × entity) catalog

What the Library is

The Library is the single catalog every permission is built from. Each entry is one scope: a resource path bound to an action.

<root>.<resource path>[.<facet>].<action>[:constraints]

org.app_group.app.create          create an application inside an app group
org.app_group.branding.update     edit the Branding card of an app group
org.member.invite                 invite a member
view.members                      open the Members page

Everything downstream refers to this catalog:

Roles hold scopes picked from it.
Forms (approval types) grant one or more scopes from it when a request is approved.
The ceiling check compares scopes that are entries in it — see Capability grants.
Server gates on API routes name a scope from it; a caller without that scope gets 403 with errorCode: "PERMISSION_DENIED" and the missing scope in required.

The Library has a high-risk end — keys, domains, organization structure — described on Event & system control. Orgs extend it with Custom actions.

How the vocabulary is formed

The managed vocabulary is derived from Axowl’s resource model, so it always matches what the product can actually do: every resource becomes a node, and the node’s kind decides which actions exist on it.

Roots. A scope starts with one of four roots:

Root	What it covers	Grantable by an org
`org`	resources that belong to the organization (app groups, members, roles, settings, …)	yes
`view`	access to a page of the console	yes
`user`	resources a person owns (their credentials, profile, linked accounts)	no
`platform`	Axowl’s own operations	no

Path. A resource sits under the resource that contains it, so the path reads top-down: an application lives in an app group, which lives in the organization — org.app_group.app. The organization itself is org.org (creating a sub-organization is org.org.create).

Actions. The kind of resource decides the verbs:

Kind of resource	Read tier	Write tier
Record (most resources)	`read` `list`	`create` `update` `delete`
Membership	`read` `list`	`invite` `suspend` `revoke` `role`
Relationship	`read` `list`	`add` `remove`
Credential	`read` `list`	`issue` `revoke`
Setting	`read` `list`	`update`
Log	`read` `list`	—

Some resources add verbs of their own, for example org.app_group.promote, org.org.verify_domain, org.setting.rotate_signing_key, org.end_user.activate.

Facets. Where a resource is edited card by card, each card is its own scope, so one card can be delegated without the rest: org.app_group.profile.update, org.app_group.branding.update, org.app_group.login_methods.update, org.app_group.security.update, org.app_group.billing.update.

Tiers and wildcards. Read (read, list) sits below write (every other verb). A trailing wildcard covers a whole subtree — org.app_group.* is everything under app groups, view.* is every page. Pages and resources are separate namespaces: org.* never covers a view.* scope, and the reverse.

Constraints. A scope can be narrowed after a colon — org.app_group.delete:creator=self — using the grammar in Capability grants. A grant made through an approval can also carry the lifecycle controls uses / ttl / exp (see Lifecycle control variables).

Examples from the managed catalog

The live list is long and grows with the product, so read it from the API below rather than from this page. These are representative entries:

Area	Scopes
Members	`org.member.invite` · `org.member.suspend` · `org.member.revoke` · `org.member.role`
Teams & reporting lines	`org.member.team_create` · `org.member.team_lead_set` · `org.member.team_member_add` · `org.member.team_member_remove` · `org.member.relationship.add` · `org.member.relationship.remove`
Roles	`org.role.create` · `org.role.update` · `org.role.delete` · `org.role.assign`
App groups & applications	`org.app_group.create` · `org.app_group.update` · `org.app_group.delete` · `org.app_group.promote` · `org.app_group.app.create` · `org.app_group.app.update` · `org.app_group.app.delete`
End users	`org.end_user.create` · `org.end_user.update` · `org.end_user.suspend` · `org.end_user.activate` · `org.end_user.delete`
Devices	`org.device_identity.create` · `org.device_identity.update` · `org.device_identity.delete` · `org.device_identity.device_binding.update`
Organization & settings	`org.org.create` · `org.org.update` · `org.org.delete` · `org.setting.read` · `org.setting.update`
Keys, domains, sign-in	`org.api_key.issue` · `org.api_key.revoke` · `org.setting.rotate_signing_key` · `org.setting.regenerate_webhook_secret` · `org.org.verify_domain` · `org.idp_connection.update`
Billing	`org.org.billing_manage`

Pages

Page access is its own axis: one scope per console page.

Scope	Page
`view.organization`	Organization Overview
`view.members`	Members
`view.suborg`	Sub-organizations
`view.settings`	Settings
`view.notifications`	Notifications
`view.applications`	Applications
`view.reporting`	Reporting
`view.roles`	Roles & Permissions
`view.enduser_directory`	EndUser Directory
`view.devices`	Device Identity
`view.audit`	Audit Integrity
`view.seals`	Seal Registry
`view.business`	Business Services
`view.billing`	Billing
`view.integrations`	Integrations
`view.customers`	Customer Relations
`view.roost`	Roost

Reading the Library

GET /api/org/{slug}/approvals/action-library

Requires a signed-in member of the organization. It returns one flat array, sorted by category and then name — the same list the console shows in the permission picker of a role and in the Create Form wizard.

[
  {
    "origin": "managed",
    "kind": "action",
    "scope": "org.app_group.branding.update",
    "name": "Org: App Group / Branding — Update",
    "category": "app_group",
    "riskLevel": 2
  },
  {
    "origin": "managed",
    "kind": "view",
    "scope": "view.members",
    "name": "Members",
    "category": "Pages",
    "riskLevel": 1
  }
]

Field	Meaning
`origin`	`managed` — defined by Axowl · `custom` — added by this organization
`kind`	`action` — a scope you can pick · `view` — a page scope · `resource` — a header row for one resource (its `scope` is empty; it is there for grouping, not for picking)
`scope`	the scope string to put on a role or a form
`name`	display name
`category`	grouping key: the first path segment under `org` for managed actions, `Pages` for page scopes, `Custom` for custom scopes, the kind of resource for `resource` header rows
`resourceEntity`	the resource type the entry belongs to; rows with the same value group under one `resource` header
`riskLevel`	the scope’s risk floor: `3` for `delete` / `revoke` / `suspend` / `issue` / `rotate_signing_key` / `regenerate_webhook_secret` · `1` for `read` / `list` · `2` for every other action, page scopes included. Custom scopes follow the same rule. Header rows carry `0`
`properties`	on `resource` rows only: the resource’s field names with `type` and `nullable` — schema only, never data

What the list contains:

Managed actions — the read-tier and write-tier scopes under org. Scopes under user and platform are not returned, because an organization cannot grant them.
Pages — the view.* scopes above.
Custom scopes — only the ones registered by the calling organization. See Custom actions.

RiskLevel

Every scope has a risk floor that follows from its last segment — 3 for the destructive and security-sensitive actions above, 1 for read / list, 2 for anything else — and a form that grants it can never be saved below that floor. The floor is worked out from the scope string when the form is saved, so it applies to every scope a form can grant: a page scope such as view.members and a custom scope such as shipment.approve both count as 2, and shipment.delete as 3 — the same values the list shows. A wildcard counts as the riskiest scope it can cover: 3 for a scope ending in .*, except view.*, which is 2. The level decides who has to approve a request — see RiskLevel → approval routing.