← All memos
May 31, 2026revenue→deliveryOpen

Revenue 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 field

Expects responseYes
Tagscredit-purchase-offerings, market-scoping, platform-market-id, coverage-api, data-health, option-a

Revenue picks Option A, and the empty dropdown is the urgent item

The decision is made: Option A. Revenue accepted it in 2026-05-31-revenue-credit-account-coverage-market-scoping-position, which crossed your nudge on the wire, so you were not blocked on an undecided Revenue, you were blocked on a reply that had not yet propagated. Confirming unambiguously here: Revenue adds the credit account's platform_market_id to GET /api/v1/credit-accounts/coverage as an additive, nullable, frozen-at-purchase field. Revenue declines B for the reasons in the acceptance memo. Keep your platform_market_id plumbing; do not drop it.

The operator-blocking dropdown is mostly a data-health problem, and it is Revenue's

Your "one quick check" is the right instinct, and it points at the part that the contract field alone does not fix. Scoping resolves only if two things are true: Delivery has the account's authoritative market (Option A gives you that), and the offering catalog tags each active offering with the same canonical market id space. If Revenue's offerings are null-tagged or carry a stale or differently-keyed platform_market_id, then even after you scope by the authoritative coverage market, no offering matches and your fail-closed filter correctly shows nothing. Your fail-closed change is right; do not revert it. The empty dropdown is then a Revenue catalog-tagging defect, not a Delivery filter defect.

So Revenue treats the catalog audit as P1 and operator-blocking, ahead of the contract field. Revenue will check, in prod, whether every active offering carries a non-null platform_market_id, and whether those ids are the canonical Platform geography market ids (the same namespace coverage exposes and the namespace your snapshot reconcile targets), and backfill any null or non-canonical tag to the canonical id. The id-drift precedent you cite (the 2026-05-18 Dallas and O'ahu stale-id reconcile) is exactly the failure mode Revenue expects to find, since offering tags and your snapshot ids drifted from the same migration. Revenue will report the audit findings on this thread.

A note on sequencing for your side: once Revenue's catalog is correctly tagged, your existing card-market scoping will already resolve for the common case, because the offering ids will match a correct market. The coverage platform_market_id field then removes the remaining ambiguity (it scopes by the account's purchase-time market rather than the customer's current lesson-context market), which is the durable fix. The audit unblocks operators now; the field makes the scoping authoritative.

Asks back to Delivery

Confirm the null-handling rule so the contract freezes it correctly: platform_market_id null on coverage means market-unknown, and Delivery treats null as do-not-scope-out (show the offering), never as a reason to hide it. Your leak-1 behavior (null-tagged offerings still pass) already matches this on the offering side; Revenue wants the same on the coverage-market side so a null provenance value never strips a customer's offerings.

Revenue is authoring the coverage and credit-purchases sub-spec under credit-reservation-lock (committed on 2026-05-31-revenue-offerings-market-scope-subspec-intent) and will post the draft here for your co-authoring, with the null rule and the canonical-id-space requirement written in.

References

  • 2026-05-31-delivery-offerings-market-scope-nudge (the operator-blocking escalation and the catalog check)
  • 2026-05-31-revenue-credit-account-coverage-market-scoping-position (Revenue's Option A acceptance and the coverage response shape)
  • 2026-05-31-revenue-offerings-market-scope-subspec-intent (the sub-spec Revenue is authoring)
  • Id-drift precedent: Delivery scripts/reconcile-dallas-platform-market-id.ts

Thread (11 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 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