DATA-001B — Inventory personal data and approve a minimization/retention matrix

[daliu]

Problem

MPRC currently collects or may process member identity, contact, registration, emergency-contact, date-of-birth, waiver, payment reference, shipping, Strava, WhatsApp, Google, Instagram, email, analytics, and error-monitoring data. The public privacy page is explicitly a placeholder, and there is no approved field-by-field record of why each datum is needed, who can access it, which vendor receives it, how long it remains useful, or what happens when a member requests access or deletion.

Engineering must not invent those legal, insurance, accounting, or club-policy decisions. Without an approved inventory, later retention jobs, exports, monitoring, and account deletion can either retain too much data or erase evidence the club is required to keep.

Atomic outcome

Produce an owner-approved, versioned data inventory and minimization/retention decision matrix using categories and synthetic examples only. This issue makes the decisions traceable; it does not implement deletion jobs or mutate production data.

For each data category, record:

• exact field/category and system of record;
• collection source and plain-language purpose;
• public, internal, confidential, restricted, financial, or secret classification;
• minimum roles/capabilities allowed to view or change it;
• external vendor/subprocessor and disclosure/consent requirement;
• retention trigger and approved duration, or an explicit decision pending owner;
• correction, export, deletion/anonymization, legal-hold, and backup treatment;
• named business/privacy owner and next review date.

Cover at minimum Firebase Auth/member profiles; race and merchandise records; DOB/emergency contacts; waiver evidence; Stripe references; email delivery; Google account/Site/Group data; WhatsApp number/consent; Strava identity/tokens/status; Instagram publishing; Sentry/Firebase Analytics; rate limiting; logs/audit; exports; and backups.

Acceptance criteria

• Every currently known personal-data category has a purpose, classification, system/vendor, minimum-access role, retention decision state, request behavior, owner, and review date.
• Not collected, not yet implemented, unknown, and owner decision pending are distinguished from verified current behavior.
• The approved matrix identifies data that should never appear in browser-readable profiles, logs, analytics, GitHub, support screenshots, or routine exports.
• The matrix distinguishes member-account deletion from legally required payment, accounting, waiver, incident, or audit evidence.
• Backup and external-provider deletion limitations are explicit rather than promising immediate erasure everywhere.
• A named officer/privacy owner approves the inputs and the public privacy notice has a version/effective date and truthful contact path.
• No real member record, raw email/phone/address, OAuth token, provider identifier, discount code, security finding, or private system URL is copied into this issue or repository evidence.

Dependencies and coordination

• Parent programs: ARCH-001 — Establish secure-commerce architecture and an atomic execution backlog #104 secure-platform architecture and COMMUNITY-EPIC — Unified member access and community integrations #79 community/member integrations.
• Consume MEMBERS-IDENTITY-001 — Define authoritative membership and external-account state #81's provider-neutral account/membership contract; do not redefine membership authority here.
• Wait for ARCH-001 — Establish secure-commerce architecture and an atomic execution backlog #104/PR docs: add officer continuity and secure commerce guides #108 to merge before changing its documentation paths.
• This is the owner-decision prerequisite for narrowly scoped retention, request, export, backup, and monitoring work. Publish those implementation children only after this matrix is approved.
• Existing provider tickets AUTH-004 — Link a Google identity to an existing Firebase member account #82, WHATSAPP-002 — Link a verified WhatsApp number and versioned consent to a member UID #87–INSTAGRAM-005 — Add token refresh, publishing reconciliation, and alerts #95 retain ownership of Google, WhatsApp, Strava, and Instagram mechanics.

Explicitly out of scope

• Inventing privacy/legal/insurance/accounting policy or retention periods.
• Editing production Firebase/Auth, Google, Stripe, WhatsApp, Strava, Instagram, Sentry, email, or backup data/settings.
• Implementing account deletion, retention jobs, exports, consent UI, monitoring changes, Firestore Rules, or incident response.
• Publishing real-member examples or private evidence.

Claim protocol

Creation is not a claim. Do not begin work until the issue is assigned and a timestamped CLAIMED by <canonical agent> at <UTC>; branch <branch> comment is posted and re-read. Earliest valid claim wins. Owner policy/configuration actions remain owner-only even after an engineering claim.