Where we are, and what this session is not
This is not a compliance course. It does not teach you PDPA, GDPR or the EU AI Act - those have their own courses on this shelf and they are better at it. What this session teaches is the architectural half: the five design decisions that make compliance possible or impossible, all of which are made long before anybody from legal is in the room.
★ What you walk out with tonight. A count of how many places Daybreak's customer email exists, a lineage answer to "what breaks if I change this", a deletion design that would actually work, and an owner attached to every dollar on the bill.
LiveThe framing: governance is a design property, not a policy document2 min▶
Almost every governance failure you will meet is an architecture decision that was made silently and correctly according to the constraints in the room at the time. Somebody copied a table to unblock a report. Somebody granted a role because a person needed it on a Friday. Nobody wrote anything down and nothing broke.
The useful mental model: every copy of personal data is a new obligation with the same expiry date and none of the same controls. A design that produces copies faster than it produces controls is producing liability at a predictable rate, and the rate is visible on a diagram if anyone draws one.
Access at the boundary, and the copy problem behind it
7 min liveAccess control that lives on individual tables is a permanent maintenance job. Access control that lives at a boundary is a design. The difference is whether a new table inherits a rule or needs a decision.
LiveMinimization: the cheapest control is not having it4 min▶
Four moves, in order of how much trouble they save you later:
- Do not collect it. The strongest control available and the one that requires a conversation with product rather than engineering. Every field you never collect is a field you never secure, never breach, never have to delete and never have to explain.
- Tokenize at the boundary. Replace the email with a stable surrogate on the way in, and keep the mapping in exactly one vault. Downstream analytics keeps working - joins are on the token - and the PII surface stops growing on its own.
- Aggregate early. If the serving layer only ever shows revenue by SKU by day, the serving layer does not need customer rows at all. Most warehouses hold row-level personal data to answer questions nobody has ever asked.
- Expire on a schedule that runs. A retention policy that is a document is a document. A retention policy that is a job with a dashboard is a control.
The design test that catches most of it: ask what the serving layer would break if you removed every personal field from it right now. The honest answer is usually "one export that one team uses once a quarter", and that export is what is holding the whole surface open.
A customer asks to be deleted. The data is spread across 14 places, some of them immutable files in object storage.
You can delete the row in Postgres. The warehouse holds copies in six tables. The lake holds compressed files where that customer is one row inside a 400 MB object that also contains 90,000 other people, and rewriting it breaks every downstream snapshot. Somebody proposes a quarterly manual process. It runs twice.
A customer asks to be deleted. Personal fields exist in exactly one vault, and everything downstream holds a token.
You delete the vault entry. Every downstream copy is now permanently un-resolvable to a person, which is the outcome the request was asking for, and no analytical history breaks because nothing downstream ever held the email. The whole operation is one delete and an audit line.
Lineage is a design output, and the bill needs a name on it
6 min liveIf you cannot answer "what breaks if I change this" without asking three people, you do not have an architecture, you have a pile that happens to work.
LiveCost attribution, and the unowned-spend failure4 min▶
The single most reliable prediction in this field: a platform nobody is billed for is a platform nobody prunes. Storage is cheap, compute is metered, and a table that costs $40 a month and is read twice a year will sit there for a decade because deleting it is somebody's risk and keeping it is nobody's cost.
- Tag at creation, not at audit. Every asset carries an owning team from the moment it exists. Retro-tagging is a project that gets to 60 percent and stops.
- Show the number to the team, monthly. Not to finance. Teams prune their own bill when they can see it and nobody prunes on a request from central.
- Make usage visible next to cost. "$40 a month, last queried 197 days ago" is a sentence that deletes things. "$40 a month" on its own is a sentence that gets ignored.
The session 5 board says the full design costs $2,480 a month. Attribution question: which of the four teams pays which part? If the answer is "the platform budget", then in eighteen months the platform budget is the only line that has grown and the only one nobody can explain. Put the marts on the team that reads them.
Self-studyWhere the regulation actually lands on the design4 min▶
Without teaching the law, these are the four places obligations meet architecture. Each is a design decision you can make tonight.
| Obligation | The design decision it forces |
|---|---|
| Tell a person what you hold about them | You need lineage that resolves to a person. Tokenization plus one vault makes this a query rather than an investigation |
| Delete on request | Deletion must be designed in. Immutable files with mixed subjects make it structurally hard, which is a storage-layout decision |
| Limit purpose and retention | Zones and expiry jobs. A purpose that is not encoded in access is a purpose stated in a policy nobody enforces |
| Show who accessed what | Audit logging at the boundary, retained longer than the data itself. Cheap if designed, near-impossible to reconstruct |
For the obligations themselves: learn-pdpa-dnc-with-phoebe, learn-gdpr-with-phoebe and learn-data-governance-with-phoebe. This session's job is to make sure the architecture does not make them impossible.
Count Daybreak's PII surface, then shrink it
★ 22 min · everyone buildsNot a policy exercise. A counting exercise, followed by four design decisions that each remove a number of places rather than adding a number of controls.
Count the places. Every table, file, export, cache, spreadsheet and notebook where a customer email exists. Daybreak's honest count is 14, and four of them are things nobody remembered until somebody searched.
Zone it. Raw, modeled, serving. Three zones, six roles, 18 decisions instead of 252. New assets inherit rather than requiring a grant nobody remembers to ask for.
Tokenize at the boundary. The email becomes a stable token on the way in. One vault holds the mapping. Analytics never notices, because every join it does was on the identifier anyway.
Expire on a job, not on a policy. Raw events over 90 days deleted by something that runs and reports. If nobody would notice the job failing for a month, it is not a control yet.
Attribute the bill. Every asset gets an owning team at creation. Show each team their own number monthly, with a last-queried date next to it.
Do the count for real. Pick one personal field in a system you know and list every place it exists. Include the exports and the spreadsheets - especially the exports and the spreadsheets. Almost nobody's first answer is complete.
Draw your three zones. Where does raw land, where does modeled live, what does serving expose? Then check: does a brand-new table automatically fall into one, or does someone have to decide? If someone has to decide, they will forget.
Answer the deletion question honestly. If a customer asked to be deleted today, what would actually happen? Walk it through. The answer is usually a manual process nobody has run, and knowing that is worth more than a policy that says otherwise.
Now shrink the surface below. The meter starts at 14 places. Each design move removes some. The trap at the bottom is the single most common way a carefully governed platform quietly reopens.
Look at what the trap costs. One export to a spreadsheet adds two places back, and they are the two places with no access control, no expiry, no audit and no lineage. Every governance programme in the world is losing to a CSV somewhere.
Put a team name on every line of your bill. If any line says "platform", find out who reads the thing it pays for, and move it. Session 8 will ask you who is paying, and "us" is not an answer that survives.
If you take one thing from tonight. Count the copies. Not the controls - the copies. Governance conversations that start with controls produce documents, and governance conversations that start with a count produce deletions.
Before session 7
30 min- Count one field's copies. Email, phone, national ID - pick one and find every place it lives. Write the number down before you look, then after. The gap between the two is the finding.
- Walk a deletion request end to end, on paper. Do not implement anything. Just find out what would actually happen and how long it would take.
- Ask your lineage question. Pick a column and try to answer "what breaks if I change this" without asking a person. How far can you get with what exists today?
- Find one unowned cost line. Something running that nobody is billed for. Then find out when it was last read.
- Find your CSV. The export that goes out of the governed zone into a spreadsheet or a shared drive. There is one. Session 7 will make the same point about a different kind of copy.
Three questions
Clear all three and session 6 gets stamped in your passport.
1 · Why is deletion the governance property that has to be designed in rather than added later?
It is a physical layout problem, not a tooling or paperwork problem. Tokenizing at the boundary sidesteps it entirely: delete the vault entry and every downstream copy becomes permanently un-resolvable to a person, with no analytical history broken.
2 · Access is granted per table across 42 assets and 6 roles. What is the architectural problem?
A per-table grant is technically identical in strength. The problem is that it does not compose: nobody can answer "who can see emails" without reading all 252, and a new asset defaults to whatever someone remembered. A zone makes new assets inherit, so the rule survives growth.
3 · Which sentence actually gets an unused table deleted?
Cost alone gets ignored because it is small and abstract. Cost plus an owner plus a last-read date is a specific claim about one team's money for something they have not used since March, and that is the version that produces a deletion rather than a reply.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map. Certificates, videos and assessments stay with the official providers.
Session 6 cheat sheet · pin this
You have a governed platform. Session 7 puts a model in it, and everything you have learned gets tested by a component with non-deterministic latency, non-deterministic cost, an index that goes stale without telling anyone, and a loop that can decide to do more work. Plus the DORA 2025 finding worth arguing about: AI adoption raises throughput and instability at the same time.