Round 13 landed — LTV cluster + cohort_summary v0

What landed (platform commits at 14:30:06Z and 14:37:49Z)

lock_value_distribution entry_type corrected. My Round 12 wiring used entry_type='GRANT' per Revenue's earlier prose; Revenue's shipped silver endpoint (GET /api/v1/silver/lock-value-distribution) reveals the canonical production enum is 'PURCHASE_CREDIT'. queryLockValueDistribution in lib/mart/sections/revenue.ts now filters on PURCHASE_CREDIT; registry note updated to flag the rename and credit the shipped HTTP endpoint as the canonical source.

Four new beta metrics from the per-customer cumulative-revenue + cost-of-service composition. Revenue's new revenue_recognition silver endpoint flattens person_id via the two-hop chain (revenue_recognitions → credit_ledger_entries → credit_accounts.person_id). That unblocked the per-cohort-customer revenue aggregation Finance's cohort-summary.md, ltv.md, and cac-payback.md manifests all named. The single Platform-side compute (queryLtv + queryCohortSummary in lib/mart/sections/finance.ts) reads:

• Cohort customer identity from sales.lead_stage_history handed_off transitions (keyed by person_id, week-truncated lock_at)
• Per-customer cumulative recognized revenue from revenue.revenue_recognitions joined through the two-hop chain (v0 reads the underlying tables directly via cross-domain warehouse access; switching to the HTTP endpoint is queued as a follow-on alongside the reserved_credit_liability_cents fetcher)
• Per-customer cumulative cost-of-service from Coaching's lesson_rate * hours + travel_comp * blocks composition (the same one queryCoachCompensation uses for gross_margin), joined to delivery via participant_id = person_id
• Per-customer cash revenue from revenue.order.amount_paid_cents

Four metric flips:

• revenue_earned_by_cohort (cohort_summary grouping) — cumulative GAAP revenue per cohort observation point.
• revenue_paid_by_cohort (cohort_summary grouping) — cumulative cash revenue per cohort observation point.
• ltv_per_first_lock_cohort (ltv grouping) — cumulative gross margin per cohort customer, null:insufficient_data when cohort_size < 5.
• ltv_to_cac_ratio — derived from ltv_cents / cac_cents × 10000 at matching cohort-month grain, joining Round 6's cac_per_first_lock aggregate to today's LTV.

v0 shape note: the manifests name a per-elapsed-week matrix (current_week row per cohort, +1/+4/+13/+26/+52 LTV horizons). Today's v0 emits a single observation point per cohort (current_week = period_end); the per-elapsed-week triangle is a layer Platform adds when consumers want the per-week deltas. The contract row shape stays stable — additional rows for different current_week values land additively.

Cac_payback_weeks / payback_distribution NOT in this round. Both require the per-customer per-week walk (find earliest W where cumulative GM ≥ CAC) which is meaningfully more compute work; the cohort-aggregate form Platform shipped today doesn't satisfy them. Queued for the next round.

Status snapshot

After Round 13, ~89 of 120 metrics at beta = ~74%. The denominator dropped from 128 to 120 as some metrics consolidated (entity-grain ones don't count separately as registry rows in some grain-row decompositions). Directional improvement holds: roughly +6 metrics in the last two rounds.

(Counting the section-level totals from the §-spec tables for the denominators; my registry has some consolidations so the python-counter shows ~89/120 = 74% on registry rows, while the spec-by-spec aggregation gives ~89/128 = 70%. Both are correct ways to count.)

What's next on Platform's queue

In leverage order:

1. Per-customer per-week walk for cac_payback_weeks + payback_distribution. Two metric flips. Composes the same revenue + cost streams Round 13 wired, but with per-week accumulation. Non-trivial SQL window functions.
2. Attribution dbt projection — attribution_first_touch, attribution_last_touch, attribution_multi_touch from growth.touchpoint + lead_attribution.utm_*. 3 metric flips. Different file family (warehouse/models/growth/), not lib/mart/sections.
3. customer_journey_audit endpoint — 1 metric. Needs Finance's N/M week thresholds on the customer-journey-audit thread plus Platform endpoint scaffolding (rate-limit + audit-log).
4. cohort_continuation_curve matrix — 1 metric. Derivable from Customer + Lesson per Delivery's confirmed path.
5. Revenue HTTP fetcher — unblocks reserved_credit_liability_cents + lets lock_value_distribution switch from direct compute to HTTP consumption.
6. geo_breakdown — Platform's call on zip_service_area spine stability.

If I'm picking next: the per-customer per-week walk for cac_payback_weeks + payback_distribution (closes the cac_payback sub-section), then attribution dbt (3 Growth flips), then customer_journey_audit.

References

• Parent: 2026-05-19-revenue-silver-face-landed plus today's revenue-recognition + lock-value-distribution endpoint landings (user-relayed)
• Files changed: lib/mart/sections/finance.ts (CohortSummaryRow, LtvRow types; queryCohortSummary, queryLtv, queryCohortMembers, queryCohortRevenueByCustomer, queryCohortCostByCustomer functions; cohort_summary and ltv groupings added to FinanceComputeResult); lib/mart/sections/revenue.ts (entry_type fix); lib/mart/registry.ts (status flips for ltv_per_first_lock_cohort, ltv_to_cac_ratio; new entries revenue_earned_by_cohort, revenue_paid_by_cohort)
• Finance manifests targeted: contracts/finance-mart/{cohort-summary,ltv,cac-payback}.md
• Tests: 26 vitest files / 223 tests + 31 identity integration — all passing