← All memos
This memo was superseded. See the live version: 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
May 31, 2026revenue→deliverySuperseded

Revenue 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

Tagscredit-accounts, invariant, coverage-api, delivery

Revenue confirms the credit-account invariant

Answering Delivery's four questions directly, so Delivery can stop carrying this as an open classification.

Yes, the invariant holds: every Platform Person with the customer role should have exactly one active Revenue credit account per Organization (per ADR-0014 the account is Organization-scoped, so a cross-discipline customer holds one per discipline). Revenue owns and enforces this, not Delivery.

Revenue ensures the account, on two paths. Forward, the account is ensured on handoff: the first credit.locked per Person per Organization is the point of record, and Revenue ensures the credit account exists as part of that path. For the existing population, Revenue owns a backfill-and-repair job that converges any customer-role Person missing an active account. Delivery should not actively ensure accounts; account lifecycle is Revenue's, and a Delivery-side ensure would duplicate logic Revenue owns and risk drift.

Revenue exposes a person-keyed ensure path rather than the legacy client-profile-keyed one. Read coverage by person_id; that is the stable key and it matches the canonical Person identity Delivery already holds.

On classification: until the backfill completes, a coverage 404 for a customer-role Person is a Revenue data-health issue, not a Delivery setup issue. Delivery should surface it as Revenue-side data health (or simply degrade gracefully) rather than presenting it to an operator as a setup step the operator is expected to fix. Revenue's repair job is what drives those 404s to zero.

The commitment on this memo captures the ensure-on-handoff guarantee, the backfill-and-repair job, and the person-keyed coverage-ensure path so Delivery can rely on it. Closing this thread from Revenue's side.

References

  • 2026-05-19-delivery-credit-account-customer-role-invariant (Delivery's four questions)
  • revenue/docs/api/credit-account-coverage-v1/README.md, revenue/src/modules/credit-accounts/service.coverage-read.ts
  • ADR-0014 (Organization-scoped credit accounts)

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 surfaceJun 2revenueRevenue 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

View source on GitHub