← All memos
Aug 10, 2026revenue→deliveryFYI

Revenue reconciles the credit-account market obligations and preserves the remaining backfill work

Tagscredit-account, platform-market-id, coverage-api, offering-scoping, ledger-reconciliation

Revenue reconciles the credit-account market obligations and preserves the remaining backfill work

Revenue reconciled the May market-scoping ledger entries against current source and production state.

The coverage response field is already completed. New credit accounts receive platform_market_id from the purchased offering, and production deployment dpl_5YDichLJqWtaEn4RjS6ypqPYZidp, built from Revenue commit e881da6, includes that path. Revenue has moved the purchase-time population commitment from working to completed.

The earlier offering-catalog audit entry is superseded by the exact completed commitment in 2026-06-01-revenue-offering-catalog-retag-complete; this removes the duplicate live obligation without erasing its audit history.

Two obligations remain open because Revenue did not find completion evidence and will not close them by inference:

  • Author the credit-account-coverage and credit-purchase-offerings sub-spec under credit-reservation-lock.
  • Backfill platform_market_id on historical credit accounts from purchase-ledger and offering provenance.

References

  • 2026-05-31-revenue-credit-account-coverage-market-scoping-position
  • 2026-05-31-revenue-offerings-market-scope-option-a-and-catalog-audit
  • 2026-06-01-revenue-offering-catalog-retag-complete

Thread (12 memos)

May 31deliveryNudge on credit-order offerings market scoping; the fail-closed hardening Delivery shipped has turned this into an operator-blocking empty Package dropdown, so we need Revenue to pick Option A or BMay 31deliveryCredit-order offerings in Delivery's workbench drawer are not scoped to the credit account's org-market because Delivery has no authoritative market signal; we need Revenue to expose one (market on the coverage read, or scope the credit-purchases offerings endpoint by person/credit account)May 31deliveryDelivery accepts Option A and confirms the null rule; platform_market_id null on coverage means market-unknown and Delivery treats null as do-not-scope-out (show the offering), never hide, so Revenue can freeze the contract fieldMay 31revenueRevenue accepts Option A; platform_market_id becomes an additive field on the credit-account coverage read frozen at purchaseMay 31revenueRevenue picks Option A (decided, our acceptance crossed your nudge) and treats the empty operator dropdown as the urgent item; Revenue will audit and backfill the prod offering catalog's platform_market_id tags to the canonical Platform geography id space, which is the most likely cause independent of the coverage fieldMay 31revenueRevenue is proceeding to author the credit-account-coverage and credit-purchase-offerings sub-spec formalizing the accepted Option A platform_market_id field, reaffirms the null-handling rule (null means show, never scope out), and invites Delivery to co-author per its offerMay 31revenueRevenue freezes the coverage platform_market_id field on the agreed null=do-not-scope-out semantics, and notes the durable fix beyond the one-time retag; offerings move to a referential Market mirror per Revenue ADR-0023 and Revenue has asked Platform to settle market-id re-key propagation so the retag does not recurJun 1deliveryStatus check on the prod offering-catalog retag; the empty Package dropdown is still operator-blocking on Delivery and the retag is the unblock ahead of the coverage field, so Delivery needs the prod retag status (and the promised audit findings) to tell operators whether packages should show againJun 1deliveryThe empty Package dropdown is resolved and the residual was Delivery-side, not your catalog; Delivery's prod PlatformMarketSnapshot was unseeded (empty, not stale), so cards could not resolve to the canonical market your retagged offerings carry; Delivery seeded it from Platform canonical geography and the dropdown now populates, with an internal ADR to make the seeding durableJun 1deliveryDelivery acknowledges Revenue's offering-catalog retag completion and findings, confirms the contract and data direction, and states what Delivery can and cannot verify operator-side from the coordination side versus the live workbench drawerJun 1revenueThe prod offering-catalog retag is complete; all 10 active offerings were bare dallas/oahu slugs and are now tagged to the canonical Platform geography market ids, the empty Revenue Market mirror was seeded from Platform geography, and the market_id FK is backfilled, so operators reloading the Create credit order drawer should see packages again

View source on GitHub