Lesson 35: Warehouse Data Residency, Deletion SLAs, and PII Minimization for Cross-Border RPG Live-Ops

Lesson 34 made replication observable. This lesson answers what legal and trust reviewers ask next: which copy of the facts is lawfully stored where, what happens when a player deletes an account, and whether your warehouse still carries personally identifying fields you forgot from early telemetry experiments.

You are not filing lawyer work here. You are producing engineering artifacts counsel can bless: a residency map, a deletion SLA matrix, and a PII inventory that plugs into the service accounts from Lesson 32.

What you will build

By the end of this lesson, you will have:

1. A warehouse_residency_map.md listing regions of write, each replica, and which player markets feed them
2. A deletion_sla_matrix.md with maximum hours to remove or irreversibly hash player-linked rows per jurisdiction tier you actually ship
3. A pii_inventory.csv classifying columns as forbidden, hashed only, or aggregated OK across facts and views
4. A replication addendum forbidding failover copies from landing PII in lower-protection regions without explicit policy flag

Step 1 - Separate telemetry PII from warehouse facts

Most PII leaks are not malice. They are schema drift:

• early builds logged e-mail or device advertising IDs into JSON blobs ingested in Lesson 31
• someone joined those blobs to dim_player for a one-off dashboard and never dropped the join

Rule: facts that power executive stability views may carry only stable surrogate keys and coarse geo, not raw contact fields.

Step 2 - Write the residency map as a table, not a paragraph

Minimum columns:

If a cell says “worldwide,” rewrite it. Worldwide is not a region.

Step 3 - Deletion SLAs that operations can execute

For each player-rights tier your studio acknowledges (labels only, not legal advice):

1. detection time — how you learn a deletion request is real
2. execution time — when warehouse rows must be gone or hashed
3. proof artifact — export log ID or job name stored beside Lesson 28 briefing evidence

Tie SLA breach to yellow ship posture in the same language as analytics confidence from Lesson 26.

Step 4 - Build pii_inventory.csv

Columns:

• table_or_view
• column
• classification (forbidden / hash_only / aggregate_ok)
• replacement_strategy (salted hash with rotation, bucketing, drop)
• last_verified_by

Anything forbidden in a replica region stricter than the write region gets a migration ticket, not a silent ALTER.

Step 5 - Patch the Lesson 34 failover runbook

Add a pre-flight row before connection string flips:

• confirm the failover region’s PII class is not weaker than source
• if weaker, block failover until views are scrubbed or policy updated

This keeps infra heroes from accidentally solving uptime by violating residency promises.

Step 6 - Budget and compliance handshake

Cross-check that scrub jobs and extra hashing do not blow Lesson 33 cold-path budgets. Deletion waves are bursty; schedule them like any other heavy scan.

Mini challenge

1. Add one forbidden column you find in a legacy JSON ingest to pii_inventory.csv with a drop plan.
2. Fill one row of deletion_sla_matrix.md with numeric hours, not adjectives.
3. Add the failover pre-flight row to your Lesson 34 runbook file.

FAQ

Do we need separate warehouses per country?

Usually no. You need clear legal labels, contracts, and technical controls on where copies live and who can query them.

What about hashed IDs forever?

Hashing is fine if rotation and salt policy exist. “Forever” hashes still need documentation for player transparency.

Should marketing analytics share this warehouse?

Default no. If they must, duplicate classification work; do not inherit trust by folder name.

Who signs warehouse_residency_map.md?

Product plus infra plus whoever owns external counsel intake. Engineering owns accuracy; exec owns risk acceptance.

Lesson recap

You can now:

• stop PII from hiding inside early JSON telemetry
• describe residency and replicas in a form legal partners can review quickly
• tie deletion work to operational SLAs and ship-confidence colors
• block naive failover that trades uptime for policy violations

Next lesson teaser

Continue with Lesson 36: Vendor DPA Checklist Mapping for Cloud Products Touching RPG Metrics Warehouses to map processor coverage, renewal ownership, and release flags across ingest, storage, BI, and support surfaces.

Related learning

• Lesson 34: Cross-Region Read Replica Lag and Failover Read Paths
• Lesson 33: Warehouse Query Budgets and Cost Guardrails
• Lesson 25: Final AI Dialogue Release Sign-Off Checklist — complementary “what we promise players” framing for data handling narratives.

If this lesson stopped a replication project from becoming a subpoena-shaped object, store the residency map beside your Lesson 21 launch control references so go or no-go reviews include data posture, not only crash rates.