A replication payload carries a residency tag that vanishes once the job crosses the first availability zone. The destination bucket now stores the records under a policy that never enforced the original boundary.
Cloud orchestration layers treat the tag as optional metadata rather than a hard constraint on write operations. Once stripped, downstream services inherit no obligation to check jurisdiction before serving or further copying the data.
Procurement teams accept region lists in vendor proposals without demanding that every replication path carry the same tag through the entire pipeline. The result is production traffic that satisfies uptime targets while violating residency rules the contract claimed to honour.
Security reviews conducted after code merge never see the stripped tag because test environments run inside a single region. The failure only appears when the same job hits the multi-region mesh that actually ships the product.
Data residency therefore becomes a delivery constraint only when the replication configuration itself is version-controlled and tested under cross-region load before any production cut-over.
Vendors will not add this check unless the buyer withholds final payment until the log shows every payload retaining its tag at the target edge. Without that gate the marker remains cosmetic.
Teams that embed the check inside the replication job definition rather than relying on bucket policies keep the boundary intact even when new services attach to the same dataset.
Audit logs that record both the incoming tag and the outgoing write decision expose the exact step where enforcement collapsed. Those logs turn residency from a slide into an observable control.