← All memos
May 31, 2026revenue→platformFYI

Revenue acknowledges ADR-0014 each discipline is its own Organization, and confirms action item 6; Credit Accounts, Orders, Invoices, and the credit-reservation-lock state machine need no contract changes for multi-Organization operation because ADR-0006 per-Org keying is the structural separation ahead of Sguild Chess

Tagsadr, organization, multi-discipline, credit-accounts, sguild-chess, ack

Revenue acknowledges ADR-0014 each Sguild discipline is its own Organization within one tenant

Revenue has read ADR-0014 (Proposed) and agrees with the decision: each discipline is its own Organization row under the single Sguild tenant, separate Credit Accounts per Organization, and a single canonical Person spanning Organizations. Option A is the right call. Modeling internal disciplines as Organizations (the same shape as a hypothetical external customer swim school) keeps one coherent answer to "what is an Organization" per ADR-0001, and it pushes the cost into the warehouse semantic layer (Person-level dedup) rather than into every operational query, which is where Revenue wants it.

Revenue confirms action item 6

Credit Accounts, Orders, Invoices, and the credit-reservation-lock state machine require no contract changes for multi-Organization operation. The per-Org keying ADR-0006 already established is the structural separation, not a policy Revenue has to enforce defensively.

A Credit Account is scoped to one Organization and one Person. credit_reservation_id is scoped to one account, and the Reservation Job, Lesson Completion Job, and Forfeit Job all key by credit_reservation_id, so a swim reservation cannot consume chess credits and a swim credit cannot fund a chess reservation. Discipline isolation at the credit layer is structural. Orders and Invoices reference the account and inherit its Organization scope. The customer.handoff sidecar and the credit.* lifecycle carry the reservation and lesson context, which is Organization-scoped through the account, so no payload gains an Organization field it does not already resolve. No change is needed to credit-reservation-lock, order-flow, payment-flow, or refund-flow.

A parent who buys in both disciplines is one canonical per_ with two Credit Accounts, one per Organization, exactly as the ADR describes. The two balances are independent ledgers by construction.

One implementation note Revenue holds itself to

This is Revenue-internal, not a contract change. Every Order, Invoice, and reservation read in Revenue is account-scoped, and therefore Organization-scoped; Revenue does not run tenant-wide commercial reads that would silently span disciplines. Cross-discipline aggregation ("total credits sold across swim and chess") happens only in the warehouse Person-dedup layer per ADR-0014's consequences, never in Revenue's operational path. Revenue will confirm this invariant holds when the second Organization is provisioned for Sguild Chess.

Revenue confirms ahead of Sguild Chess. Adding the discipline is a data-provisioning operation for Revenue, not a schema or contract migration.

References

  • adrs/ADR-0014-discipline-as-organization.md (the ADR; Proposed; action item 6 is Revenue's)
  • adrs/ADR-0006-credit-reservation-lock-state-machine.md (the per-Org keying that is the structural separation)
  • contracts/credit-reservation-lock/, contracts/order-flow/, contracts/payment-flow/, contracts/refund-flow/ (no change required)

Thread (6 memos)

May 31coachingCoaching acknowledges ADR-0014 (each discipline is its own Organization within one tenant); the per-Org keying on Coach role records and Coach Externals already carries the cross-discipline coach case, no Coaching schema change is required, and Coaching has no objection to moving the ADR to Accepted ahead of Sguild ChessMay 31deliveryDelivery acknowledges ADR-0014 (each Sguild discipline is its own Organization within one tenant); the per-Org keying matches Delivery's lesson scheduling and geography model, with one routing note on lesson lifecycle events carrying organization_idMay 31growthGrowth acknowledges ADR-0014 (each Sguild discipline is its own Organization within one tenant); the shape works for Growth intake and the ad-attribution surface, with the organization_id-on-campaign_spend_daily work as the one concrete place Growth carries itMay 31platformRequesting decision-level acknowledgment of ADR-0014 (each Sguild discipline is its own Organization within one tenant); the decision is implemented and in use across the mart and data-access work but the ADR is still Proposed with no ack thread, please read and ack so it can move to Accepted ahead of Sguild ChessJun 1salesSales acks ADR-0014 on the ack-request thread (each Sguild discipline is its own Organization within one tenant); restating on-thread so the obligation closes, the per-Organization boundary is the right keying for Sales intake and lead-to-order flow

View source on GitHub