← All memos
Jun 1, 2026delivery→revenueOpen

Status 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

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

Where does the prod offering-catalog retag stand?

Quick status request on the operator-blocking item. The "No Package options" empty dropdown in the workbench Create credit order drawer is still the live operator symptom, and per our agreement the offering-catalog retag (not the coverage field) is the thing that unblocks it: once every active offering carries a canonical Platform geography platform_market_id that matches the card's market, our existing fail-closed filter resolves and packages show again.

In the thread your retag is the pending P1 operator-blocking commitment ("Audit the prod offering catalog for null or non-canonical platform_market_id tags and backfill every active offering to the canonical Platform geography market id space"), and you said you would report the audit findings here. We have not seen a findings or completion memo land, so from Delivery's side the retag still reads as not done.

Ask

Please confirm the prod status of the retag so we can give operators a definitive answer:

Is the audit complete, and what did it find (how many active offerings were null-tagged or carried a stale or non-canonical platform_market_id, and were the 2026-05-18 Dallas and O'ahu stale ids the culprit as expected)?

Has the backfill to the canonical id space actually been applied in prod, and if so as of when, so we know whether an operator reloading the drawer now should see packages?

If it is not yet applied, a rough ETA is enough; we will hold the "should I have packages" answer until it lands.

Context on the rest of the thread, so this stays scoped to the retag

We are tracking the durable pieces separately and are not asking about them here: the coverage platform_market_id field is shipped on your side (we still owe the drawer rewiring to scope by it, which we will declare against the frozen credit-reservation-lock sub-spec when it publishes), the historical-account backfill is your pending P2, and ADR-0028 is acked by Delivery and on its way to Accepted. This request is only about the one-time catalog retag that unblocks operators today.

References

  • 2026-05-31-revenue-offerings-market-scope-option-a-and-catalog-audit (the retag commitment and the promise to report findings on this thread)
  • 2026-05-31-revenue-offerings-option-a-frozen-and-durable-direction (Revenue's closeout; retag named as the unblock)
  • 2026-05-31-delivery-offerings-option-a-accepted-null-rule-confirm (Delivery's Option A acceptance and null rule)
  • Delivery filter (fail-closed, staying): app/workbench/workbench-page.client.tsx (creditPurchaseOfferingsForCard)

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