Re Round 10 Coaching asks

Ask 1 — Capability schema

null:not_applicable stands. No formal capability taxonomy exists in the Coaching schema. CoachCertification (coach × CertificationType) is the closest surface — it carries a vocabulary of certification types scoped per organization with issuedAt, expiresAt, and status. Certification type is not a capability tag: it records credentials, not the skill or discipline dimensions that coach_idle_hours_by_capability implies.

Until a formal capability model is introduced (a per-coach capability roster with a canonical taxonomy), coach_idle_hours_by_capability stays null:not_applicable. Activation path is automatic when the model exists — no follow-up memo needed at that time if the column shape is named here.

Ask 2 — Employment history; coach.status derivability

The short answer: coach.status is point-in-time only. Status transitions are not silver-exposable from existing columns in a clean aggregate form.

What exists: The Coach model carries a CoachStatus enum (hiring, onboarding, active, inactive, archived) as a point-in-time field. There is no coach_employment_event table, no first_active_at timestamp, and no dedicated status-history surface. The CoachingAuditLog is an append-only ops audit log that records before/after JSON blobs for all ops writes — status transitions would be captured there, but the table is not shaped for warehouse aggregation (no enum column, before/after is untyped JSON, not indexed for efficient per-period transition queries).

Implication for the four metrics Platform named:

• coach_churn_count — requires a count of active → inactive or active → archived transitions in a period. Not derivable from coach.status alone (point-in-time). Derivable from CoachingAuditLog by parsing before.status / after.status, but this is a fragile silver path, not a clean one. Coaching does not plan to ship coach_employment_event silver this sprint.
• coach_onboarding_count — requires a count of coaches entering onboarding or active for the first time in a period. coach.createdAt can proxy "new coach rows added" but conflates hiring-status rows (not yet onboarding) with true onboarding starts. Not a reliable derivation without an event table.
• coach_ramp_time_days — requires first_active_date - onboarding_start_date. Neither field exists as a typed column.
• coach_tenure_distribution — requires current_date - first_active_date. Same gap.

All four are null:upstream_unavailable. Coaching will file a memo when a coach_employment_event silver is scoped; until then Platform should not attempt to derive these from the audit log.

Ask 3 — Survey surfaces

coach_satisfaction_of_platform — Coaching's side, null:upstream_unavailable. No coach feedback or survey table exists in the Coaching schema. When survey infrastructure lands, Coaching will file a follow-up naming the source table.

customer_satisfaction_of_coach — This is not a Coaching-side surface. The customer relationship lives in Delivery (delivery.customer, delivery.attendance). A customer-feedback or survey table for rating their coach experience would be a Delivery domain resource. Coaching has no insight into its current existence or roadmap. Platform should direct Ask 3's second half to Delivery; Coaching's ack from 2026-05-19-coaching-mart-100-percent-deployment-ack did not address this metric for this reason.

Summary