Re: Person role filters, Delivery confirms Participant as Student source and redirects Coach to Coaching
Why
Delivery is filing the role-source answer for the Platform Person role-filter thread. The broad Platform shape is right: role chips should be derived from domain-owned role records or projections, not stored as mutable Person attributes.
One correction matters before Platform treats the chips as authoritative. The parent memo's Coach line still reads as if Delivery owns Coach role presence. ADR-0008 and the parallel ADR-0003 amendment moved Coach to Coaching on 2026-05-01. Delivery still owns assignment for a specific lesson and emits coach.assigned, but the Coach role record and coach eligibility surface are Coaching's.
What
For the Delivery-owned part of the map, Student should derive from Delivery's Participant role record. The authoritative shape is one par_ Participant per Person per Organization, keyed by person_id plus organization_id, per ADR-0003 and domains/delivery.md. A child who takes lessons has a Participant; an adult who takes lessons also has a Participant. Minor status stays a Platform Person fact, not a Student role distinction.
The Delivery repo does not yet expose a stable Participant Postgres model or read API for Platform to call. The migration mechanism design names participant as the Phase 2 Delivery table, after lesson_site and before lesson. Until that table and read surface land, Platform should keep the Student chip provisional or hidden rather than deriving it from legacy Airtable table names.
For Coach, Platform should confirm with Coaching, not Delivery. The source should be Coaching's coa_ role record or an agreed Coaching read model keyed by person_id plus organization_id. Delivery should not be used as the Coach source merely because current planner code still has legacy coach-shaped modules during the migration window.
For Client, Delivery has no canonical role source to offer. Delivery's customer_tracking row is post-handoff internal state created from Revenue's customer.handoff; it is not a Person role record and should not become the source of a Platform-wide Client chip. If the operator-facing chip means buyer or customer, Revenue's credit account, order, or reservation facts are the better place to settle that label. If the chip means member of a tenant or organization, Platform tenancy is the better interim label.
Asks
No Delivery-side Platform work is requested by this memo. Delivery's guidance for the next Platform implementation pass is:
- Treat Student as Delivery Participant, but wait for the Participant read surface instead of reaching into legacy Airtable.
- Treat Coach as Coaching-owned and ask Coaching for the role-presence read.
- Do not use Delivery customer-tracking as the canonical Client role source.
References
- Parent memo:
2026-05-07-platform-person-role-filter-follow-up - ADR-0003: Person as canonical entity with role records per domain
- ADR-0008: Coaching as a sixth domain owning Coach, availability, and capacity
- Delivery domain memo:
domains/delivery.md - Coaching domain memo:
domains/coaching.md - Delivery migration mechanism design:
2026-05-07-delivery-migration-mechanism-design