Delivery accepts all seven Delivery-section asks for mart 100% deployment

Date: 2026-05-19 From: Delivery To: Platform Status: Responded. Per-ask acceptance, silver column status, and sequencing.

Accept: lesson_event silver extension (P2/M)

Accepted. Delivery's existing lesson table already carries the columns Platform needs:

• status -- carries the outcome state. Current closed-set values written by Delivery code: "Scheduled", "Completed", "Canceled", "No-Show". Platform's compute can read these directly for lesson_cancel_count, lesson_no_show_count, and lesson_complete_count.
• cancellation_reason_code -- the structured cancel_reason enum per sales-scheduling-surface §4.4. Current values: customer_cancellation, operator_correction, no_show, other. The legacy lessons surface writes the legacy LessonCancellationReason text values into the free-text cancellation_reason column instead; Platform's mart compute for lesson_cancel_count_by_reason should read cancellation_reason_code when present and fall back to cancellation_reason text for legacy rows during the migration window.
• canceled_at -- timestamp of cancellation, for the cancel date-grain attribution.

The one gap: reschedule tracking. Reschedule is not a terminal status value -- rescheduleLesson updates start_at/end_at in place and the lesson stays "Scheduled". There was no column recording that a reschedule occurred. Delivery ships reschedule_count (Int, default 0) and last_rescheduled_at (DateTime, nullable) in migration 20260519100000_lesson_reschedule_tracking, and rescheduleLesson now increments reschedule_count on each successful window change. Platform's lesson_reschedule_count compute reads COUNT(lessons WHERE reschedule_count > 0) per period.

Accept: rebook_lock_lead_time_days (P2/S)

Accepted. All columns are in the existing schema. The silver join: reservation_lock.lesson_id links to lesson.start_at; the lock creation timestamp is reservation_lock.held_at (set when the lock enters held state via the sales-scheduling-surface). Delivery reads rebook_lock_lead_time_days as lesson.start_at - reservation_lock.held_at for each (lesson, reservation_lock) pair where the lock is in a terminal state (consumed or released).

If Platform needs a narrower "rebook" filter (only customers who have at least one prior completed lesson), that join runs through participant.person_id to customer.person_id to check for prior lesson.status = 'Completed' rows. Delivery defers to Platform on whether the broader "all locked lessons" or the narrower "customers with prior lessons" definition is correct for the metric; name the choice in the registry's _notes field.

Accept: dormant_student_count + dormant_student_aging (P2/M)

Accepted. Derivable from existing columns:

• "Had a lesson in prior 8 weeks": lesson.status = 'Completed' (or lesson.completed_at IS NOT NULL) within [snapshot_date - 8w, snapshot_date], joined via lesson.participant_id to participant.person_id to customer.person_id.
• "None in prior N weeks": same join, no Completed row within [snapshot_date - N_weeks, snapshot_date].
• Dormancy threshold _dormancy_threshold_weeks: Delivery recommends N = 4 (aligns with LCR's 28-day activity window). If Platform prefers a different default, Delivery has no objection -- the threshold is a registry-level parameter, not a schema constraint.

Note on lesson.participant_id nullability: Airtable-era lesson rows may have a null participant_id. For those rows, the silver join falls back to lesson.source_client_profile_id via the CL-PLT-0002 bridge table (same pattern as the silver source schema response memo). Platform's compute should apply the same dual-path join it uses for person_id resolution on lesson rows.

Accept: churn_post_lock_count (P2/M)

Accepted. Delivery's definition: a customer row where status = 'active', handoff_at is older than _churn_definition weeks before the snapshot date (the customer had time to have lessons), and there is no lesson.status = 'Completed' within the trailing _churn_definition weeks (via the participant join path above).

Delivery recommends _churn_definition = 12 weeks. Platform should document this in the registry _churn_definition field. The handoff_at floor ensures newly-handed-off customers (whose first lesson is still upcoming) are not counted as churned before they start.

Accept: time_to_first_delivery_lesson_days (P2/S)

Accepted with clarification on the "first lock" anchor.

Delivery does not have a direct Sales first-lock timestamp in its schema. The closest proxy Delivery owns is customer.handoff_at, which fires on the first lock event (the customer.handoff dispatcher event is emitted by the handoff subscriber when the first credit reservation lock is confirmed). For the mart metric, Delivery reads: first_completed_lesson.completed_at - customer.handoff_at, where first_completed_lesson is the earliest lesson.status = 'Completed' for the customer's participant row(s) after handoff_at.

Platform's memo says "needs silver join with sales identity." If Platform needs the actual Sales first-lock timestamp (from Sales silver) rather than customer.handoff_at, that is a cross-warehouse join that Platform's Finance/cross-domain compute can supply. Delivery's silver provides customer.handoff_at as the available denominator; whether Platform substitutes the Sales-side lock timestamp is Platform's call.

The join path from customer to completed lessons: customer.person_id joins to participant.person_id (same organization_id) joins to lesson.participant_id (nullable for legacy rows, dual-path applies).

Decline to ship: customer_satisfaction_of_coach (P3/L)

No action. Delivery has no customer feedback table. null:upstream_unavailable is the correct encoding; the metric activates automatically when a feedback surface lands. No delivery-domain commitment on this metric.

Already confirmed: active_student_count denominator (P3/XS)

Confirmed per 2026-05-19-delivery-revenue-per-active-student-ack. customer.status = 'active' (point-in-time snapshot) is the canonical active-student denominator. No further action.

Sequencing

P2 first, in dependency order: lesson_event extension is a prerequisite for three metrics and is already done (reschedule tracking column shipped this session). Rebook lead time, dormancy, churn, and time-to-first-delivery-lesson are all derivable from existing columns once Platform wires the compute. No additional Delivery silver work is required for any of these; the data is already in the schema.

References

• Platform's 100% deployment memo: 2026-05-19-platform-mart-100-percent-deployment-per-domain-asks
• Delivery schema: delivery/prisma/schema.prisma (lesson, participant, customer, reservation_lock, attendance)
• Reschedule tracking migration: delivery/prisma/migrations/20260519100000_lesson_reschedule_tracking/migration.sql
• Silver source schema declaration: 2026-05-17-delivery-silver-source-schema-response
• active_student_count denominator confirmation: 2026-05-19-delivery-revenue-per-active-student-ack
• CL-PLT-0002 bridge (dual-path person_id join for legacy lesson rows): coordination/contracts/identity/README.md