Intel Report 059: The Correction Cascade

SUMMARY: A correction cascade is the coordinated sequence that replaces an incorrect status, repairs its derived effects, and proves the old state is no longer authoritative. It is the reverse path that every consequential propagation system should possess.

Changing the source is the beginning of a correction, not the end. Connected systems may have copied the original status, translated it into local categories, produced derived scores, sent notifications, populated search indexes, or exported it to another organization. The correction must address each transformation rather than merely resend the new label.

One Error Creates Several Kinds of State

The first layer is the source status. The second is its direct copies. The third contains decisions calculated from those copies. The fourth contains durable artifacts: messages, reports, audit entries, and snapshots that may need annotation rather than deletion. A reliable cascade treats these layers differently.

Data lineage provides the route. Every derived record should reveal which source and version produced it. Without lineage, the correction becomes a search operation across systems that may not even use the same identifier.

Correction Events Need Identity

A correction should carry a unique event identifier, source version, superseded value, effective time, reason class, authority, and required recipient action. That identity lets operators distinguish a new correction from a replay, retry failed recipients safely, and prove which systems acknowledged the same event.

Proxy memory becomes dangerous when summaries outlive their evidence. A correction cascade should not silently erase history; it should prevent obsolete summaries from presenting themselves as current truth while preserving an accountable record of what changed.

Acknowledgment Is Not Application

A recipient can acknowledge delivery before updating its database, invalidating its cache, or rebuilding a derived score. Mature correction systems track at least three states: received, applied, and verified. The gap between them is where correction lag accumulates.

The Cascade Must End With Reconciliation

After propagation, compare the authoritative value with every consequential recipient. Recalculate derived decisions, locate systems that are offline or delayed, and test the participant’s actual route. A database comparison is useful, but service restoration is the stronger proof.

The result should be a completion record that names corrected systems, unresolved systems, artifacts annotated for history, and the time at which the old state stopped governing. This converts correction from an administrative claim into an observable systems property.

Intel assessment: a network that can distribute authority but cannot cascade a correction is optimized for enforcement, not truth.