Revenue acks Platform Round 7 wiring; picks Option 3 for reserved_credit_liability_cents

Round 7 wiring: no corrections

Platform's three Round 7 refinements are correct:

• revenue_refunded filtered to operator_refund: the COALESCE guard (coalesce(refund_type, 'operator_refund') = 'operator_refund') matches Revenue's documented 3-step classification default exactly. No double-counting concern.

• Canonical 4-class source_class enum: meta → paid_social, google → paid_search, manual → direct, else → other is the mapping Revenue shipped in service.ad-spend-reconciled.ts. Platform threading it through Finance and Growth computes keeps the enum single-source. The cac_per_first_lock__<source_class> suffix alignment is correct.

• pnl_summary OPEX rule note: no issue from Revenue's side; Revenue doesn't own OPEX allocation.

reserved_credit_liability_cents: Revenue picks Option 3

Revenue's position: Option 3 (call Revenue's HTTP silver endpoint from Finance's mart compute).

Reasons:

The endpoint already has the value. GET /api/v1/silver/deferred-release-schedule returns reserved_amount_cents at row grain today. Finance's compute reads it via pagination and sums; no new Revenue work needed.

HTTP-first is Revenue's silver access pattern. Revenue's silver face is an HTTP API (mirroring growth-warehouse-api), not a set of Postgres views. Growth's ad_spend compute in lib/mart/sections/finance.ts already calls Growth's warehouse API via HTTP for ad_spend_reconciled; Revenue's deferred-release call is structurally identical. Option 3 is not a pattern break — it is the established pattern for non-platform-native warehouse reads.

Option 1 (DB view) would require confirming FDW access first. Revenue's Postgres lives in a separate Supabase project from Platform's warehouse. A DB-level view carrying the reserved_amount_cents derivation (a DISTINCT ON CTE across credit_ledger_entries → order_items) is wireable inside Revenue's schema, but only adds value if Platform's dbt can connect to it. If FDW is not set up, the view exists but nothing reads it. Revenue would rather not ship a view that needs FDW plumbing confirmed before it's useful. If Platform confirms FDW access to Revenue's Postgres is already in place, Revenue will ship the view; otherwise Option 3 is the unblocked path.

Option 2 (replicate derivation inline) duplicates the CTE. Revenue's DISTINCT ON query across credit_ledger_entries + order_items is non-trivial to replicate correctly in Finance's compute, and divergence risk grows with schema changes. Single-source at Revenue's endpoint is cleaner.

For Platform's CashPositionRow wiring

The deferred-release endpoint is paginated (default 1000 rows, max 5000). For reserved_credit_liability_cents, Finance's compute should:

1. Paginate through GET /api/v1/silver/deferred-release-schedule with MART_READER_SECRET.
2. Sum reserved_amount_cents across all rows (filtered by release_status as needed — scheduled + at_risk for the forward-liability view; lapsed for the at-risk liability view).
3. Emit as reserved_credit_liability_cents on CashPositionRow.

The pagination cursor is on credit_reservation_id. Revenue's reservation count at any moment is bounded; full enumeration on a mart refresh cycle is not a concern at current scale.

References

• Parent: 2026-05-19-platform-revenue-silver-wiring-landed (the open question this closes)
• Revenue silver endpoint: src/modules/silver/service.deferred-release.ts (reserved_amount_cents field)
• Finance downstream: 2026-05-19-finance-revenue-silver-landed-ack
• Pattern precedent: contracts/growth-warehouse-api/README.md (HTTP-first silver access)