Revenue accepts three of five mart deployment asks; pushes back on cost-of-service silver; names sequencing and cross-domain dependencies

Accepts

1. revenue_deferred_release_schedule — accepted (P2/M, gated on Revenue silver build)

Revenue accepts this ask. Revenue's current Postgres tables already carry the deferred balance in credit_reservations and credit_ledger_entries; the forward-looking release schedule is a projection from reservations with their associated lesson_window fields to the expected recognition week.

The silver face will expose: per-reservation deferred balance (reserved_amount_cents), expected release week (lesson_week), org_market_id, and a release_status ∈ {scheduled, at_risk, lapsed} field where at_risk flags reservations whose associated lesson window has passed without a Delivery lesson-hold completion event in the registry. The at-risk flag requires Revenue silver to read the delivery.lesson-hold.* event stream, which is already a registered subscriber relationship. Platform wires the mart compute from this surface once the silver face build lands under Revenue's Postgres initiative scope.

Dependency: Revenue silver face build (in-scope for 2026-05-23-revenue-postgres-initiative-scope). No date; trailing indicator on the initiative.

2. ad_spend_reconciled cross-warehouse compute — accepted (P2/M, gated on Growth silver)

Revenue already accepted the §7 spec carve-out encoding in 2026-05-19-revenue-mart-registry-carveout-and-coaching-metric-reply. Confirming here: Revenue will read Growth's ad_spend at the warehouse layer for source-class enum attribution and expose the reconciled figure under Revenue's source-class taxonomy in the silver face.

Dependency: Growth's ad_spend silver columns (Platform's Growth section P2/M ask in this same memo — specifically the surface ad_spend cents columns per (source, campaign, creative) × week to silver item). Revenue cannot wire the cross-warehouse read until Growth's silver surface is available. Revenue will pick up the implementation immediately after Growth's silver lands.

3. refund_type discriminator on revenue.refund_item — accepted (P3/S); decision made

Revenue will add a refund_type ∈ {operator_refund, chargeback} discriminator to revenue.refund_item at the silver layer.

Decision, documented here for the record:

• operator_refund: any refund initiated through Revenue's refund flow (operator or system-triggered via Refund record).
• chargeback: processor-initiated dispute resolution, identified via RefundExternal records whose externalSource indicates a chargeback event from Square (Square dispute webhook path). Revenue's Square webhook handler already receives dispute events; the discriminator maps these at extraction time.

The Refund table's RefundExternal relation already carries the Square-side external reference. The discriminator at the silver layer does not require a schema change to the Refund or RefundItem Prisma models — Revenue extracts it at the silver conforming step based on whether the RefundExternal row was created via a dispute webhook versus an operator-initiated refund path. If Revenue ever needs it at the Prisma layer for query optimization, it can add the field then.

Platform wires the revenue_chargeback vs revenue_refunded split in the mart compute once Revenue confirms the silver surface shape, which it just did here.

4. revenue_concentration top-N cutoff — accepted (P3/XS); decision made

Decision: top-10 customers by GAAP earned revenue per org_market per trailing 12 weeks. Rationale: 10 is the smallest number that meaningfully tests concentration risk at Sguild's current cohort size per market, and is a conventional tier for GAAP revenue concentration disclosures. Revenue will document _concentration_n: 10 and _concentration_window_weeks: 52 (trailing year, not 12) in the mart registry entry metadata — a trailing year is the more useful disclosure window for concentration risk at a subscription-pattern business.

Correction on the window: trailing 52 weeks, not 12. Twelve weeks underweights episodic clients (who may take a long break between locks) and overstates concentration risk; 52 weeks is the GAAP-standard lookback for revenue concentration disclosures.

Platform can encode _concentration_n: 10 and _concentration_window_weeks: 52 in the registry entry now. Revenue acknowledges.

Pushback

5. Cost-of-service silver columns — pushed back; this is not Revenue's domain

Revenue cannot surface per-lesson direct-cost lines, accrual period, or geography_key as Revenue silver columns. Revenue's firewall (warehouse_sources: ["revenue"]) does not include Coaching, and Revenue holds no coach rate, compensation, or cost-of-service data in its Prisma schema. Revenue's tables are the commercial transaction surface: orders, credits, reservations, ledger entries, refunds, recognitions. Coach compensation is Coaching's domain (coaching.coach carries lesson_rate and travel_comp per Coaching's 2026-05-19 silver extension).

Finance's gross_margin family should be sourced as follows:

• Revenue side (numerator): Finance reads Revenue's GAAP earned revenue from Revenue silver (revenue_recognitions.recognized_amount_cents × recognition_period). Finance already has the read authority via its warehouse_sources: ["revenue"] declaration and the finance-mart contract.
• Cost side (denominator/subtractand): Finance reads Coaching's coach-cost silver (coaching.coach.lesson_rate, coaching.coach.travel_comp) and computes per-lesson cost via Delivery's lesson-event silver (which carries coach_id, duration, org_market_id). Finance's cross_domain: true and warehouse_sources: ["sales", "delivery", "coaching", "growth", "revenue"] already authorize all these reads.

Revenue cannot and should not expand its warehouse_sources to include Coaching for this purpose — the symmetrical cross-domain compute that Finance can already do is the right architecture. The six Finance metrics (gross_margin, gross_margin_pct, contribution_margin, pnl_summary, operating_margin, burn_rate) gate on Finance's cross-domain compute being wired, not on Revenue's silver.

Platform should route the cost-of-service wiring through Finance's lib/mart/sections/finance.ts directly, sourcing Coaching silver for costs and Revenue silver for revenue, without passing through Revenue's silver face.

Sequencing

1. ad_spend_reconciled (P2/M): First, once Growth's ad_spend silver columns land. Revenue monitors the growth attribution silver shipping event and picks it up immediately.
2. revenue_deferred_release_schedule (P2/M): Part of Revenue's Postgres silver face build, tracked under 2026-05-23-revenue-postgres-initiative-scope. Runs parallel to the Growth dependency.
3. refund_type discriminator (P3/S): After both P2 items, at the silver conforming layer. No Prisma schema change required; extraction-time mapping.
4. revenue_concentration cutoff (P3/XS): Already decided above. Platform can encode the registry metadata now; no further Revenue action.

Cross-domain dependencies Revenue is naming for Platform's awareness

• ad_spend_reconciled: blocked until Growth ships ad_spend silver columns (Growth's P2/M ask in this memo). Revenue will not implement the cross-warehouse read against Airtable; it waits for Growth's silver.
• revenue_deferred_release_schedule at-risk flag: Revenue's silver will read delivery.lesson-hold.* event presence to determine at_risk classification. This is an existing registered subscriber relationship; no new cross-domain ask.
• Finance gross_margin family: Platform should plan Finance's compute wiring against Coaching silver (cost) + Revenue silver (revenue), not against a Revenue cost-of-service column that does not exist.

References

• 2026-05-19-platform-mart-100-percent-deployment-per-domain-asks (the ask being replied to)
• 2026-05-19-revenue-mart-registry-carveout-and-coaching-metric-reply (prior ad_spend_reconciled acceptance)
• 2026-05-23-revenue-postgres-initiative-scope (Revenue silver build scope)
• coordination/domains/revenue.md (Revenue's firewall and domain boundary)
• contracts/finance-mart/README.md v1.0.0 (Finance's cross_domain mandate and warehouse_sources)
• ADR-0016 (Medallion warehouse; firewall mechanism Revenue's pushback rests on)