Here is the complete final issue with that last revision included.

Why AI actions need recovery paths, not just approval.

Before I let a pipeline write to production, I ask one question.

Can I put it back?

I learned to ask that question early, because once the write has happened, the available options are already narrower.

Last issue was about the check before the action: the approval point where a person decides whether the system should be allowed to act. That check matters, but it is easy to treat approval as the finish line.

It is not.

Approval reduces risk. It does not make an action safe.

A person can approve an action based on valid information, and the action can still produce the wrong result. The data may change between review and execution. The scope may be wider than expected. An operation can succeed technically while creating a result the business cannot accept.

None of this necessarily means the approval was careless. It means approval was never the whole design.

Once an AI system can change a real system, recovery has to be designed before the action is allowed. It cannot begin with an incident runbook written after the first failure.

Before the system changes a record, permission, configuration, or workflow, it needs to preserve enough context to understand what existed before the change.

In a data pipeline, that might mean retaining the previous values, the affected record set, the version of the input, the batch identifier, or the source offsets used during processing.

For a configuration change, it may mean preserving the prior version and the exact scope of the deployment.

I have seen teams point to their logs and assume recovery is covered.

Usually, they have half of it.

An audit log tells you what happened. A recovery record preserves the information needed to decide what response is still possible.

Those are different artifacts.

The audit log supports review. It helps establish who initiated an action, when it happened, and what the system reported.

The recovery record supports restoration. It gives the engineer evidence about the state that existed before the action changed it.

A log might say that a job updated 40,000 rows.

A recovery record identifies those rows and preserves the values required to restore them.

One helps me explain what happened. The other gives me something concrete to recover from.

When the before-state has not been captured, direct reversal may already be unsafe. The team may still be able to compensate for the action or restore a checkpoint, but it is no longer returning to a known state based on evidence.

It is estimating.

Not every action supports the same type of recovery.

A reversal restores the previous state directly.

A compensating action creates a new change that offsets the original one.

Checkpoint recovery returns the system to an earlier stable state.

The right mechanism depends on what the system changed.

A database update may be reversible when the previous values were retained and no conflicting writes occurred afterward.

An email cannot be reversed. Once it has left the system, the available response is compensation: a correction, a follow-up, or a separate intervention.

A destructive transformation across a large dataset may be technically reversible row by row, but doing so could introduce more risk than restoring a known checkpoint and replaying the valid work.

The recovery design also has to account for time.

A reversal that is safe immediately after an action may become unsafe after downstream systems have consumed the result. Restoring one table does not automatically restore every decision made from that table.

This is why “we can roll it back” is not a plan.

Rollback describes one recovery mechanism. It does not establish that the mechanism applies, that the necessary state was preserved, or that the effects are still contained.

The recovery path needs to be known before the action begins.

Recovery is another action.

A recovery attempt uses permissions and changes state just like the original action. It can be wrong for many of the same reasons.

An AI system should not automatically correct every mistake it detects simply because a recovery mechanism exists. Automatic recovery is appropriate only when the path is bounded, deterministic, and verifiable.

When the original state is uncertain, the system should stop.

The same applies when the effects have crossed a boundary the system cannot control. A payment may have been initiated. A customer may have received a message. Another pipeline may already be processing the result.

There are also situations where several recovery paths are technically valid, but choosing between them requires business judgment.

Restoring a checkpoint might remove legitimate work. Compensation might preserve that work while creating a second set of consequences.

The system may recognize that the result is wrong without understanding why it became wrong.

That is not a signal to take more action.

Uncertainty should reduce autonomy, not trigger more of it.

A system that responds to its own mistake by taking a larger, faster, or less understood action has not recovered.

It has escalated the incident.

Teams often skip this part because the action works during the demonstration. The approval step exists, so the workflow appears governed. Recovery feels like an operational detail that can be added later.

It stops feeling like a detail the first time an approved action produces the wrong result.

A trustworthy system is not one that never makes a mistake.

It remembers what changed and knows when to stop.

The action I worry about most is the one nobody planned to undo.