Notifying Every Branch Office of a Correction

Opening Scene

The registry corrects a citizen’s address on file — a genuine, verified fix. If that’s where the story ends, the correction has accomplished nothing. The tax office is still mailing notices to the old address. The utilities office is still routing service requests there too. The correction only matters once a bulletin goes out to every office that keeps a working copy, telling each of them to refresh their local record before their next action depends on it. A registry that’s excellent at reconciling records but slow or unreliable at broadcasting corrections is, in practice, barely better than one with no reconciliation at all.

In Plain English

Propagation is the process of distributing golden record updates — new values, merges, corrections — out to every downstream system of reference that consumes that master data, keeping their local copies aligned with the authoritative source. This is the operational payoff of everything covered so far: matching, survivorship, and stewardship all exist to produce a correct golden record, but the correction only creates real business value once it reaches the systems that actually act on it — the billing system that sends the invoice, the fulfillment system that ships to the address, the marketing system that respects the updated consent preference.

The Old Way

Propagation has always come with real design tradeoffs, independent of any specific technology:

Batch propagation trades timeliness for simplicity — periodically pushing a full or incremental update to every downstream system on a schedule (nightly, hourly) is easier to build and reason about, but it means every system of reference is, by design, at least somewhat stale between refresh cycles.
Event-driven propagation trades complexity for immediacy — publishing a change event the moment a golden record updates, consumed by downstream systems in near real time, keeps systems of reference much fresher, at the cost of a more complex integration architecture that has to handle delivery reliability, ordering, and downstream failure gracefully.
Selective propagation is often necessary and easy to get wrong — not every downstream system needs every field, and pushing irrelevant updates to systems that don’t need them wastes effort and can even introduce risk, if a system that shouldn’t receive sensitive fields ends up receiving them anyway through an overly broad propagation rule.

Neither batch nor event-driven propagation is universally correct — the right choice depends on how quickly downstream systems genuinely need to reflect a change, a question Article 18 returns to directly when contrasting real-time and batch MDM more broadly.

What’s Changing (and Why AI Is the Reason)

AI-assisted impact analysis can predict which downstream systems and processes a given golden record change is likely to affect meaningfully, helping propagation prioritize the updates most likely to matter rather than treating every change as equally urgent. A minor formatting correction and a legal-name change don’t carry the same downstream urgency, and AI-assisted analysis can help propagation reflect that difference.
AI agents that consume master data increasingly need to know not just the current golden record value but also that it recently changed, since an agent mid-workflow with a stale cached value can produce a materially wrong outcome — AI-aware propagation increasingly includes explicit change signals, not just updated values, specifically so consuming agents can react appropriately.
AI-assisted monitoring can detect propagation failures — a downstream system that silently stopped receiving updates, for instance — faster than traditional integration monitoring, by learning the normal update cadence for each downstream consumer and flagging anomalies against that learned baseline.

The Metaphor, Fully Extended

Registry Element	Master Data Management Concept
A bulletin sent out after a citizen’s file is corrected	A propagation event distributing a golden record update downstream
A scheduled weekly mail run to every branch office with accumulated corrections	Batch propagation, trading timeliness for architectural simplicity
An urgent same-day courier for a critical correction	Event-driven propagation, trading complexity for immediacy
Sending only the relevant page of a citizen’s file to an office that only needs that page	Selective propagation, sending only the fields a given downstream system actually needs
A registry assistant flagging which offices a specific correction is actually likely to matter to	AI-assisted impact analysis, prioritizing propagation by likely downstream significance

For Beginners: What to Actually Do

Whenever you look at data in a downstream system, ask how and how often it’s refreshed from its source — the answer tells you how much staleness risk that data carries.
Practice distinguishing batch and event-driven propagation as a deliberate architectural choice, not a technical detail — each implies a different tolerance for staleness that should match the use case.
Notice when a downstream system seems to be receiving more master data fields than it actually needs — that’s often a sign of unrefined, overly broad propagation rather than a deliberate choice.
Get in the habit of checking “when was this record last refreshed from source?” before trusting a downstream copy for anything time-sensitive.

For Practitioners and Leaders: The Deeper Layer

Choose batch versus event-driven propagation per downstream consumer based on genuine business need for freshness, not by defaulting to whichever pattern your existing infrastructure already supports.
Build selective propagation deliberately, scoping which fields each downstream system receives, both to reduce noise and to limit the blast radius of any sensitive field being exposed unnecessarily.
Instrument propagation pipelines with monitoring that can detect silent failures, since a downstream system that quietly stops receiving updates often goes unnoticed until a much more visible failure occurs downstream of that.
Design propagation events to carry explicit change context, not just updated values, so both human-built integrations and AI agents consuming the data can react appropriately to what specifically changed.

Quick Recap

Propagation distributes golden record updates to every downstream system of reference, and it’s where reconciliation work actually converts into real business value.
Batch propagation favors simplicity at the cost of staleness; event-driven propagation favors freshness at the cost of architectural complexity; selective propagation limits updates to what each consumer actually needs.
AI-assisted impact analysis can prioritize propagation by likely downstream significance, and AI-assisted monitoring can catch silent propagation failures faster than traditional approaches.
AI agents consuming master data benefit from explicit change signals, not just updated values, to react appropriately mid-workflow.

Where This Fits in the Series

Article 10 covered how corrections get made; this article covered how they reach the systems that depend on them. Article 12 addresses a related operational risk: handling merges, and un-merges, safely when a match turns out to be wrong.