Event & system control — the platform tier

🚧 Design

The platform-control tier of the Action Library. Higher-risk than any business action — these govern the audit substrate and the org itself.

The most sensitive tier

Every action in Axowl emits an event, and every event is sealed into the chain. So controlling the events = controlling the audit substrate. “Who can turn off the audit trail?” or “who can redefine what permissions exist?” are the most privileged grants of all — far above any single business action.

These actions sit at the top of the RiskLevel scale (Critical / Sovereign): never auto-granted, always routed to the highest approval (owner passkey or multi-approval).

Variables follow the same convention as the Action Library: [ref] / [set] / [num] are ceiling-bearing (compared by subsume), [in] is input only.

Event control

Actions over the event / audit pipeline itself.

Action	Entity	Variables	Emits	Risk
subscribe / unsubscribe	EventSubscription	event[set] endpoint[ref]	event.subscription.*	Elevated
configureWebhook	WebhookEndpoint	endpoint[ref] url[in]	org.keys.*	Elevated
regenerateWebhookSecret	WebhookEndpoint	endpoint[ref]	org.keys.webhook_secret_regenerated	Critical
toggleEventRecording	EventConfig (e.g. EndUserEventsEnabled)	category[set]	settings	Critical — pauses a peripheral capture category only; the core sealed chain is always-on and immutable (see Protected boundary)
registerCustomEvent / defineCustomAction	the catalog itself	name[in] schema[in]	CustomEventRegistered	🔴 Meta

registerCustomEvent = the right to define rights

registerCustomEvent / defineCustomAction doesn’t act on a business object — it adds an entry to the Library. It is the meta-authority: the right to define what rights exist. Grant it as carefully as ownership itself. Defining an action does not grant it — a newly-defined capability is held by no one at *; it must still be granted normally. Otherwise “define + self-grant” would be an escalation.

System / sovereign actions

Actions over the organization and its keys — structural, irreversible-ish, top-tier.

Action	Entity	Variables	Emits	Risk
transferOwnership	Organization	newOwner[ref]	org.security.owner_transferred	🔴 Sovereign (multi-approval)
suspend / deactivate / delete	Organization (SubOrg)	org[ref]	org.lifecycle.suspended/deactivated/deleted	🔴 Sovereign
reparent	Organization	org[ref] parent[ref]	org.hierarchy.parent_changed	Critical
rotateSigningKey	Organization	—	org.keys.signing_key_rotated	Critical
createApiKey / revokeApiKey	Organization	name[in] / key[ref]	org.keys.api_key_*	Critical
createPluginToken / revokePluginToken	Organization	token[ref]	org.keys.plugin_token_*	Critical
verifyDomain / changePrimaryDomain	Organization	domain[in]	org.access.domain_verified / primary_domain_changed	Critical
updatePolicy / updateSecurityPolicy	Organization	—	org.policy.updated / security_updated	Critical
register / revoke / upgrade	Seal	member[ref] tier[set]	seal.lifecycle.*	Critical

RiskLevel → approval routing (whole Library)

Every Library entry carries a RiskLevel; it picks how the grant is approved. This is the bridge between the catalog and the approval line.

Risk	Name	Routing
0	Routine	auto-grant
1	Standard	auto-grant
2	Elevated	direct supervisor approval
3	Critical	owner passkey signature
4	Sovereign	simultaneous multi-owner approval

Everything on this page defaults to 3–4. Business actions in the Action Library usually sit at 0–2.

---

Related: Action Library · Custom actions · Capability grants · Events