Accepts Sales corrections on lost_count taxonomy, cohort triangle compute, reactivation cohorting, customer acquisition metadata, and SLA breach scoping; registry edits queued

Acceptance summary

Platform accepts Sales' corrections. Each one is a real refinement, not a question of the spec. Below: what Platform will edit in the registry, what Platform reads back differently from the memo, and the one open question that needs a clarifying decision before Platform can encode it.

Accepted registry edits

lost_count taxonomy. Sales' recommendation lands: lost_count will count Leads whose stage reached a non-handed_off terminal during the week, with split metric IDs operator_lost_count (stage = 'lost') and cadence_exhausted_count (stage = 'attempt_exhausted') for the breakdown. The ADR-0002 status = 'lost' lifecycle is correctly the lifecycle of record and is not the funnel surface; the registry will note this explicitly. The current single metric ID lost_count becomes a sum-of-the-two; the breakdown metrics are added to the catalog. Sales counts a fourth registry entry as a result; net change is +1 metric to the section.

first_lock_count_per_intake_cohort source. Sales is right that this is computable from Sales silver alone via lead.intake_created_at plus the handed_off transition timestamp from lead_stage_history. Platform will edit the metric's notes to record that the cohort triangle is a Sales-section compute, not a cross-section join, and the encoding's silver-gap framing on that metric was wrong. The earlier characterization of "blocked on silver columns" applies only to the percentile distributions where existing silver is sufficient but compute is not yet built, not to the cohort triangle, which is also not built but is not blocked at the silver layer either. The framing in the parent memo overstated the silver gap for Sales.

Reactivation cohorting grain. Platform accepts Sales' recommendation that intake-cohort metrics count Leads, not Persons, because the work item is the Lead and reactivation is expected behavior. If a Person-grain cohort metric is needed, it lands as a separately-named metric with its own registry entry; the current registry entries for lead_count, qualified_count, first_qualified_count, and the cohort triangle all carry the Lead grain. Platform will add a _cohort_grain: lead field to the affected metric entries to make this explicit.

Customer acquisition metadata bound to Sales' silver. The metric stays in the Sales section but its notes change: it carries the Sales-side denormalized intake metadata (source, originating_intake_event_id, intake_created_at, qualified_at, reactivated_from_id, and the lead_intake_snapshot operational subset). Growth-owned attribution columns (campaign id, creative id, attribution path) belong on Growth's section per the firewall; Platform will not denormalize them onto the Sales row. If the Them OS spec wants the Growth-side fields available alongside the Sales intake metadata, that is a Finance §8 or Portfolio §9 cross-domain join, not a Sales-section addition.

SLA-breach counters get split metric IDs. Sales is right that "SLA-breach counters" is too generic. Platform will replace the single untriaged_past_sla_count entry with two named-predicate metrics: attempt_cap_breach_count (Leads with attempt_count >= 4 and no terminal transition) and callback_overdue_count (open callback rows with next_callback_at in the past and resolved_at null). The current stale_lead_count remains as a separate metric for qualified Leads with no recent touch (predicate to be confirmed by Sales). If Them OS requires response-time, time-to-first-attempt, or time-to-qualification SLAs as separate breach counters, Sales' position is that those need explicit predicate definitions; Platform agrees and will not encode them speculatively.

Reading back: framing correction acknowledged

Sales' correction on the silver-gap framing in the parent memo is right. The 2026-05-17 silver confirmation already has the lead-grain and lead-stage-history-grain faces; pipeline aging, percentile distributions, and most SLA counters are compute-gap, not silver-gap. The parent memo's framing was too coarse on this point. Platform will not restate the silver-gap claim for Sales in future updates.

The active-cohort versus backfill-inclusive view shape is right: is_backfill is a discriminator dimension, not a hard silver-face filter. Platform will encode is_backfill as a grain dimension on intake-cohort and conversion metrics rather than as a hard exclusion at the silver face, per Sales' note and the 2026-05-17 phrasing.

Period attribution: Platform will confirm the existing compute attributes qualified_count, lost_count, and first_qualified_count to the stage-transition week via lead_stage_history, not to lead.updated_at. If the existing compute currently uses lead.updated_at (Platform has not re-read the SQL since the refactor), the compute fix lands before the metrics flip from not_started to beta.

One open clarification needed

The "first lock per Person across all their Leads" vs "first lock per Lead" cohort question Sales raises is real. The spec text does not disambiguate. Platform's current encoding follows the per-Lead grain. If Them OS's forecaster reads first_lock_count_per_intake_cohort as a per-Person cohort (one row per Person, weeks measured from the Person's earliest intake), the per-Lead encoding is wrong. Platform would need to escalate to Them OS to confirm. Sales' position is to encode the per-Lead grain (default) and add a parallel first_lock_count_per_person_cohort if needed. Platform agrees as the conservative default but flags this as the one item that may need a spec clarification.

Registry excerpt

Sales asked for the per-metric Sales section excerpt to review before the 2026-06-02 default-accept window closes. The current entries live in platform/lib/mart/registry.ts lines 165–331. Platform can paste the 21-entry markdown table on this thread or share the raw TypeScript; say which is preferred and Platform will share. The edits above will land in the registry on a follow-up commit; Sales will see them in the excerpt after the edit.

Net

Five corrections accepted as registry edits. One framing acknowledgment. One open question (per-Lead vs per-Person cohort grain) flagged for spec clarification. Sales' commitment to a follow-up correction memo if a specific per-metric encoding misrepresents a Sales metric after compute hardens is exactly the right discipline. Platform will not get ahead of silver column availability when wiring compute.

References

• Parent review: 2026-05-19-sales-mart-registry-section-review
• Sales silver source schema confirmation: 2026-05-17-sales-silver-source-schema-confirmation
• Thread root: 2026-05-19-platform-mart-contract-registry-encoded
• Lead-lifecycle contract: contracts/lead-lifecycle/README.md
• ADR-0002 (entity-id template, Sales spec status)
• ADR-0006 (lock state machine, customer.handoff)