Vision proposal: maintained structured registry of privacy regulations per jurisdiction

[mazzasaverio]

Vision proposal: a maintained, structured registry of privacy regulations per jurisdiction

Second vision-level proposal (companion to the language-coverage one). The idea: keep a structured, dated, source-linked registry of the regulations that matter for this package (GDPR, EU AI Act, EDPB guidelines, national laws, US state laws, LGPD, etc.) inside the repo, continuously maintained, so that both the code and the people using the package stay aligned with the legal reality.

Why in the repo

• Users adopt this package because of regulation, but today the legal context lives in scattered blog posts. A curated registry next to the code is a real differentiator and a natural documentation entry point.
• Regulation moves (example: EDPB Guidelines 02/2026 on anonymisation, in public consultation until October 2026, explicitly note that AI lowers re-identification cost). When it moves, both docs (e.g. docs/security.md wording on pseudonymization vs anonymization) and possibly code defaults should follow. A registry with review dates makes that drift visible instead of silent.

Proposed shape

• docs/regulations/ with one structured file per jurisdiction (machine-readable YAML or JSON front matter + rendered markdown), each entry carrying:
  • jurisdiction and instrument (e.g. EU / GDPR, EU / AI Act, IT / L.132-2025, US-CA / CPRA, BR / LGPD);
  • what it says that is relevant to this package (pseudonymization definition, anonymization threshold, obligations when sending data to third-party AI services);
  • key articles/recitals with primary-source links;
  • dates: in force, applicable, last amended;
  • last_reviewed date and a review_by deadline;
  • status of pending items (consultations, drafts) marked as such.
• Staleness check in CI: a small script that fails (or warns) when an entry is past its review_by date, so the registry cannot silently rot. Reviews are cheap: confirm or update, bump the date, cite sources.
• Contribution rule: registry PRs must cite primary sources (official journals, regulator websites), not press coverage.
• A prominent disclaimer: this is engineering documentation to keep code and users oriented, not legal advice.

Alignment with code

Where the registry states something actionable, the code and docs should reference it explicitly. Examples: the pseudonymization-is-not-anonymization wording in README/docs can cite the registry entry; jurisdiction-oriented policy presets (or just documented recipes, e.g. "GDPR-cautious configuration") can point to the entries they derive from. Registry first, code alignment as a consequence.

Scope control (so this stays maintainable)

Start small: EU (GDPR + AI Act + EDPB guidelines) and Italy, since that is where we can actually review competently, then grow jurisdiction by jurisdiction via community PRs under the sources rule. An entry we cannot review on schedule gets marked stale by CI rather than pretending to be current.

If the direction sounds right, I would start with the entry schema + the EU/IT entries + the CI staleness check as a first PR.

[mazzasaverio]

Follow-up, and this time raising the objection myself: after re-reading VISION.md, this proposal sits closer to a stated boundary than I acknowledged when filing it.

The vision says explicitly:

Pseudonymization does not guarantee anonymization, complete PII detection, regulatory compliance, or immunity from contextual re-identification.

and the roadmap requires that proposals outside the committed scope "show that they fit the layer boundaries". A regulation registry inside the repo could reasonably be read as drifting toward the compliance territory the project deliberately refuses, and the risk is not theoretical: users tend to read "there is a GDPR section in the repo" as "this package makes me GDPR compliant", which is exactly the misunderstanding the vision guards against.

So the honest framing of the decision is a fork in the road, and it is yours:

1. Reject, on the grounds that legal context belongs outside the codebase. Perfectly defensible; in that case I would still suggest a single short docs page listing the disclaimer plus links to primary sources, with no maintained registry and no schema.
2. Accept in a deliberately narrowed form: the registry documents only what changes engineering decisions (definitions of pseudonymization vs anonymization, what regulators say about sending data to third-party AI services, re-identification thresholds), never obligations, checklists, or anything resembling advice. Every entry carries the boundary text above, and no entry ever claims a configuration "makes you compliant".

If you take option 2, I would add one rule to what I proposed: the registry must never be referenced from marketing-shaped material (README claims), only from docs/, so it stays a maintenance tool rather than a selling point.

I lean toward option 2 narrowed as described, because the anonymization threshold genuinely is moving (EDPB Guidelines 02/2026, in public consultation until 30 October 2026, note that AI lowers re-identification cost) and that movement affects wording the package already ships. But option 1 is a legitimate call and I would not argue with it.