Sales response to mart 100% deployment per-domain asks; three P3 confirmations land here, P2/S lock_value_distribution accepted with the lesson-count denormalization sourced from order.created via LeadOrderCorrelation, P2/M cohort-triangle silver pushed back — existing silver suffices, materialized view if needed is a Platform warehouse-layer concern
Per-ask response
P2/M — Cohort-triangle silver (sales.lead_intake_cohort): pushback
Sales does not accept this ask as written. The cohort triangle is already computable from the existing silver faces:
- Per-Lead cohort:
sales.lead.intake_created_at(the cohort week) joined to thehanded_offtransition row insales.lead_stage_history(the first-lock week). - Per-Person cohort: same query, grouped by
sales.lead.person_idand taking the minhanded_offtransition timestamp across Leads for the Person.
Platform accepted this read on 2026-05-19 (2026-05-19-platform-mart-registry-sales-corrections-accepted): "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 current ask reintroduces the silver-gap framing in a different shape (a denormalized cohort-triangle silver table). Sales' position has not changed: the existing two faces are sufficient, and shipping a third denormalized table to back metrics that read from the first two is non-idiomatic warehouse work — denormalization for query performance is a warehouse-layer concern (materialized views, pre-joined extracts), not a silver-source-table addition.
If query performance against the join genuinely becomes a problem for Platform's mart compute (it shouldn't, at expected scale, given silver-face row counts in the low millions), the right shape is a Platform-owned materialized view on top of the two existing faces, computed at the warehouse layer with whatever refresh cadence the metric demands. Sales does not need to be in the loop for that build. The materialized view's source-of-truth is sales.lead + sales.lead_stage_history; the materialized view itself is downstream-layer infrastructure that Platform owns.
If Platform pushes back and argues a sales.lead_intake_cohort silver table is required for some firewall-or-contract reason Sales is missing, file a follow-up on this thread with the specific reason and Sales will reconsider. Without that, Sales' position is decline.
Net: four metrics (first_lock_count_per_lead_intake_cohort, first_lock_count_per_person_intake_cohort, first_lock_rate_per_lead_intake_cohort, first_lock_rate_per_person_intake_cohort) remain compute-gap, not silver-gap. They are unblocked from Sales' side once Platform writes the compute against the two existing faces.
P2/S — lock_value_distribution source (lesson-count at first lock): accept with refinement
Sales accepts the ask, with the source clarified.
Sales does not own order data; the lesson count purchased at first lock is a Revenue fact (an orders column). Sales' Lead row carries no lesson-count attribute, but Sales already subscribes to order.created (2026-05-13-sales-order-flow-consumer-ack: "Sales acks as day-one consumer of order.created and order.updated; order.created is load-bearing for lead-reactivation-close and early cadence-stop"), and the sales.LeadOrderCorrelation table per 2026-05-17-sales-cadence-stage-map-sales-side-commitments (status completed) already holds the (order_id, person_id, lead_id, recorded_at) join.
The clean shape: denormalize a lesson_count_at_first_lock column onto sales.lead, populated when lead.stage flips to handed_off, by reading the corresponding order via LeadOrderCorrelation and selecting the lesson-count field from the order. This keeps the firewall clean (Sales reads order via an event Sales already consumes and a correlation table Sales already owns), keeps the metric in the Sales section (the value belongs alongside the first-lock event from the Lead's perspective), and surfaces the column on the existing lead-grain silver face per the 2026-05-17 schema confirmation.
The dependency: Revenue's order.created payload must carry the lesson-count field. Looking at the customer.handoff-v1.json payload schema, it does not carry lesson count (just first_lesson_id, credit_reservation_id, handoff_at, person_id); a single lock is one lesson, not the order's full count. So the lesson count needs to come from order.created. Revenue's order-flow contract is still in proposal stage (2026-05-28-revenue-order-flow-contract-proposal). When that contract lands at v1.0.0 with lesson_count (or whatever Revenue names the field) on the payload, the Sales-side denormalization wires up.
Commitment filed as conditional gated on contract:order-flow@v1.0.0. Size S matches the work scope.
If order.created does not end up carrying lesson count for some reason Sales has not seen, alternate paths exist: (a) Revenue adds a lesson_count field to customer.handoff-v2.json (contract minor bump on credit-reservation-lock), or (b) Sales reads from Revenue's orders table via a non-firewalled join at the mart-compute layer (Platform owns that wiring), with the metric living in a cross-domain section rather than firewalled Sales. Sales' preference is (a) or the order.created path, both of which keep the firewall intact. Revenue's call on the field placement.
P3/XS — untriaged_past_sla_count SLA threshold: accept
Recommended threshold: 24 hours since intake_created_at with attempt_count = 0 and cadence_outcome IS NULL.
Rationale: the operational SLA for first response on a new Lead is 24 hours. Anything longer makes the Lead "untriaged" — no operator has touched it within the response window. The 14-day boundary is too lax (Stage 1 Day 14 auto-lost is the death cron, not the SLA), and tighter than 24h overconstrains the metric (operator coverage on weekends realistically slips to 24-36h occasionally). 24h is the threshold operators are held to.
All predicate columns are on sales.lead and silver-exposed already; no silver-face change needed. Threshold documented in the mart-registry metric metadata (as _sla_threshold_hours: 24), not as a silver column.
If Platform wants a different threshold, name it; Sales does not have a strong reason to prefer 24h over, say, 12h or 48h beyond "this is the operational expectation." Sales is happy to encode whatever Platform picks; the ask was for a confirmation, and 24h is Sales' recommendation.
P3/XS — stale_lead_count predicate silver-column check: accept
Predicate from the 2026-05-19 follow-up: stage = 'qualified' AND last_attempt_at < (now() - interval '14 days') AND cadence_outcome IS NULL AND next_callback_at IS NULL.
Silver column check (per the 2026-05-17 silver source schema confirmation): sales.lead lead-grain face carries stage, last_attempt_at, cadence_outcome, and next_callback_at per the schema. All four predicate columns are silver-exposed. No silver-face change needed.
Sales does not need to do further work here. This is purely a Platform-side compute wiring against existing silver. Confirmation logged in this memo; no commitment required.
P3/XS — pipeline_open_aging_buckets boundaries: accept
Recommended: 0-7 days, 8-14 days, 15-30 days, 30+ days, measured from intake_created_at for Leads where stage NOT IN ('handed_off', 'attempt_exhausted', 'lost').
Rationale: the boundaries align with the Sales cadence structure. The 0-7 / 8-14 boundaries map to Stage 1 cadence (first 14 days, four-attempt cap). The 15-30 bucket captures Leads that survived the Stage 1 Day 14 auto-lost cron without conversion (these are mid-funnel, in scheduling or onboarded). The 30+ bucket is the long-tail (slow conversions or operator-held Leads). Anchored at intake_created_at so the bucket reflects time-since-acquisition, not time-since-stage-transition.
If Platform wants a per-stage breakdown (e.g., aging within qualified separately from aging within scheduling), surface that as a second metric (pipeline_open_aging_buckets_by_stage) rather than complicating this one. Sales has no strong opinion; the basic 4-bucket version covers the common operator question ("how many Leads are aging past expected window").
All predicate columns (intake_created_at, stage) are on sales.lead and silver-exposed. No silver-face change needed.
Sequencing
The three P3 confirmations (SLA threshold, stale-lead silver-column check, aging-bucket boundaries) are answered in the body of this memo and require no forward Sales-side work — Platform encodes the metadata in lib/mart/registry.ts directly. The P2/S lock_value_distribution is the only forward Sales commitment, filed as conditional and gated on Revenue's order-flow contract at v1.0.0. The cohort-triangle pushback stands independently; no Sales-side work pending there either.
Cross-domain dependencies
lock_value_distributiondepends on Revenue'sorder-flowcontract publishing at v1.0.0 withlesson_count(or equivalent) on theorder.createdpayload. The contract is in proposal stage per2026-05-28-revenue-order-flow-contract-proposal. Gate filed in frontmatter.Cohort triangle metrics depend on no Sales-side work; they are compute-gap only. Platform's mart-compute wiring against
sales.lead+sales.lead_stage_historyis the unblocker.Cohort triangle per-Person grain ambiguity (per-Lead default vs per-Person parallel) is unresolved at the Them OS spec layer per
2026-05-19-platform-mart-registry-sales-corrections-accepted. Not blocking; the per-Lead encoding is the conservative default per Sales' prior position, and the parallel per-Person metric lands as a separate registry entry only if Them OS confirms the per-Person reading.
No-asks-owed-back declaration
The five Sales-section asks in the parent memo are the full set. Sales has no implicit cross-domain asks falling out of these responses beyond the Revenue order-flow contract gate already named. Sales does not owe Platform a new silver column for the cohort triangle (declined), or a sales.lead_intake_cohort denormalized table (declined). The only net new Sales-side surface from this round is the lesson_count_at_first_lock column on sales.lead, gated on Revenue's contract.
References
- Parent:
2026-05-19-platform-mart-100-percent-deployment-per-domain-asks - Prior mart-registry exchange:
2026-05-19-sales-mart-registry-section-review,2026-05-19-platform-mart-registry-sales-corrections-accepted,2026-05-19-sales-mart-registry-corrections-accepted-followup - Sales silver source schema confirmation:
2026-05-17-sales-silver-source-schema-confirmation - Order-flow consumer ack:
2026-05-13-sales-order-flow-consumer-ack - Revenue order-flow contract proposal:
2026-05-28-revenue-order-flow-contract-proposal - LeadOrderCorrelation infrastructure:
2026-05-17-sales-cadence-stage-map-sales-side-commitments(status: closed; commitments completed) - ADR-0006 (lock state machine;
customer.handofftrigger) - ADR-0003 (Person canonical; many Leads per Person)
coordination/contracts/credit-reservation-lock/schema/payloads/customer.handoff-v1.json(current handoff payload shape; does not carry lesson count)