How should the correction, withdrawal or invalidation of an…

Direct answer

First inventory every direct and indirect downstream target that uses the decision. Send the correction as a unique, idempotent event. Each target produces evidence of receipt, application and an independent read-back of the current state. For critical targets, test real behaviour rather than field equality alone. An unreachable or external target is not complete; keep it open with an owner and retry route.

In plain language

Imagine correcting your address at a hospital. It is not enough for reception to say, 'I sent the change.' You must check that the laboratory, pharmacy and billing system actually use the new address.

Why this matters

If an old decision survives in one cache, export or connected application, the person may still encounter the wrong outcome. Partial propagation recreates an error that appears to have been corrected.

Do not confuse

A receipt confirms that the event reached the target; an application acknowledgement confirms that the change was processed.
Read-back means independently reading the target's current state.
Field equality tests the same value, semantic equivalence tests the same meaning, and behavioural equivalence tests the correct action.
A direct target receives the decision first; an indirect target is affected through another target.
An external target may be outside direct control; that limitation cannot be hidden by marking it complete.

What should you do?

Inventory every direct, indirect, cache, export, report and third-party target that receives the decision.
Assign each target a criticality, owner, expected update and verification method.
Publish a unique, versioned, orderable and idempotent correction or withdrawal event.
Collect receipt and application acknowledgements with the decision identifier and target version.
Read the target state back independently and test convergence in fields, meaning and critical behaviour.
Manage failed, delayed and external targets with an open status, owner and retry date.
Do not declare propagation complete until every required target is verified.

How do you audit it?

Are all direct and indirect targets really present in the inventory?
Is the event unique, versioned, orderable and safe to apply more than once?
Were receipt and application distinguished?
Was the current state read back independently from the target system?
Does a critical target behave correctly, or does only its field value match?
Were failed or external targets closed as though complete?
Can a downstream system recreate the old decision later?

Limit

An organisation cannot guarantee when a third party outside its control will update. It can notify, retain evidence, retry and monitor; unverified convergence must remain explicitly UNRESOLVED.