Product Decision Log

Field	Value
Status	live
Owner	PRODUCT OWNER / DIR
Last updated	2026-06-14
Relationship	Feeds product-spec.md; product-sensitive PRs should cite the relevant decision IDs.

Operating Rule

The operator is the product owner. Product decisions do not block engineering by default: use a conservative MVP working assumption, record it here, include it in the PR spec/notes, and keep moving. Stop only if the operator explicitly asks or the choice would create major rework if wrong.

Statuses:

• working assumption - safe to build against now; product owner may revise.
• decided - product owner has explicitly confirmed.
• revisited - prior decision changed; keep the old row for history.

Decisions

ID	Date	Status	Decision / working assumption	Applies to	Notes
PD-001	2026-06-08	decided	Product decisions are handled like counsel questions: record the issue, state a working assumption, keep engineering moving, and update the product spec after every pass that changes product behavior or scope.	Atelier process, all ideas	Product owner is the operator.
PD-002	2026-06-08	working assumption	Consent UI should present separate optional toggles for analytics, ML training, and marketing. Core auth/matching should continue even when these are off.	Mobile consent UI, infra events, privacy readiness	Implemented in mobile PR-13 using Settings privacy choices and a non-blocking Home prompt. Backend primitives use analytics, ml_training, and marketing.
PD-003	2026-06-08	working assumption	Consent copy and notice labels may be internal placeholders before real users; final external copy is legal/policy publication work.	Mobile consent UI, privacy notice	Mobile PR-13 uses internal placeholder copy and mobile-internal-2026-06-08; log counsel copy questions separately in ../counsel-queue.md.
PD-004	2026-06-08	working assumption	Deleted-user messages should be tombstoned while preserving thread continuity for the other participant.	Messaging, account deletion, retention	Backend message-send exists as of infra PR-22 (2680a01); tombstone/delete behavior remains a counsel/product retention question.
PD-005	2026-06-08	working assumption	Reports against deleted users should be retained in pseudonymized safety form for the report-retention window.	Trust and safety, account deletion	Preserves abuse-history utility without keeping ordinary account identity.
PD-006	2026-06-08	working assumption	Partile is 18+ until an age/minors policy is explicitly designed.	Onboarding, safety, privacy	Avoids minors complexity for the stranger-matching / physical-proximity MVP.
PD-007	2026-06-08	working assumption	Show safety guidance before first meaningful in-person contact.	Messaging, matching, safety	Exact copy can start as placeholder product copy and be refined later.
PD-008	2026-06-08	working assumption	Worker lifecycle events (match.candidate_proposed, match.expired) should start as analytics-tier, worker-originated, actor-scoped rows per affected participant, not ML-training signals or pair-wide system rows, unless a later product decision changes that.	Event taxonomy, ML governance	Implemented in infra PR-19 (94d4018) through try_emit_event; this preserves per-user analytics consent semantics while keeping operational/product analytics possible.
PD-009	2026-06-08	working assumption	Message events should record metadata only, such as length and lineage identifiers, never message body.	Message-send path, event taxonomy	Implemented for backend message.sent in infra PR-22 (2680a01) as T1 metadata-only (body_length) with no message body in event fields.
PD-010	2026-06-08	decided	Android expansion work is held unless the operator reopens that lane. Existing mobile PR-12 Android dev-build harness remains recorded as current state, but further Android manual QA / Google Play prep should not be the default next work.	Mobile release planning	This corrects the yolo-run scope mismatch.
PD-011	2026-06-08	working assumption	Future ML training must use anonymized aggregate snapshots built from whitelisted T2 events only; direct app_events, T0/T1 events, low-k groups, raw trajectories, and non-whitelisted fields are not training inputs.	ML governance, anonymization boundary	Implemented technically in infra PR-20 (9e828db) with k-anonymous ml_training_snapshots / _rows; counsel C8/C9 still ratify the final anonymization standard before real model training.
PD-012	2026-06-08	decided	Active presence requires a verified boarding pass. The product flow is sign in -> boarding-pass gate -> scan/upload -> barcode decode -> confirm normalized trip -> create presence. Manual flight entry is rejected for the beta/product flow (any dev-only fallback is explicitly out of product scope, never a beta path). Matching, candidates, and conversations stay unavailable until a verified trip/presence exists. MVP capture is in-app: camera scan of a paper or on-screen digital pass, plus screenshot/image import from Photos/Files. PDF/document import is currently unsupported and must fail closed unless it can be decoded locally without raw retention. Native share extensions and direct Apple/Google Wallet pass-library access are later, non-MVP.	Presence, onboarding, matching gate, mobile capture, backend verification, privacy/minimization	Operator decision: no manual flight info entry. Verification source is barcode decoding (IATA BCBP over PDF417/Aztec/QR/Data Matrix); OCR only as a label fallback when barcode extraction fails, never as the verification source. Raw image/PDF/barcode material is transient and not retained; backend stores only minimal normalized trip/presence fields. Infra PR-21 (52cd2c8) implements the backend product contract: authenticated /presence requires verification_source=boarding_pass_barcode and verification_level=document_verified, rejects manual/self-reported/unverified writes, and still rejects raw pass artifacts. Mobile PR-15 (a078460) implements the UI/state gate, removes the manual Set Presence product path, and fresh-checks GET /presence before candidate/conversation product fetches or candidate approve/dismiss mutations. Mobile PR-16 (305b387) implements the camera barcode scan path, conservative on-device BCBP parse, sanitized trip confirmation, document-verified presence creation, and denied/unavailable camera states without raw barcode retention. Mobile PR-17 (c478b26) implements Photos/Files image import with local scanFromURLAsync, shared confirmation/submission, cache-copy cleanup, and no raw image/barcode storage/log/API path; PDFs/non-images are unsupported/fail closed. Mobile PR-18 (075b035) physically verifies iPhone scan/import/gate/unlock behavior with sanitized evidence and fixes the scanner preview hard gate by removing premature CameraView.isAvailableAsync() failure while preserving sanitized onMountError. Ties: PRIV-06, ../counsel-queue.md C25.
PD-013	2026-06-10	decided	Professional-networking intent only; not dating/casual.	Product positioning, discovery, safety copy	Canonicalized in user-journeys.md.
PD-014	2026-06-10	decided	Matching requires verified shared place and time (boarding pass sets airport X + window W; night-before scan enters tomorrow's pool; no proximity -> no match).	Presence, matching pool, discovery	Supersedes any "active presence now" interpretation.
PD-015	2026-06-10	decided	Discovery = open, relevance-ranked directory of everyone in-window + starring/shortlist.	Discovery, matching UX	Implemented as backend GET /directory in infra PR-23 (75d8337), internal-signal relevance ordering in infra PR-26 (e40f0fd), and mobile directory + local-only stars in mobile PR-24 (c441157).
PD-016	2026-06-10	decided	Connect = request-to-connect with a note; recipient reads the note before accept/decline (supersedes dating-style double-opt-in).	Connect, messaging, safety	Implemented in backend infra PR-24 (a6cf2af) and mobile PR-25 (12615d7), including incoming/outgoing lists, accept-to-conversation, and block/report on directory and incoming-request cards.
PD-017	2026-06-10	decided	Match rationale = model-generated "why you two", shown symmetrically to both sides; PDL/ZoomInfo enrichment is an internal matching signal only, never displayed or redistributed.	Matching, AI rationale, enrichment, privacy	Infra PR-27 (e43b60c) implements cached symmetric Claude rationale using minimized profile fields. Enrichment remains deferred/not active per PD-024.
PD-018	2026-06-10	decided	Profile = LinkedIn + optional internal enrichment + user-built via quick intent tags or an optional AI interview; MVP AI scope = match rationale + AI interview only (no icebreakers/scheduling).	Profile, AI scope, matching	Backend profile fields are implemented in infra PR-25 (0934291) and mobile PR-26 (88cf083). The AI interview backend is implemented key-gated in infra PR-28 (d2db03f); mobile interview UI remains upcoming.
PD-019	2026-06-10	working assumption	Structured chat: note opens -> recipient confirms intent (Advice/Intro/Hiring/Pitch/Just connect) -> one-tap Propose-to-meet; gate/area + suggested neutral Heathrow spot revealed only on mutual accept.	Chat, meet-up handoff, safety	Director-proposed assumption still open to operator veto.
PD-020	2026-06-10	working assumption	Connections persist post-trip as durable professional contacts (network, not moment); discovery stays window-bound.	Connections, retention, erasure	Infra PR-29 (1fbcf6e) implements GET /connections over accepted connection requests; independent retention duration and erasure treatment still tie to counsel C28.
PD-021	2026-06-10	decided	Launch is Heathrow-only (single airport; terminal maps available).	Launch scope, meet-up suggestions	Multi-airport launch remains out of v1 scope.
PD-022	2026-06-10	decided	Message-send is in product scope (infra PR-22); message events record metadata only, never body.	Messaging, event taxonomy, privacy	Infra PR-22 (2680a01) has passed: backend POST /conversations/{id}/messages is implemented with no-leak authz, rate limiting, and consent-gated metadata-only message.sent. Mobile PR-23 (ea3aaac) adds the message composer/send surface.
PD-023	2026-06-11	decided	AI match rationale and the optional AI profile interview use the real Claude API; Anthropic is a subprocessor; implementation is key-gated and must preserve no-training, minimization, and response-caching controls.	AI rationale, AI interview, subprocessors, privacy	Implemented key-gated in infra PR-27 (e43b60c, Claude Haiku 4.5 rationale) and infra PR-28 (d2db03f, Claude Sonnet 4.6 profile interview). Without ANTHROPIC_API_KEY, rationales return null and /profile/interview returns 503. Ties: GOV-06, C27.
PD-024	2026-06-11	decided	Enrichment is deferred. PDL/ZoomInfo remain planned, not contracted, and no broker data is processed until a later explicit implementation/vendor decision. Ranking should use internal signals only for now.	Enrichment, ranking, subprocessors, privacy	Operator decision. Keeps PRIV-13 designed but inactive; ties C26, RoPA, subprocessors.
PD-025	2026-06-11	decided	Accepted connections should have a dedicated contacts-list surface backed by GET /connections; it exposes only accepted, non-blocked, self-scoped professional contacts and conversation links.	Connections, network, retention	Implemented in infra PR-29 (1fbcf6e) with connections_smoke.py. This operationalizes PD-020 but does not resolve independent retention duration, which remains C28.
PD-026	2026-06-14	decided	Monetization of the social/connecting layer. Affiliate-first is the day-one revenue engine; the social graph stays FREE during cold-start — do NOT paywall discovery while density is still being proven, because gating it suppresses the opt-in / co-presence that is the make-or-break (even a strong terminal yields only ~20–40 visible profiles at base adoption). Once a node has real density, move to free-to-be-seen + paid-leverage: being discoverable + a limited number of intros are free; pay to unlock unlimited/priority intros, "see who wants to connect / who viewed you", and pro filters (industry/fund/role). First paid social SKU = a ~$5 one-time / per-trip "unlock connections" at the high-intent moment (delayed, at-gate); a higher annual sub (~$24–36/yr) for power users is a later layer. $1/mo is rejected (too low to matter — below affiliate per-user take — churns, and still gates density). Exact price to be A/B tested in-app, not guessed.	Monetization, discovery, subscription/IAP, GTM phasing	Operator-confirmed direction (2026-06-14). Grounded in research/travel-companion-pass2.md (affiliate-first + thin sub; pro-networking converts ~3–6% at $60–120/yr ARPPU, not dating-like) and research/market-sizing-* (density/opt-in is the constraint, and infra break-even ≈250 active users at $10/yr — so pricing is a growth lever, not a survival need). Apple: in-app unlocks/subs are IAP (~15% small-business program), unlike external affiliate referrals; $1/mo is especially IAP-inefficient. Ties: pass-2 Apple compliance (affiliate 3.1.3(e) external vs 3.1.1 IAP), PD-013 (professional-not-dating), PD-016 (request-to-connect).