Undo an unwanted change

The order

1. Stop the source. Pause or restrict the agent so the same request cannot repeat while you work.
2. Read the decision. Confirm the gate that allowed it. An action that should have paused points at a permission to change, not only an edit to revert.
3. Identify exactly what changed. The outcome links to the objects affected. Recover those, not everything from that time window.
4. Reverse what is reversible, using WordPress’ own recovery paths.
5. Narrow the permission before returning the agent to service.
6. Verify both sides — the content state, and a decision record that explains why it will not recur.

Use WordPress’ own recovery

Revisions, trash, and restores all apply normally. The plugin governs requests; it does not replace WordPress’ content history, and it does not keep a parallel copy of your content.

Recover narrowly

The temptation during an incident is to restore the whole site to this morning. That undoes everyone else’s legitimate work as well, and it destroys the audit chain you will want during the review.

Because the evidence names the specific objects, you can nearly always avoid that. Use the broad restore only when the record shows the change was genuinely broad.

Do not skip step five

Related guides

• RecoveryWhen an action cannot be undone

  Reversibility is a property of the action, known in advance from its classification. What to do when there is no undo, and how to avoid a repeat.

• EvidenceRead the request evidence

  Identity, Ability, context, decision and outcome — the five things every evidence record carries, and how to read one without needing the agent’s source code.

• RecoveryReturn to normal after an incident

  A checklist for coming out of an emergency mode: change the cause first, verify the controls, then restore service — and write down what you changed.