Evidence
Outcome unverified
Unverified is not the same as failed. In practice it most often means the action succeeded and the confirmation did not.
- Activity & evidence
- 4 min read
Check the target directly
Open the object the request named and look at it. This resolves the question faster than any amount of log reading, and it is the only check that tells you the actual state rather than what was reported.
Then read the linked evidence
The activity record shows how far execution got and what was captured. Between that and the object itself you can nearly always establish whether the change landed.
Verify the audit chain as well. A verification failure is a different problem from an unverified outcome, and it needs its own attention.
Provider support varies
Some Abilities return richer evidence than others. Where a provider returns less, the record says the outcome is unverified rather than inferring a result it cannot confirm.
Recording an assumed success would make the audit trail wrong in exactly the situation where it most needs to be right.
Do not retry blind
Establish the state first. If the action did land, a retry creates a second one. If the Ability is bulk-capable, it creates a second set.
If you genuinely must retry, do it through the governed path so the second attempt is recorded too — not by working around the plugin.
Activity & evidence
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.