Decide pre-cohort CourseInterest identity and retention

[alexeygrigorev]

Decision outcome

Choose one complete identity, deduplication, retention, and privacy contract for interest in a reusable Course before any Cohort exists. This issue is a decision gate only: filing or recommending an option does not approve it, create implementation authority, or make a nullable-Cohort CourseRegistration valid.

Parent epic: #54. Split from #242.

Normative authority and exact gap

• _docs/PROCESS.md
• _docs/specs/01-platform-architecture.md, durable account and private MemberProfile ownership
• _docs/specs/04-courses-and-cohorts.md, Registration: pre-Cohort interest is CourseInterest, never CourseRegistration(cohort=NULL)
• _docs/specs/07-security-privacy-operations.md, privacy rights, full-erasure default, retention jobs, and approved 14-day unverified-record default
• _docs/specs/open-decisions.md, resolved decisions 6, 12, and 19
• _docs/architecture/app-boundaries.md, accounts owns identity/profile and courses owns course workflows
• Epic: Preserve target-native course registration, enrollment, and learner flows #54, additive registration source Migrate course registrations to immutable cohort-owned evidence #242, account/profile foundations Build the accounts-owned MemberProfile schema and service foundation #247/Add verified member-profile onboarding and cut over account settings #248, and privacy epic Epic: Implement privacy rights, retention, erasure, and propagation #64

Current authority requires a verified durable account plus completed MemberProfile for Cohort registration. It does not say whether the lighter, pre-Cohort CourseInterest must use that same profile gate or may use accountless verified email. It also assigns no exact interest dedupe key, expiry, rights behavior, or conversion boundary. Engineering must not infer those choices.

Required owner response

Reply I1, I2, or I3, or provide an equally exact replacement covering every row below.

I1 — verified durable account, no profile requirement (PM recommendation)

• Identity/profile: require an authenticated, active/eligible durable-account survivor with verified email ownership. Do not require or read MemberProfile.
• Dedupe: at most one interest per (Course, durable survivor account). Replay and concurrency return the existing record. Missing, absorbed-without-one-survivor, quarantined, inactive, or colliding identity fails closed; email changes do not create a second interest.
• Stored personal data/evidence: store only the account relation, Course relation/immutable Course identity, lifecycle timestamps/state, and versioned interest-privacy acknowledgement. Store no email/profile snapshot, comment, registration/marketing consent, or Cohort/campaign target.
• Retention: an unconverted interest expires 24 months after its creation or latest explicit member renewal. Expiry removes the account link and other personal evidence; only bounded non-PII reconciliation/aggregate evidence may remain under Epic: Implement privacy rights, retention, erasure, and propagation #64.
• Rights: include the live interest in authenticated account access/export. Withdrawal and account erasure are idempotent, stop future interest processing, remove the personal link/evidence, and propagate through the Epic: Implement privacy rights, retention, erasure, and propagation #64 tombstone/restore boundary.
• Delivery: capture sends no verification message because ownership is already verified. Any later Course-availability transactional notice requires its own approved purpose/template through the website delivery service; no marketing subscription or consent is inferred.

This is the smallest contract and avoids both unrelated profile friction and a second identity-verification system.

I2 — verified durable account plus completed MemberProfile

Use every I1 rule, including (Course, durable survivor account) uniqueness, minimized storage, 24-month renewal-based expiry, authenticated rights, erasure, and delivery boundaries, except:

• creating or renewing interest additionally requires a current, member-confirmed completed MemberProfile through the accounts-owned safe-read contract;
• no profile value or profile snapshot is copied into CourseInterest;
• later profile edits do not rewrite interest, while an unavailable/stale/unconfirmed profile blocks a new create/renew operation without deleting an existing interest.

This reuses the registration onboarding gate but adds profile work unrelated to merely asking to hear when a Course next runs.

I3 — accountless verified email

• Identity/profile: no account or MemberProfile is required. Ownership is established only by a purpose-bound, expiring, single-use verification flow; pending interest grants no course/account authority.
• Dedupe: at most one pending-or-verified interest per (Course, accounts-normalized email). Exact replay converges; normalized collisions, conflicting account claims, stale tokens, or ambiguous ownership fail closed and never pick a record.
• Stored personal data/evidence: store normalized email, Course relation/immutable identity, pending/verified/withdrawn/expired state, verification and lifecycle timestamps, and versioned interest-privacy acknowledgement. Store no profile snapshot, comment, registration/marketing consent, Cohort/campaign target, raw token, rendered message, or provider payload.
• Retention: pending records and bounded abuse metadata expire after 14 days. Verified unconverted interest expires 24 months after verification or latest explicit renewal. Expiry/withdrawal removes the email and other personal evidence; only bounded non-PII reconciliation/aggregate evidence may remain under Epic: Implement privacy rights, retention, erasure, and propagation #64.
• Rights: accountless access/export, withdrawal, and erasure require fresh purpose-bound identity proof and non-enumerating responses. Operations are idempotent and join Epic: Implement privacy rights, retention, erasure, and propagation #64 processor/restore propagation.
• Delivery: the verification intent/job is created atomically and sent only after commit through the accepted website delivery boundary. Availability notices use a separately approved transactional purpose. Ambiguous delivery is never automatically resent; no marketing subscription or consent is inferred.
• Account/conversion: later account signup never silently links or merges the interest. Explicit conversion may associate only one eligible verified survivor with the same normalized email; mismatch/collision fails closed.

This preserves the lowest signup friction but adds an accountless identity, verification, delivery, abuse, rights, and reconciliation surface.

Common contract after a choice

Whichever packet is approved:

• CourseInterest belongs to one reusable Course and never has a Cohort, campaign, registration, enrollment, learner-work, profile snapshot, or nullable target.
• Creating interest never creates or mutates CourseRegistration, Enrollment, MemberProfile, marketing preferences, or consent.
• A later Cohort registration is a new immutable record and must independently satisfy the full verified-account, completed-profile, privacy, and registration contract. Conversion may mark/link the interest for bounded provenance but never mutate it into the registration or copy interest evidence as registration/marketing consent.
• Withdrawal, expiry, deletion, retry, and concurrency are explicit states/operations; unknown or conflicting identity/evidence fails closed.
• No historical nullable registration, newsletter flag, campaign pointer, account/profile value, or aggregate Preserve public course signup totals without registration PII #133 record is reclassified as interest by inference.
• Logs, metrics, audits, errors, tests, screenshots, and issue evidence contain only bounded safe categories/counts/opaque IDs, never email, profile values, tokens, or protected records.

Activation and migration boundary

Owner approval resolves only this product choice. PM must then update the governing specification and file/re-groom a separate engineer-sized implementation issue with the selected dependencies and acceptance evidence.

• Every option requires the accepted reusable Course identity and applicable Epic: Implement privacy rights, retention, erasure, and propagation #64 retention/export/erasure interfaces.
• I1 requires the accepted durable-survivor/verified-identity contract; I2 additionally requires accepted Build the accounts-owned MemberProfile schema and service foundation #247/Add verified member-profile onboarding and cut over account settings #248 profile service and activation; I3 additionally requires accepted accountless proof, abuse, website delivery, and Epic: Implement privacy rights, retention, erasure, and propagation #64 accountless-rights interfaces.
• Source-only schema work does not authorize a public route, writer activation, protected-data reconciliation, provider contact, production migration, or conversion of legacy rows.
• Any legacy-interest import needs a separately reviewed manifest, mapping, dry-run/reconciliation plan, and protected-data authorization. Unknown/duplicate/ambiguous rows remain untouched or quarantined.

Decision acceptance

• An authorized product/privacy owner records I1, I2, I3, or an equally exact replacement.
• The response explicitly confirms identity/profile gate, dedupe key, stored evidence, pending/verified retention trigger, withdrawal/export/erasure behavior, delivery boundary, and account/registration conversion behavior.
• PM incorporates the selected contract into authoritative specs and replaces this decision packet with unconditional downstream issue criteria and exact artifact dependencies.

Explicit non-goals

No implementation, migration, route/form/API, notification sender/template, protected-data access, legacy-row conversion, Cohort registration, Enrollment conversion, MemberProfile change, marketing preference, privacy-runtime shortcut, provider mutation, deployment, or destructive cleanup. This issue does not reopen #242 or #287 and does not block target-native Cohort registration work that never creates or consumes CourseInterest.

Disposition

BLOCKED — owner decision required. Keep needs grooming and decision. A PM recommendation, silence, code convenience, or an existing nullable registration is not approval and must not start engineering.

[alexeygrigorev]

PM decision grooming — BLOCKED / owner choice required

I narrowed this split issue to three complete, mutually exclusive packets covering the exact missing product authority: identity/profile gate, dedupe key, minimized evidence, retention/expiry, export/withdrawal/erasure, delivery/abuse, conversion, and activation/migration boundaries.

PM recommendation: I1 — verified durable account, no MemberProfile requirement, unique by (Course, durable survivor account), and automatic personal-data expiry 24 months after creation/latest explicit renewal. It is the smallest safe contract: it reuses verified ownership without collecting email/profile snapshots or adding an accountless proof and delivery system.

No option is approved. needs grooming and decision remain until an authorized product/privacy owner replies I1, I2, I3, or supplies an equally exact replacement. After that response, PM must update authoritative specs and create/re-groom a separate engineer-sized implementation issue. No engineering, migration, activation, protected-data work, or provider action is authorized by this packet.