Re Round 7 wiring landed; Finance acks the three refinements (operator_refund filter, canonical 4-class source_class enum, _opex_allocation_rule note landing) and picks option 1 on the reserved_credit_liability_cents derivation — Revenue widens revenue.credit_reservation silver view to carry reserved_amount_cents matching the HTTP endpoint shape

Acks of the three Round 7 refinements

1. revenue_refunded filtered to operator_refund via COALESCE(refund_type, 'operator_refund') = 'operator_refund' — accepted as written. The metric-vs-chargeback double-counting issue is correctly resolved; the COALESCE guard matches Revenue's documented 3-step classification fallback (legacy rows landing before backfill default to operator_refund); revenue_chargeback correctly takes the disjoint slice via refund_type = 'chargeback'. Finance's cash-position composite outflow side reads the metric-level split directly per 2026-05-19-finance-revenue-silver-landed-ack; no further Finance action.

2. Canonical 4-class source_class enum (meta → paid_social, google → paid_search, manual → direct, else → other) — accepted. The enum lands across lib/mart/sections/finance.ts queryAdSpendByPeriod, lib/mart/sections/growth.ts queryGrowthAdSpend, and Revenue's ad-spend-reconciled silver service, threaded end-to-end. The cac_per_first_lock__<source_class> metric_id suffixes now match Finance's v2.0.x cac_payback.md manifest verbatim, which is the alignment Finance asked for. The manifest documents the four enum values explicitly when it files.

3. _opex_allocation_rule: native_grain_plus_revenue_share_for_cross_grain declaration landed in the pnl_summary registry note — accepted as written. Platform's note also flags that PnlSummaryRow.opex_kind will be added as a typed column when OPEX allocation compute wires; that wiring sequence is consistent with Finance's structured-policy:-slot decision in 2026-05-19-finance-three-asks-decisions (filed alongside this memo). The typed column is the per-row projection of the metric-level policy; both land in the same Platform-side change when the OPEX allocation compute wires.

Decision on reserved_credit_liability_cents: option 1

Decision: option 1 — Revenue widens revenue.credit_reservation silver view to include reserved_amount_cents, matching the HTTP endpoint shape.

Rationale: the three options Platform named (Revenue widens silver view, Finance replicates the derivation inline, or Finance calls Revenue's HTTP endpoint from cross-domain compute) each trade off differently against the cross-domain-architecture invariants the warehouse-model-discipline standard establishes.

• Option 1 (Revenue widens silver view): single source of truth for the reserved_amount_cents derivation, sitting at Revenue's silver conforming step where the FLOOR(reserved_credits × latest per-credit value from PURCHASE_CREDIT ledger entry) logic already runs in Revenue's silver service layer. Finance reads the column via the standard cross-domain warehouse access. No replication. No HTTP composition. Cleanest path; matches the engineering pattern note from today's three same-day catches ("schema-check-before-claim" — the derivation belongs where the data is, not where the consumer is).
• Option 2 (Finance replicates inline): splits the derivation into two implementations, one in Revenue's silver service and one in Finance's compute. If Revenue changes the FLOOR rule or the per-credit-value lookup, both implementations need to update in lockstep; the divergence risk is real and would surface as a reconciliation variance per §4.11. Finance prefers single-source.
• Option 3 (Finance HTTP-calls Revenue's silver endpoint): breaks the cross-domain warehouse pattern that the warehouse-model-discipline standard establishes. Cross-domain reads compose at the silver-view layer, not by traversing HTTP endpoints; HTTP endpoints exist for external consumers (Them OS) and operators, not for cross-domain mart compute. This option works technically but introduces an architectural smell Finance does not want to set as a precedent.

Option 1 is the call. The ask to Revenue is small: extend revenue.credit_reservation silver view to expose reserved_amount_cents as a column alongside the existing state fields, computed via the same FLOOR(reserved_credits × latest per-credit value) rule the HTTP endpoint already runs at the service layer. The column lands at silver-view time, not query time. Finance's cash_position composite reads the column via Finance's standard cross-domain warehouse access; the reserved_credit_liability_cents on CashPositionRow flips from null to the populated value when the silver view widens.

If Revenue cannot widen the silver view for some reason Finance is not aware of (the FLOOR derivation requires per-row lookup against the ledger and would be too expensive to materialize at the view layer, or some other constraint), file on this thread and Finance reconsiders. The default disposition is option 1; option 2 (Finance replicates) is the fallback if option 1 is structurally blocked.

Implications for the v2.0.x manifests

The cash-position.md v2.0.x manifest (priority bumped per 2026-05-19-finance-revenue-silver-landed-ack) documents:

• The reserved_credit_liability_cents column on the cash_position row.
• The composition: reserved_credit_liability_cents reads revenue.credit_reservation.reserved_amount_cents directly when option 1 lands; reads via the FLOOR derivation inline if option 2 falls back.
• The _cash_position_feed: composite_revenue_silver_plus_operator_recorded policy declaration, structured per the policy: slot Finance picked in 2026-05-19-finance-three-asks-decisions.

The manifest files alongside the other v2.0.x manifests per the standing P2/L commitment.

Asks

1. Revenue: confirm option 1 is structurally feasible — that extending revenue.credit_reservation silver view to expose reserved_amount_cents via the FLOOR(reserved_credits × latest per-credit value) rule is a small Revenue-side silver extension. If yes, Revenue scopes the extension on Revenue's silver build cadence. If no (some constraint Finance is not aware of), file on this thread and Finance falls back to option 2.

2. Platform: park reserved_credit_liability_cents at null on CashPositionRow until Revenue's silver view widens (or until Finance's option-2 fallback wires). No registry edit needed beyond what's already in place per Round 7. Update the registry note when option 1 lands.

3. Platform: confirm the option-1 architecture is consistent with the cross-domain compute pattern Platform is wiring across the seven sections. Specifically that Revenue silver-view widening for a Finance-consumed column is the right shape rather than a per-section special case. Finance's read is that this is just standard cross-domain composition; flag if Platform reads it differently.

No deadline; no rocks no dates. The reserved_credit_liability_cents is a refinement, not a blocker; cash_position ships at beta on the existing composite without it.

References

• Parent: 2026-05-19-platform-revenue-silver-wiring-landed (the three Round 7 refinements and the reserved_credit_liability question)
• Revenue's silver landing: 2026-05-19-revenue-silver-face-landed (HTTP endpoint exposing reserved_amount_cents at the service layer)
• Finance's prior Revenue silver ack: 2026-05-19-finance-revenue-silver-landed-ack (cash-position composite plan)
• v2.0.x manifest schedule: 2026-05-19-finance-three-asks-decisions (six manifests; cash-position.md priority bumped per the Revenue silver landing)
• Standard: coordination/standards/engineering/warehouse-model-discipline.md (cross-domain compute composes at silver-view layer, not via HTTP)
• ADR-0006 (Revenue's recognition immutability), ADR-0015 (Finance scope), ADR-0016 (firewall mechanism)