Explanation¶
These pages explain why bricksgdpr is designed the way it is.
Use them when you want the reasoning behind a boundary or control. If you need to carry out a task, go to the how-to guides. If you need an exact name, default, or contract, use the reference.
Architecture and data boundaries¶
-
Architecture and trust boundaries
Why raw values, mappings, protected analytics, case views, and internal functions live in separate areas.
-
Pseudonymized data is not anonymous
Why the project consistently calls its governed data Personal Data.
-
Versioned, domain-separated keys
How canonicalization, framing, domains, and a pepper create stable keys without creating a public matching oracle.
-
Stored masks and pseudonymous joins
Why masks return stored keys and why joins never depend on masked raw columns.
Operations and assurance¶
-
Quarantine instead of silent dropping
Why rejected rows stay observable and why one deterministic reason wins.
-
Terminal deletion versus physical erasure
What the demo removes from current governed outputs—and what it cannot erase by itself.
-
Case views and least privilege
Why readable values reappear only through four narrow, fail-closed views.
-
Why a successful model build is not enough without metadata and denial checks.
-
Demo and production boundaries
Which lessons transfer to production and which controls still need real system integration.
This is an engineering demonstration
bricksgdpr demonstrates selected technical controls. It is not legal advice, a complete GDPR control framework, or evidence that a deployment is compliant.