Regulatory & privacy

The Children's Code is 15 standards, statutory under the Data Protection Act 2018. Compliance is not optional for any "information society service likely to be accessed by children" in the UK market. The headline duties: best interests of the child (Std 1); DPIA required (Std 2); age-appropriate application (Std 3) — different protections by age band, cannot apply without knowing age; default to high privacy (Std 7); no nudge towards weaker settings (Std 13); transparency (Std 4).

SHOTid's design today violates Standard 7 directly: every locked identity goes into public_profiles readable by anon the moment lock-in fires. Standard 13: the founder cohort cap of 5,000 and the FOMO framing of registration are precisely the patterns the code targets.

Three flows must be reconciled before launch:

• The locked profile row. Currently the only override path is bumping identity_lock_version, which is an admin escalation. Fine for "I want a different handle"; wrong for "I am exercising my Art. 17 right." Erasure should be a privacy-by-design path, not an admin escalation.
• The issued credential. Once a W3C VC sits in a Sport Head's wallet, it is outside our control. We cannot recall it. The honest mechanism is a revocation registry — the VC keeps existing but reads as revoked when any verifier checks status. The W3C-recommended pattern is Bitstring Status List v1.0 (the successor to Status List 2021). Publish a bitmap; the credential carries an index pointer. Revoking = flipping one bit. No PII in the registry.
• The convenience caches. profiles.email exists alongside auth.users.email. There is no lawful basis for storing the same personal data twice. Erasure must clear both.

• Verifiable parental consent required before any collection of personal information from a known under-13. Methods listed in 16 CFR § 312.5; the cheap ones (KBA, credit-card micro-charge) cost real money per signup. No realistic way to ship VPC for a December launch.
• Actual-knowledge trigger: the moment a support ticket, federation flag, or self-disclosure tells SHOTid that a Sport Head is under 13, the data must be purged or VPC obtained. No "but they lied at signup" exception.
• Penalty maximum — FTC adjusts the COPPA civil-penalty maximum for inflation annually. The current cap is in the low five figures per violation (see FTC COPPA page). Per-violation, not per-incident — a breach affecting 200 under-13s is 200 violations.
• The amended COPPA Rule (2024–25) tightens third-party-disclosure rules and requires separate VPC for ad networks/analytics. Federation share counts as third-party disclosure under the strictest reading.

Realistic posture: hard age gate at signup, refuse under-13 entry globally (not just UK), maintain an actual-knowledge purge process, document the COPPA stance in the DPIA. Supporting 13–17 with VPC for the December cohort is not viable — defer until v2.

Mitigation pattern is structural: keep VC issuance identity-only. Ticketing partners run their own merchant of record, hold their own licences, take their own KYC. The credential proves "this Sport Head is who they say they are" and stops there. Anything beyond requires a non-trivial legal memo before integration ships. Bake into partner contract template now, before partner pressure makes it harder.

• Brazil — LGPD. Applies extraterritorially. Does not mandate localisation like Russia/China; ANPD has indicated localisation expectations for "high-risk" sector use cases. 100k+ Brazilian Sport Heads will get the ANPD's attention by year two.
• Sierra Leone — Personal Data Protection Act 2022. Establishes a DPA, consent-based processing, GDPR-derived cross-border transfer regime. Does not mandate localisation; does require local representation if processing affects SL residents from outside. SLFA's expectations may outpace the statute around the December launch.
• Nigeria — NDPA 2023. Similar GDPR-derived structure. NDPC more active than its statute suggests. Diaspora-heavy West African Sport Heads will cross-trigger UK + NDPA + LGPD on a single profile.
• Italy — Garante. Most aggressive EU DPA. First to ban ChatGPT temporarily, first to challenge Meta's AI-training basis. An Italian-locale identity product without a clear DPIA is a poke at the Garante.

The architectural fork is now. Either commit to single-region with federation data lakes that materialise locally (cheap, conflicts with sovereignty rhetoric), or per-federation tenancy with regional Supabase projects (expensive, conflicts with ADR-0006's "no privileged data path"). Write ADR-0007 before more federations come online.

Under UK GDPR Art. 4(1), personal data is "any information relating to an identified or identifiable natural person." The ICO's standing position is that identifiability includes data that, alone or combined with other reasonably-available information, identifies an individual. public_profiles fails this on three vectors:

• Avatar + sport + region is a quasi-identifier. A unique avatar state hash, plus "boxing in Sierra Leone", plus handle + founder number narrows the population to single digits.
• Federation-published rosters are the side channel. SLFA already publishes member lists. Cross-referencing handle + sport + country gives full re-identification.
• Founder number is a tiny set. 5,000 numbered identities is small enough that any side channel (tweet, press photo, wedding announcement) closes the gap.

The "public" framing is a product decision, not a legal one. Defaults must be private. Locked Sport Heads opt in explicitly to public_profiles exposure after lock-in, in plain language. For minors (§01) the option must not even be offered.

• By design, a caller with no credentials maps a public handle to the recovery email of the human behind it. Email is personal data under UK GDPR / DPA 2018. The mapping is disclosed to "any third party" the moment they call the RPC. Disclosure without lawful basis (Art. 6).
• Notification obligation: the moment the team has reasonable grounds to believe attackers have harvested at scale, Art. 33 requires ICO notification within 72 hours; Art. 34 requires user notification "without undue delay" for high-risk breaches. A handle-to-email oracle hits both.
• Cost of a notification event, independent of any fine: external counsel for the regulator submission, ICO incident manager assigned for months, mandatory remediation report, possible audit, brand damage at exactly the moment of launch. Six-figure all-in is conservative.
• The fix is not "rate-limit at Supabase auth" as the migration comment suggests. The fix is to never return the email. Replace with a sign-in RPC that takes handle + PIN and returns a session token (or error). The OIDC issuer path in ADR-0006 already implies this; build that, then drop the migration.

The DPIA the team has not written needs to contain, at minimum:

• Description of processing. Re-use the architecture data-flow map.
• Necessity and proportionality. For each data point — country, locale, geo unit, PIN, email — justify why it is necessary. The duplicate profiles.email cache fails this test as written.
• Risk register. Re-use the security-posture page's findings.
• Mitigations. What's being done, when, by whom. Without dates this section is theatre.
• Consultation. Children's representative consultation is expected for any service in the Code's scope.
• Residual risk. If residual risk is high after mitigations, Art. 36 requires prior consultation with the ICO before processing begins. Lead time: 8–14 weeks. The December cohort cannot wait that out unless the DPIA starts in the next two weeks.