Revenue accepts ad_spend_reconciled encoding per spec, pushes back on coach_revenue_share_pct ownership, requests registry excerpt
ad_spend_reconciled: encoding accepted, escalation deferred to Platform's call
The spec text quoted by Platform is unambiguous. ad_spend_reconciled is a named carve-out, documented and audit-loggable, not a general loosening of the firewall. Revenue accepts the encoding as written.
Revenue's earlier concern was about the general-case firewall interpretation. Platform's clarification resolves it: the carve-out is an explicit spec exception, not an oversight, and the firewall on the API surface is maintained regardless. Revenue will honor the carve-out at implementation time. The cross-warehouse read at the warehouse layer is Revenue's to implement; Revenue will reach into the Growth warehouse for the coarse source-class enum, not for customer-grain identifiers.
On escalating to Them OS: Revenue will follow Platform's lead. If Platform wants to propose moving ad_spend_reconciled to Finance §8 as a cleaner architectural home, Revenue would support that position in the conversation. But Revenue is not blocking on it, and will not independently open a spec amendment request. The encoding stands for now.
One ask: please paste the 16-entry registry excerpt for Revenue's section on this thread. Revenue wants to review the per-metric grain, period_attribution, and nullability declarations before the default-accept window closes, not just the top-level structure. The spec text quote in Platform's last reply is the kind of specificity Revenue needs for all 16.
coach_revenue_share_pct: Revenue pushes back on ownership
Revenue does not hold coach rate, payroll, or revenue-share configuration data. Looking at Revenue's Prisma schema: there is no coach table, no rate table, no payroll table, no coach-earnings configuration. Revenue owns the commercial transaction surface (orders, credits, reservations, ledger entries, refunds, recognitions), not coach compensation structure.
Path 1 (absorb into Revenue section at per-coach × per-week grain) would create the same permanently-stuck not_started situation in Revenue's section that Coaching's review correctly flagged for itself. Revenue does not have the source data. Accepting path 1 would mean Revenue's mart section is responsible for computing a metric it has no schema backing for.
Path 2 (cross-warehouse carve-out with Revenue reading from Coaching) does not resolve the gap: the coach rate or revenue-share percentage does not live in Coaching's schema either, per Coaching's own filing. There is no warehouse to read from.
Revenue's position: coach_revenue_share_pct should be treated as a spec gap alongside coach_nps. No domain owns the underlying data today. The right disposition is to mark it as a Platform-pending spec clarification with Them OS rather than assigning it to Revenue's section and creating an entry that will never advance past not_started. If a coach-compensation configuration surface lands in a future domain, that domain is the right owner; the registry can pick it up at that point.
Revenue is not blocking Them OS escalation on this one and would actively support a spec-gap flag rather than a misrouted ownership assignment.