Recovery
When an action cannot be undone
Classification tells you which Abilities cannot be undone before you grant them. That is the argument for approval, made in advance.
- Recovery & emergency
- 4 min read
What to do now
- Stop the agent so it cannot repeat the action on other objects.
- Establish the exact scope from the evidence. With a bulk-capable Ability, the difference between one object and four thousand is the whole problem.
- Check for an external copy — a database backup, the provider’s own history, a CDN or search cache, an export someone made.
- Decide whether a broad restore is proportionate. Sometimes it is; it costs everyone else’s work since the backup.
- Export the evidence before any restore, or you will lose the record of what happened.
The combination to watch for
Irreversible on its own is manageable. The combination that causes real damage is irreversible + public-facing + bulk: one call, permanent, and visible to your customers before you notice.
The Ability Explorer shows all three dimensions on the detail view. Filtering for that combination and reviewing what you find is an hour well spent on any production site.
Preventing a repeat
Two controls, and the upstream one is stronger:
- Narrow the connection user so the destructive variant is outside its native capability. A ceiling you cannot misconfigure beats a permission you have to remember.
- Require approval for anything classified irreversible, so a person sees the preview before it happens.
Where an Ability supports it, a preview of what the write would do is shown before it happens. For an irreversible action that preview is the last moment anyone can change the outcome — which is a reason to keep it behind approval rather than allow.
Recovery & emergency
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.