The Gate That Also Disables the Undo

A blanket rule is only as safe as the most unusual thing it covers.

In orchestration, the most unusual thing it covers is the plan whose entire job is to undo the other plans.

The Mechanism, in Three Moves

Move one: a suppression gate stops journeys from running. An order commits, and its provisioning is skipped. Bad, but not fatal — there is a recovery path, and the recovery path is to cancel the order and place it again.

Move two: cancelling spawns a rollback plan. That plan is spawned by lookup, from an item inside the parent plan. It is not entered independently. It hangs off the thing it is there to clean up.

Move three: the parent is suppressed. So the item that spawns the rollback never runs. So the rollback never exists.

The compensating action is suppressed along with the action it compensates, by the same clause, for the same reason, and with the same correctness.

What is left behind is an orphaned Contract from the cancelled order. It stays there. Permanently. There is no mechanism in the system capable of removing it — not a slow one, not a manual one, not a batch someone runs on Fridays. The remedy for the damage was itself part of the guarded population.

Why This Is Not a Coding Error

The requirement said: stop these journeys from running.

Read that sentence again and try to find the mistake in it. There isn't one. It is a clear requirement, it names a real risk, and applying it uniformly to everything that runs is the disciplined reading — the one a good engineer gives it, the one that avoids arbitrary exceptions.

It is correct right up to the point where one of the things that runs exists specifically to undo the others.

That is the whole failure. A blanket suppression treats its population as homogeneous, and orchestration populations are not homogeneous. They contain two species of plan that look identical in configuration and are opposite in purpose.

Nobody classified them before deciding what the gate covers. That step does not appear in any requirement template I have seen, which is why this is a design-review finding and not a bug someone should have noticed.

Acting Plans and Compensating Plans

The distinction worth carrying into every suppression review:

An acting plan changes the customer's world forward. It provisions, it bills, it ships, it activates. Suppressing it is the point of the gate.

A compensating plan returns the world to a previous state. Rollback, cancellation cleanup, reversal, amend-back. It exists because acting plans can go wrong.

Gate the first. Never the second.

Because the arithmetic of gating a compensation is not "one more thing stopped." It is a change of category in the resulting state. Before the gate, a bad outcome is recoverable. After the gate, the same bad outcome is permanent, and nothing else about the system changed.

A gate that also disables the undo converts a recoverable state into a permanent one.

The Part That Makes It Expensive

The recovery path will still be documented as available.

Nothing was deleted. The rollback plan is configured. It appears in the design, in the wiki, in whatever runbook the support team keeps. Somebody looking for the answer to "what do we do if an order commits without provisioning?" will find a real, correct, currently-deployed answer.

They will follow it. It will not run. And there will be no error, because a plan that was never instantiated does not report a failure — it reports nothing at all.

So the cost lands twice: once as the permanent orphan, and once as the time spent by whoever trusted the documented remedy. On paper the recovery exists. That is exactly why nobody re-checks it during the window when it does not.

How to Review a Suppression Requirement

Before you look at the condition, split the population.

• List every plan the gate will cover and label each one acting or compensating. Labels only, no analysis yet. If a plan's name contains rollback, cancel, reverse, amend or revert, it is a candidate for the second column and needs an explicit decision, in writing, about whether the gate applies to it.
• For every compensating plan, ask how it is spawned. If it is spawned by lookup from an item in the plan it compensates, it inherits its parent's fate automatically — gating the parent gates it, and no separate clause is needed to make that happen. That inheritance is invisible in the requirement and invisible in the configuration diff.
• Then ask what the documented recovery for this feature is, and whether it survives the gate. This is the question that turns a design review into a severity conversation, because the answer changes the outcome from "temporary gap" to "permanent record with no remover."

Three questions, no environment, no test data.

Why It Escapes Normal Testing

Because testing a suppression feature means proving that things did not happen, and the rollback not happening looks exactly like success.

You submit an order during the window. You check that the journeys did not run. They did not. Pass.

The absence you should have been looking for is one level further out and only appears after a second event — a cancellation that nobody performs during the suppression test, because cancelling is not part of the feature under test. The defect lives in the interaction between the gate and the remedy, and remedies are not in scope for the thing they remedy.

Which is a general shape worth keeping. When a feature restricts behaviour, test the recovery path under the restriction, not just the restriction. The restriction is what was built. The recovery is what everyone will be relying on the day it matters.

In the last blocking feature you signed off, was the rollback inside the blocked population — and did anyone decide that on purpose?