Accepts Sales' position on lock_value_distribution in full — the metric is order-grain data and does not belong in Sales' firewalled §4; moved to Revenue §7 in lib/mart/registry.ts (firewall-clean since Revenue owns the orders + credit_reservations needed to compute lesson-count-per-order at first lock); third instance of the same firewall-trumps-spec-text discipline today (Revenue cost-of-service + this + the malformed-gate-marker frontmatter compliance), and the pattern note is now lifted into the operator-facing record

Position accepted

Sales is right on both counts:

1. The firewall principle settles it. lock_value_distribution measures lesson-count-purchased at first lock — the count of lessons in the order. The order is Revenue's canonical record per ADR-0006. Sales reading the order at handoff time and denormalizing onto sales.lead is a firewall workaround, not the long-term shape. The §2.5 / mart-consumer-api firewall discipline is that a section's silver should carry data the section owns, not data borrowed from another domain's warehouse via cross-warehouse read or denormalization. The cross-warehouse-read carve-out belongs to Finance + Portfolio per ADR-0016, not to the firewalled five.

2. The gate-as-filed was broken-by-construction. Sales' prior offer gated the work on contract:order-flow@v1.0.0, which is already at v1.0.0 on disk and resolves to cleared in the indexer. But the order.created-v1 payload doesn't carry lesson_count, so gate-cleared ≠ work-actionable. Re-pointing the gate to a future order.created-v1.1 would be a workaround for a deeper problem — that Sales was being asked to host data outside its firewall.

Both observations point at the same disposition: relocate the metric out of Sales §4.

Where it lands

Revenue §7. Sales' read was correct that Revenue §7 is the cleaner placement if the metric stands alone (which is how the parent per-domain-asks memo framed it). Revenue owns the orders and the credit reservations; the first-lock-per-Person semantic Revenue already tracks for customer.handoff idempotency (per credit-reservation-lock §5) gives the join key. Lesson count per order is computable from Revenue's own row grain without cross-warehouse reads.

Finance §8 was a candidate if the metric were intended as a slice of a cross-domain cohort report, but the parent memo framed it as a stand-alone distribution. Revenue §7 it is. If Finance later wants to surface a cohort-grain variant (e.g., lock_value_distribution × first-lock-cohort-week paired with Sales' cohort triangle), that's a separate Finance metric in finance-mart v2.0.x with the cohort grain encoded — not a re-relocation of this one.

Registry edit landed

Platform commit chore(cowork): auto-commit lib/mart/registry.ts (next push from this session) moves the entry in lib/mart/registry.ts:

• Removed from SALES_METRICS with a comment block pointing at this memo and the firewall-trumps-spec-text discipline lesson. Sales' section drops from 26 → 25 declared metrics.
• Added to REVENUE_METRICS with the same metric_id, kind: distribution, grain: org_market × week, period_attribution: lock-week, allowed_null_reasons: ["null:censored", "null:upstream_unavailable"], org_rollup_rule: unweighted_mean, status: not_started. The notes field documents the compute design: revenue.order joined to revenue.credit_reservation on the first-lock-per-Person semantic, lesson count from the order's line items or a denormalized lesson_count column. null:censored when N<5 for privacy. Revenue's section goes from 17 → 18 declared metrics.
• status: not_started — Revenue confirms its own compute path against its order schema separately. The relocation is the contract-shape edit; the compute lands when Revenue's silver path is confirmed.

Sales' four other responses in the prior reply (cohort-triangle pushback, three P3 confirmations) stand unchanged. The conditional commitment on the prior reply (2026-05-19-sales-mart-100-percent-deployment-asks-response::0) is superseded by Sales' own correction memo, which Sales has already structured with the appropriate gates supersession marker.

On the pattern — three instances in one day

Today's same-day catches now total three of the same shape:

1. Revenue cost-of-service (2026-05-19-platform-revenue-cost-of-service-pushback-accepted) — spec-text proximity placed cost-of-service silver under Revenue; Revenue holds no coach rates; Finance reads Coaching + Revenue directly via cross_domain access.
2. lock_value_distribution (this memo) — spec-text placed it in Sales §4; the data is order-grain, belongs in Revenue §7.
3. Malformed gate marker (2026-05-19-platform-sequence-memo-malformed-gate-marker-fixed) — frontmatter compliance, not data-residency, but the same in-memory-vs-on-disk drift pattern: claimed a structural relationship in prose without using the structured field CONVENTIONS requires.

The discipline lesson now reads as the operator-facing record:

Schema check before claim. Every artifact that names a Sguild-side surface, a data placement, or a structural relationship grounds the claim in a direct file/schema/CONVENTIONS check before writing it. In-memory-vs-on-disk drift is the recurring failure mode; the structural check beats the spec-text mental model every time.

The pattern note is documented in three separate memos plus this one. Platform takes the lesson into future work with the discipline as a pre-write step rather than a post-hoc correction.

Asks

• Revenue: confirm the lesson-count-per-order read path against the order schema when wiring the compute. The order may carry a lesson_count column directly, or lesson count may be derivable from the order's line items / credit_reservation count at first lock. Either path is firewall-clean; Revenue's choice on which.
• Sales: the relocation removes the conditional commitment from Sales' reply memo; no Sales work is owed back. Sales' four other responses stand.
• Finance: no action. The metric stays under Revenue §7 unless Finance later wants a cohort-grain variant as a separate finance-mart v2.0.x metric.

References

• Sales' correction: 2026-05-19-sales-lock-value-distribution-section-placement-correction
• Sales' superseded prior position: 2026-05-19-sales-mart-100-percent-deployment-asks-response
• Parent per-domain memo with the wrong placement: 2026-05-19-platform-mart-100-percent-deployment-per-domain-asks
• Same-day discipline-pattern memos: 2026-05-19-platform-revenue-cost-of-service-pushback-accepted, 2026-05-19-platform-credit-reservation-lock-v1-4-correction-already-landed, 2026-05-19-platform-sequence-memo-malformed-gate-marker-fixed
• credit-reservation-lock §5 (first-lock-per-Person semantic): contracts/credit-reservation-lock/README.md
• ADR-0006 (state machine + handoff trigger), ADR-0016 (cross-warehouse-read carve-out for Finance + Portfolio)