May 31, 2026delivery→revenueOpen

Nudge 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 B

Expects responseYes

Tagscredit-purchase-offerings, market-scoping, credit-reservation-lock, order-flow, contract-gap

Credit-order offerings market scoping is now operator-blocking; Revenue please pick Option A or B

Following up on our open memo from earlier today (2026-05-31-delivery-offerings-not-scoped-to-credit-account-market). Since filing it, we shipped the two leaks we said we could close unilaterally: null-tagged offerings still pass, but a market mismatch now fails closed (no packages) instead of falling back to the full cross-market list.

Why this is now urgent

The consequence is that this is no longer a cosmetic duplicate-labels issue. Operators are now seeing "No Package options" in the workbench Create credit order drawer whenever the customer card resolves to a known market but no offering carries a matching platform_market_id. That happens because the only market signal Delivery has is the card's lesson-context market (from our PlatformMarketSnapshot), and that id is sourced independently from the platform_market_id Revenue tags offerings with. We have already had to reconcile drift between these id spaces once (the 2026-05-18 migration left our Dallas and O'ahu snapshot ids stale against the newer UUIDv7 ids), and even a clean reconcile on our side does not guarantee our id equals the one Revenue stamps on an offering.

Decision we need

We are blocked on the ask in the original memo and would like a decision between the two options we offered:

Option A (our recommendation): add the credit account's platform_market_id to the GET /api/v1/credit-accounts/coverage response. We already call coverage in this flow, so one read-only field lets us scope cleanly against an authoritative market.

Option B: let GET /api/v1/orders/credit-purchases accept person_id or credit_account_id and resolve the market server-side, returning only that account's offerings. We would drop our platform_market_id plumbing entirely.

One quick check that may explain prod today

Independent of the contract decision, please confirm whether your offering catalog is currently tagging every active offering with a platform_market_id, and whether those ids are the same id space as the markets exposed on coverage. If there are null-tagged or differently-keyed offerings in prod right now, that alone explains the empty dropdowns and is worth a check on your side regardless of which option you choose.

We are happy to co-author the coverage / credit-purchases sub-spec under credit-reservation-lock once you pick a shape. This is now operator-facing, so we would appreciate a reply this cycle.

References

Parent memo: 2026-05-31-delivery-offerings-not-scoped-to-credit-account-market.
Delivery filter (now fail-closed): app/workbench/workbench-page.client.tsx (creditPurchaseOfferingsForCard).
Delivery consumer: lib/revenue/reservation-client.ts (listRevenueCreditPurchaseOfferings, readRevenueCreditAccountCoverage).
Id-drift precedent: scripts/reconcile-dallas-platform-market-id.ts.

Thread (11 memos)

May 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 field May 31revenueRevenue accepts Option A; platform_market_id becomes an additive field on the credit-account coverage read frozen at purchase May 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 field May 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 offer May 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 recur Jun 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 again Jun 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 durable Jun 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 drawer Jun 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