Requirements traceability + privacy by design
The C4 model answers how it fits together and why; the Requirements section answers what we build and how we know it's done. This page is the call-out layer between them: which C4 elements satisfy which MVP-1 requirement epics, plus the cross-cutting privacy & data-protection-by-design posture (GDPR / CCPA-ready) that the architecture must keep feasible even though it is not an MVP-1/2 feature.
C4 element → requirement epics
| C4 element | Requirement epics it satisfies |
|---|---|
| L2 Container — Flutter app (blocs / pages / auto_route, DS atoms) | Today · Onboarding · Member Profile · Catalog · Household · Routines · Visual timers · Settings · Print · Admin · Notifications (local) · Accessibility floor |
L2 Container — client_sdk (facade → services → adapters → models) | Money & Envelopes · Personas / authz · Offline sync · Account · Analytics |
| L2 Container — Supabase (Postgres + RLS + Auth + Storage + Edge Functions) | Security · Account · COPPA (consent records) · Terms & consent · Offline sync (cloud) |
L3 Component — TodayChoresBloc / TodayChoreRow | Today |
L3 Component — LedgerService / EconomyService | Money & Envelopes · Catalog (redeem) · Admin (economy) |
L3 Component — HouseholdService (kind / role / owner / status) | Personas / authz · Household · Admin · COPPA (consent gate) |
L3 Component — ApprovalService (single earn path) | Today (completion) · Routines |
L4 Code — append-only LedgerEntry + zero-floor | Money · Security (integrity) · Offline sync (replay) |
| Cross-cutting — Auth & sessions | Account · Personas / authz · Terms & consent · COPPA · Security |
| Cross-cutting — Observability | Analytics & telemetry (the three-bucket model) |
| Cross-cutting — Infrastructure | Security · Offline sync · Account |
Cross-cutting — Design system (one DsTheme) | Accessibility floor · Visual timers · every frontend epic |
L3 Component — AchievementsCubit + StreakProjection + TimelineBloc / timeline repos (engagement projections, Wave-1 A3 / Wave-2 A4–A5) | Engagement / motivation requirement — PURE PROJECTIONS: derived read-only views over existing facade reads, zero new storage tables or columns |
L3 Component — child-link RPC + expire-pending-children Edge Function + pendingConsent RLS freeze | COPPA (child self-signup consent) — the shipped pendingConsent substrate gates a child's account until a parental consent token is presented; the expire Edge Function prunes stale pending-consent records on schedule |
Non-functional bars are gates, not boxes. Security, COPPA, the accessibility floor, and the authz model are not satisfied by one container — they are cross-cutting invariants every relevant element must uphold (household-scoped RLS, the consent gate, the a11y floor in every atom).
Privacy & data-protection by design (GDPR / CCPA-ready)
Acknowledged at the architecture level — not an MVP-1/2 feature. Full GDPR (the Privacy & GDPR feature) is deferred to a pre-EU launch, but CCPA / CPRA pulls equivalent data-subject rights forward for the US launch, so the architecture must keep them feasible from day one rather than retrofitting later.
Data-subject-rights primitives the architecture preserves:
- Access / portability — household + member data is reconstructable per subject from the SDK aggregates; an export path is additive, not a re-architecture.
- Erasure / deletion — the COPPA child-deletion + account-deletion paths are the same primitive a CCPA/GDPR erasure request needs; built once, reused.
- Consent provenance — the Terms & consent consent records (who consented, to what version, when) are the audit substrate for data-subject and parental-consent requests alike.
- Data minimization — already a COPPA control + the three-bucket analytics model; the smaller the PII surface, the cheaper every right is to honor.
The load-bearing tension — append-only ledger vs. the right to erasure. The ledger is immutable (an integrity invariant), but erasure requires removing a person's PII. Resolution direction (a forward decision, not MVP-1 work):
- Keep PII out of the ledger. Ledger rows reference an opaque member id, never a name/contact — so erasing a person never touches a value row.
- Erase by de-identification, not deletion. Honor erasure via crypto-shredding / pseudonymization of the member's PII record + tombstoning the identity, while the ledger's value rows (and household balances) stay consistent. Both the append-only invariant and the right to erasure hold.
Data residency is the remaining forward item — EU residency for GDPR vs. the current US/CA Supabase region — tracked with the post-MVP architecture decisions and the Security epic.
Not legal advice — these are launch gates; counsel signs off (esp. the 2025 FTC COPPA amendments and US state minor-privacy laws). See the COPPA requirements.