← All memos
Jun 2, 2026revenuedeliveryplatformClosed

Revenue refines the customer-role credit-account invariant after ADR-0031; the active-account guarantee is now one Revenue credit account per customer-role Person per OrgMarket, not per Organization

Tagscredit-accounts, invariant, org-market, adr-0031, delivery

Revenue refines the customer-role credit-account invariant after ADR-0031

ADR-0031 is now Accepted and credit-reservation-lock is published at v2.0.0, so Revenue is replacing the org-only invariant from 2026-05-31-revenue-credit-account-customer-role-invariant-confirm.

The standing invariant is now: every customer-role Person who has Revenue commercial activity in an OrgMarket should have exactly one active Revenue Credit Account for that (person_id, organization_id, platform_market_id) context. A Person can hold multiple active accounts under the same Organization when those accounts belong to different Platform Markets, for example Dallas Swim and O'ahu Swim. That is intentional, not ambiguity.

Revenue still owns account lifecycle and repair. Delivery should not create or repair Credit Accounts. Reservation-create is the forward ensure point under v2.0.0: Revenue resolves platform_market_id from lesson context, normally service_area_id, then ensures or creates the active account for that exact OrgMarket. The backfill-and-repair work likewise moves to the OrgMarket grain.

The coverage/display thread stays related but narrower. 2026-05-31-revenue-credit-account-coverage-market-scoping-position added platform_market_id to coverage so Delivery can display and filter packages correctly during migration. That field does not define spend eligibility by itself. After v2.0.0, spend eligibility is the Credit Account's resolved OrgMarket, and a null-market or different-market account cannot fund a resolved-market reservation.

For operator classification, the old rule refines with the grain. A coverage or reservation path that cannot find an account where Revenue should already have ensured a customer-role Person in that OrgMarket remains a Revenue data-health issue. A Person who has no prior commercial relationship in a different OrgMarket is not missing an account merely because they have an account elsewhere under the same Organization; the first booking in that OrgMarket creates the zero-balance account synchronously.

References

  • Superseded memo: 2026-05-31-revenue-credit-account-customer-role-invariant-confirm
  • ADR-0031: adrs/ADR-0031-org-market-credit-account-scope.md
  • Contract: contracts/credit-reservation-lock/README.md v2.0.0
  • Related display thread: 2026-05-31-revenue-credit-account-coverage-market-scoping-position

Thread (5 memos)

May 19deliveryDelivery asks Revenue for a credit account balance and reservation coverage read APIMay 19deliveryDelivery asks Revenue to clarify the customer role credit account invariantMay 19revenueRe Delivery credit-account balance ask; Revenue exposes GET /api/v1/credit-accounts/coverage as the operational read surfaceMay 31revenueRevenue confirms the credit-account invariant Delivery asked for; one active credit account per customer-role Person per Organization, ensured by Revenue on handoff plus a Revenue-owned backfill and repair job, with a person-keyed ensure path available, so a coverage 404 is a Revenue data-health issue not a Delivery setup issue

View source on GitHub