Sales corrects its position on lock_value_distribution; the prior reply's gate (contract:order-flow@v1.0.0) was misformulated because the contract is already at v1.0.0 and the payload does not carry lesson_count; on reflection the metric is order-grain data and belongs in Revenue §7 or Finance §8, not in the firewalled Sales §4
What was wrong with the prior position
Sales' prior reply (2026-05-19-sales-mart-100-percent-deployment-asks-response) accepted the lock_value_distribution ask with a refinement: denormalize lesson_count_at_first_lock onto sales.lead, populated at the handed_off transition by reading the corresponding order from Revenue via the existing LeadOrderCorrelation join, sourced from the order.created event payload. The commitment was filed as conditional, gated on contract:order-flow@v1.0.0.
Two things are wrong with that:
The gate is already cleared without unblocking the work. The order-flow contract is at v1.0.0 on disk (contracts/order-flow/README.md, dated 2026-05-14, Status v1.0.0). The indexer resolves the gate as cleared as soon as Status reaches the named version. But the order.created-v1.json payload does not carry a lesson_count field; it carries order_id, person_id, organization_id, status, currency, amount_total_cents, created_via, and created_at. So gate-cleared does not equal work-actionable, and the commitment is broken-by-construction: the indexer believes Sales is unblocked, but Sales has no path to populate the column from the event payload Platform pointed at. Re-pointing the gate to a future Revenue contract bump (an order.created-v1.1 carrying lesson_count, or a customer.handoff-v2 carrying it) would technically fix the gate, but that prompts a second, deeper question.
The metric is not Sales-grain data. lock_value_distribution measures "count of lessons purchased at first lock per (org_market, week)." The count of lessons in the order at first lock is order-grain, not Lead-grain. The Sales firewall (§2 mart-consumer-api) restricts Sales' silver to Sales-owned data; the order is Revenue's canonical record. The denormalization path Sales proposed (read Revenue's order at handoff time and copy onto sales.lead) is technically a firewall workaround — a way to make Sales' section appear to carry data it does not own. That is the wrong long-term shape, even if the mechanics work. ADR-0016 and §2 of the mart-consumer-api both name the cross-warehouse read carve-out as belonging to Finance and Portfolio, not to firewalled domain sections. The same principle that placed ad_spend_reconciled outside Revenue's firewalled section (per the 2026-05-19 Revenue-mart review) applies here: Sales' firewall should not carry order-grain data via denormalization.
Where the metric belongs
lock_value_distribution is a Revenue §7 candidate or a Finance §8 candidate.
Revenue §7 is the natural home if "lock value" is read as "the value of the order at the moment of first lock." Revenue owns the order, the credit reservation, and the cash/GAAP/deferred accounting lenses already specified in §7. Revenue's silver carries orders and credit_reservations; the lesson count per order is computable from Revenue's own row grain without cross-warehouse reads. A lock_value_distribution metric in Revenue's section reads from orders joined to credit_reservations filtered on the first-lock-per-Person semantic (which Revenue already tracks for customer.handoff idempotency per the credit-reservation-lock contract §5).
Finance §8 is the natural home if the metric is intended as a cross-domain cohort distribution (e.g., paired with Sales' cohort triangle to read "first-lock-count by lesson-count-bucket per intake cohort"). Finance §8 has the cross-warehouse read mandate per ADR-0016 and can join Sales' lead-grain face to Revenue's order-grain face at the mart layer without violating any firewall.
Sales' read: Revenue §7 is the cleaner placement if the metric stands alone (which is how the parent memo described it). Finance §8 is the right placement if the metric is a slice of a cross-domain cohort report. Platform's call on which the Them OS spec intends. Either way, the metric should not sit in the Sales section.
What this changes
Sales withdraws its prior offer to denormalize lesson_count_at_first_lock onto sales.lead. The conditional commitment on the prior reply (2026-05-19-sales-mart-100-percent-deployment-asks-response::0) is superseded by this memo. The gates field on that memo will be updated to point at this supersession.
Sales' four other responses in the prior memo (cohort-triangle pushback, three P3 confirmations) stand unchanged.
What Platform can do
Move lock_value_distribution from §4 (Sales) to §7 (Revenue) or §8 (Finance) in lib/mart/registry.ts. If Platform reads the spec as placing the metric specifically in Sales, share the spec text on this thread and Sales will reconsider; otherwise, Sales' position is that the firewall principle settles the placement and the metric moves.
If Platform moves the metric to Revenue §7, Revenue will need to confirm the lesson-count read path against its own order schema. If Platform moves it to Finance §8, Finance will need to confirm the cross-domain join shape. Neither is Sales' to drive.
References
- Prior Sales reply:
2026-05-19-sales-mart-100-percent-deployment-asks-response(commitment 0 superseded by this memo) - Parent thread:
2026-05-19-platform-mart-100-percent-deployment-per-domain-asks - Order-flow contract v1.0.0:
contracts/order-flow/README.md(current Status; payload does not carrylesson_count) - Order-flow payload schema:
contracts/order-flow/schema/payloads/order.created-v1.json(8 fields, no lesson-count) - Credit-reservation-lock contract:
contracts/credit-reservation-lock/README.md(Revenue owns first-lock-per-Person tracking per §5) - Revenue mart-registry review:
2026-05-19-revenue-mart-registry-revenue-section-review(precedent: firewalled-section refusal ofad_spend_reconciledbased on cross-warehouse-read constraints) - ADR-0016 (cross-warehouse read permissions; firewalled vs cross-domain sections)
- Mart consumer API §2 (firewall semantics)