Action Library — the (action × entity) catalog

[2026-07-08 rework] The catalog is no longer a hand-written list — it is derived from the database schema at boot (EntitlementLibrary.Build: entities × FK containment × declared facets × kind-valid verbs, ~450 scopes). GET /api/org/{slug}/approvals/action-library serves the derived action layer ∪ the org’s custom Permission rows (ReportingEndpoints.cs). The legacy hand-named GrantableActionCatalog (~80 actions), ViewScopeCatalog, and ResourceCatalog have been deleted; the approval engine sources its ceiling from EntitlementSubsumption over the derived library — see docs/2026-07-08-entitlement-library-derivation.md. The per-row detail in the tables below is a legacy reference view — the live vocabulary is whatever the schema derives, so treat individual cells as illustrative. Lifecycle ttl/exp enforcement and custom-action authoring remain 🚧 Design. See Capability grants for the model this sits under.

What the Library is

The Library is the single catalog every permission is built from. Each entry is one (action × entity) pair — a verb bound to a concrete thing — carrying the variable slots it accepts and the event it emits.

entry = (action, entity) → { variable slots, emitted event, operation }

A bare action string (device.access.approve) is abstract — it names nothing real. Bound to an entity (DeviceBinding) it becomes substance: a thing the system can grant, check, and seal. Everything downstream references this catalog:

Permissions are catalog entries (managed IsSystemPermission, or custom org rows).
Forms / approval types pick an action from it.
The Action List at submission draws its fields from the entry’s variable slots.
The ceiling check compares scopes that are entries in it.

The vocabulary is the event catalog — every grantable action is an event a principal causes (entity.action), so the Library is the grantable subset of Events.

Each entry also carries a RiskLevel (0 Routine → 4 Sovereign) that routes how the grant is approved — auto-grant, supervisor, owner-passkey, or multi-approval (see Event & system control). The Library splits in two: a business tier (this page) and a platform tier — the highest-risk control over events, ownership, and keys, on Event & system control. Orgs extend it with Custom actions.

Managed catalog

Axowl-defined actions, grouped by entity. Variables show name[kind]:

Ceiling-bearing (the subsume check compares these): [ref] entity-reference · [set] categorical · [num] numeric.
Input only (carried into the action, never compared by the ceiling): [in].

Every entry also accepts the lifecycle controls uses / ttl / exp (see Capability grants), plus a RiskLevel that routes its approval.

RiskLevel at a glance (exact value is set per action in the catalog; these are the typical tiers):

0–1 Routine / Standard (auto-grant) — most create / reads / invite.
2 Elevated (supervisor) — assignRole · changeRole · grantAccess · grant · suspend / remove / revokeAccess member · createRefund · approve settlement.
3 Critical (owner passkey) — delegate permission · delete application · anonymize / delete / merge user · revoke device.

Platform-tier actions (3–4) live on Event & system control.

Identity & Access

Action	Entity	Variables	Emits
`approveAccess`	DeviceBinding	`device[ref]` `os_class[set]`	`device.lifecycle.activated`
`revoke`	DeviceBinding	`device[ref]`	`device.lifecycle.revoked`
`block`	DeviceBinding	`device[ref]` `reason[in]`	`device.lifecycle.blocked`
`invite`	ConnectedId (member)	`email[in]` `role[ref]`	`org.member.invited`
`assignRole`	ConnectedId (member)	`member[ref]` `role[ref · level-ordered]`	`connectedId.authorization.role_assigned`
`changeRole`	ConnectedId (member)	`member[ref]` `role[ref]`	`org.member.role_changed`
`suspend`	ConnectedId (member)	`member[ref]`	`org.member.suspended`
`remove`	ConnectedId (member)	`member[ref]`	`org.member.removed`
`revokeAccess`	ConnectedId (member)	`member[ref]`	`org.member.access_revoked`
`create`	Role	`name[in]`	`auth.role.created`
`assign`	Role	`member[ref]` `role[ref]`	`auth.role.assigned`
`addPermission`	Role	`role[ref]` `scope[ref]`	`auth.role.permission_added`
`removePermission`	Role	`role[ref]` `scope[ref]`	`auth.role.permission_removed`
`create`	Permission	`scope[set]`	`auth.perm.created`
`grant`	Permission	`member[ref]` `scope[ref]`	`auth.perm.granted`
`revoke`	Permission	`member[ref]` `scope[ref]`	`auth.perm.revoked`
`delegate`	Permission	`member[ref]` `scope[ref]` `amount[num]`	`auth.perm.delegated`
`registerPasskey`	UserCredential	`member[ref]`	`device.passkey.registered`
`revokePasskey`	UserCredential	`credential[ref]`	`device.passkey.revoked`
`trust`	DeviceBinding	`device[ref]`	`device.lifecycle.trusted`
`issueEnrollmentToken`	DeviceBinding	`device_class[set]`	`device.enrollment.token_issued`

Apps & Integration

Action	Entity	Variables	Emits
`create`	Application	`name[in]`	`app.lifecycle.created`
`delete`	Application	`app[ref]`	`app.lifecycle.deleted`
`grantAccess`	Application	`app[ref]` `member[ref]` `level[set]`	`app.access.granted`
`revokeAccess`	Application	`app[ref]` `member[ref]`	`app.access.revoked`
`changeSecurity`	Application	`app[ref]`	`app.sec.oauth_settings_changed`
`create` / `update` / `delete`	AppGroup	`group[ref]`	`org.app_group.*` (derived)
`enable`	Integration	`module[set]`	`org.integration.enabled`
`disconnect`	Integration	`module[set]`	`org.integration.disconnected`
`grantPermission`	Integration	`module[set]` `group[ref]` `scopes[set]`	`org.integration.permission_granted`

Org structure (Reporting)

Action	Entity	Variables	Emits
`create`	Team	`name[in]`	`reporting.team.created`
`setLead`	Team	`team[ref]` `member[ref]`	`reporting.team.lead_changed`
`addMember`	Team	`team[ref]` `member[ref]`	`reporting.membership.added`
`removeMember`	Team	`team[ref]` `member[ref]`	`reporting.membership.removed`
`addReporting`	ConnectedId	`member[ref]` `supervisor[ref]`	`reporting.relationship.added`

Org administration

Action	Entity	Variables	Emits
`updateSettings`	Organization	—	`org.settings.updated`
`configureSSO`	Organization	`provider[in]`	`org.access.sso_configured`

Keys, signing-key rotation, plugin tokens, domain, policy, seal, and sovereign org actions live in the higher-risk Event & system control tier — not here.

Business & Finance

Action	Entity	Variables	Emits
`createRefund`	Invoice	`invoice[ref]` `amount[num]`	`payments.refund.created`
`cancel`	Invoice	`invoice[ref]`	`payments.invoice.cancelled`
`approve`	Settlement	`settlement[ref]` `amount[num]`	`commerce.settlement.approved`
`adjust`	Settlement	`settlement[ref]` `amount[num]`	`commerce.settlement.adjusted`
`cancelSubscription`	Subscription	`subscription[ref]`	`payments.sub.cancelled`
`applyDiscount`	Invoice	`invoice[ref]` `percent[num]`	`payments.billing.discount_applied`
`create` / `cancel`	Meeting	`meeting[ref]`	`business.meeting.*`

End users

Action	Entity	Variables	Emits
`create`	EndUser	`appgroup[ref]`	`enduser.lifecycle.created`
`suspend`	EndUser	`enduser[ref]`	`enduser.status.suspended`
`activate`	EndUser	`enduser[ref]`	`enduser.status.activated`
`delete`	EndUser	`enduser[ref]`	`enduser.lifecycle.deleted`

Users (admin / compliance)

Action	Entity	Variables	Emits
`verifyIdentity`	User	`member[ref]`	`user.identity.verified`
`linkExternalSystem`	User	`member[ref]` `system[in]`	`user.identity.external_system_linked`
`anonymize`	User	`member[ref]`	`user.lifecycle.anonymized`
`delete`	User	`member[ref]`	`user.lifecycle.deleted`
`recover`	User	`member[ref]`	`user.lifecycle.recovered`
`merge`	User	`member[ref]` `into[ref]`	`user.lifecycle.merged`

GDPR / PIPA actions — anonymize / delete / recover are high-risk and sealed for proof.

Assets

Action	Entity	Variables	Emits
`define`	AssetDefinition	`name[in]`	`asset.definition.created`
`issue`	AssetInstance	`definition[ref]` `holder[ref]`	`asset.instance.issued`
`revoke`	AssetInstance	`instance[ref]`	`asset.instance.revoked`

Reporting (initiating an approval)

The grantable capability is the right to initiate a given approval type:

Action	Entity	Variables	Emits
`initiate`	ApprovalType (WorkItem)	`type[ref]`	`reporting.approval.requested`

What is not grantable

Not every event is an action you delegate. The Library is the principal-action subset; these stay out:

Detection — *.security.* (suspicious login, anomaly, tampering, brute force), integrity.data.*
Automatic / system — *.session.* (created / refreshed / expired), audit.rollup.created, *.monitoring.*, auth.perm.cache_*, session.activity.heartbeat
Lifecycle by-products — events emitted as a result of a granted action, not the action itself
Reads / views — viewing data (a member, a report, an audit page) is mostly event-light and is handled by plain RBAC, outside this grant-Library. The Library is the mutation / decision catalog — the things a principal causes, which emit a sealed event. (A read that must be proven — e.g. a sensitive export — can still emit an event and be added.)

These appear in the audit chain; they are simply never something a person is granted the right to cause.