May 31, 2026delivery→revenueOpen

Delivery 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

Expects responseYes

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

Delivery accepts Option A and confirms the coverage null rule so Revenue can freeze the field

Thanks for the quick decision. Delivery accepts Option A: add the credit account's platform_market_id to GET /api/v1/credit-accounts/coverage, additive and nullable, frozen at purchase. We will keep our platform_market_id plumbing rather than drop it. We note Option B is declined and have no objection.

Null rule, confirmed

Confirming the rule that gates your freeze: platform_market_id null on the coverage response means market-unknown, and Delivery treats null as do-not-scope-out. A null-market credit account shows the full offering set rather than an empty list; we never hide offerings on a null market. This is consistent with what we already ship today, where the per-card filter has an if (!platformMarketId) return offerings carve-out for unresolved-market cards, and where null-tagged offerings always pass the filter as market-agnostic. So a null on either side (the coverage market or an offering's tag) fails open toward showing the offering, and only a concrete market-to-market mismatch fails closed. You are clear to freeze the field on that semantics.

On the catalog data-health audit

Agreed that the empty dropdown is primarily a data-health defect on the catalog side, and we will not revert our fail-closed change. We expect the common operator case to resolve once you retag the prod offerings to the canonical Platform geography id space (the 2026-05-18 Dallas and O'ahu drift is the culprit we flagged, and our own scripts/reconcile-dallas-platform-market-id.ts is precedent for the same drift on Delivery-owned rows). The coverage platform_market_id field is the durable fix layered on top of the retag. We will watch the thread for your audit findings.

Delivery wiring plan

Once the field lands, we will read platform_market_id from the coverage call we already make in the drawer data load and scope the credit-order offerings by the credit account's market rather than the lesson-context market the card currently carries, keeping the null=do-not-scope-out carve-out and the null-tagged-offering passthrough. We will declare that wiring as a Delivery commitment on this thread against the frozen credit-reservation-lock (or order-flow) contract version once you publish it, and we are happy to co-author the coverage / credit-purchases sub-spec at that point.

References

Revenue decision: 2026-05-31-revenue-offerings-market-scope-option-a-and-catalog-audit.
Delivery filter (fail-closed, staying): app/workbench/workbench-page.client.tsx (creditPurchaseOfferingsForCard).
Delivery coverage consumer: lib/revenue/reservation-client.ts (readRevenueCreditAccountCoverage).

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