# V3 Store Rejection Contingency

Plan id: `v3-store-rejection-contingency.v1`

Owner: V3 Release Captain, joint with the platform-release engineer for the
affected store

Companion gates: `V3/CROSS_PLATFORM_CERTIFICATION.md` (final approval
evidence), `V3/TIER_ROUTER_DECISION_DISTRIBUTION.md` (tier share data),
`V3/MARKETING_PUBLIC_WEB.md` (status page and listings),
`V3/runbooks/day0-patch-pipeline.md` (resubmission build path)

This plan answers one question before it is needed: **if a store rejects or
delays a build in the final days before GA, do we slip, decouple, or ship
partial-platform?** The answer is pre-computed below per platform so the
GA-week decision is a lookup, not a debate.

## Ground Truth: How Much of Launch Each Store Carries

From the §66.8 tier-router decision distribution (validated synthetic device
mix routed through the real BFF resolver):

| Tier                     | Share | Store-dependent?                          |
| ------------------------ | ----- | ------------------------------------------ |
| `tier_3_pixel_streaming` | 34%   | No — browser, no store involved            |
| `tier_4_native`          | 26%   | Yes — all native installs come via stores  |
| `tier_2_webgpu`          | 22%   | No — browser fallback                      |
| `tier_1_webgl`           | 14%   | No — browser fallback                      |
| `tier_0_static`          | 4%    | No — static landing                        |

**74% of expected launch traffic reaches V3 through the browser with no store
in the path.** Within the 26% native share, the synthetic mix weights are
desktop-native 230 and Quest-VR 30 (of 260 native weight), i.e. roughly 23% of
all sessions are desktop native and ~3% are standalone-VR native. No single
store rejection can block a majority of launch traffic; the web tiers are the
structural hedge.

## Per-Platform Decoupling Decision Matrix

"Web fallback" means the tier router (`/api/v3/lilith/launch`) already routes
the affected device class to Pixel Streaming or WebGPU/WebGL fallback — no
code change required, only listing/comms changes.

| Platform (store)                  | Expected share carried             | Fallback if rejected                                              | Can GA proceed without it? | Pre-decided call                                                                 |
| --------------------------------- | ---------------------------------- | ----------------------------------------------------------------- | -------------------------- | -------------------------------------------------------------------------------- |
| Apple App Store (iOS/iPadOS)      | Part of native 26%; iOS-native is a minority of it — most mobile traffic already routes pxstream (`mix-pxstream-mobile-h264`, 4%) or web tiers | Safari Pixel Streaming + web tiers, full functionality at lower fidelity | **Yes — explicitly.**       | Decouple. GA on schedule; iOS native listed "coming soon"; deep links degrade to web. |
| Google Play (Android)             | Same shape as iOS                  | Chrome/WebView pxstream + web tiers                               | Yes                         | Decouple. Same treatment as iOS.                                                  |
| Apple visionOS (Vision Pro)       | <1%                                | None (no meaningful web path)                                     | Yes                         | Decouple silently; remove from launch comms.                                     |
| Mac App Store (Apple silicon)     | Small slice of desktop native      | Desktop browser pxstream (AV1 path is the largest single case in the mix) | Yes                  | Decouple. Mac users get full web experience.                                     |
| Meta Horizon (Quest 3 / Pro)      | ~3% (Quest-VR native)              | Quest browser WebXR — degraded, not equivalent                    | Yes, with VR-deferred comms | Decouple; publish a VR-availability date within 7 days of GA.                    |
| Sony PSN (PSVR 2)                 | Small console-VR slice             | None on PS5                                                       | Yes                         | Decouple; coordinate with Sony on revised release date before any public comms.  |
| Steam (Win64 + SteamVR)           | Largest native channel (desktop ~23%) | Epic Win64 build (same artifact class) + desktop web tiers      | Yes if Epic is approved     | Decouple **only if** Epic Win64 is approved; otherwise see two-store rule below. |
| Epic Games Store (Win64)          | Redundant with Steam               | Steam Win64 + desktop web tiers                                   | Yes if Steam is approved    | Decouple.                                                                         |
| Companion mobile (iOS + Android)  | Convenience surface, no tier share | Mobile web deep links                                             | Yes                         | Decouple; companion is never GA-blocking.                                        |

**Two-store rule (the only hard coupling):** Steam and Epic are mutual
fallbacks for the desktop-native channel. If **both** Win64 storefronts are
blocked at GA-minus-2-days, desktop native (~23% of sessions) has no install
path; pxstream absorbs the demand only if POP headroom covers the shift —
check `V3/pxstream/pop-capacity-dashboard.json` for ≥25% quota headroom on
`us-east-1`, `us-west-2`, and `eu-west-1` before deciding. With headroom: GA
proceeds web-first. Without headroom: slip (see criteria below).

## Resubmission Turnaround Expectations

Planning numbers for the GA-week decision clock; the platform-release
engineer owns keeping these current with each store's actual behavior:

| Store               | Standard re-review after rejection | Expedited path                                                  | Plan-for number |
| ------------------- | ---------------------------------- | ---------------------------------------------------------------- | --------------- |
| Apple App Store     | 24–48 h                            | Expedited review request (use sparingly; one ask per incident)   | 3 days          |
| Google Play         | hours–48 h (up to 7 days worst)    | None formal; staged-rollout updates re-review faster             | 3 days          |
| Meta Horizon        | 5–10 business days                 | Partner-rep escalation for hotfix builds, 2–5 business days      | 10 days         |
| Sony (TRC re-cert)  | 5–10 business days                 | Pre-arranged day-0 patch window, 3–5 business days               | 10 days         |
| Steam               | 1–3 business days                  | None formal; Valve rep ping                                      | 3 days          |
| Epic                | 2–5 business days                  | Partner manager escalation                                       | 5 days          |

Implication: an Apple/Google/Steam rejection at GA-minus-3-days is usually
recoverable before GA; a Meta or Sony rejection at GA-minus-10-days or later
is **not** recoverable in time and the decoupling row above applies
automatically — do not burn release-captain attention re-litigating it.

## Rejection-Class Response Matrix

| Rejection class                                   | Response                                                                                                  |
| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Metadata / screenshot / listing asset             | Fix from `V3/public-web/app-store-listings.json` source of truth, resubmit same build same day.            |
| Technical (crash, perf, size)                     | Day-0 patch pipeline (`V3/runbooks/day0-patch-pipeline.md`); patch must fit `DAY0_PATCH_HEADROOM.md` budgets. |
| Policy/content (age rating, content descriptors)  | **Cross-platform hazard**: an IARC rating problem on one store likely invalidates the rating on Apple/Google too, and may contradict a region dossier (`V3/docs/regions/`). Escalate to legal + the region owner before resubmitting anywhere. |
| Payments / commerce policy                        | Escalate to Lilith-Commerce lead; check whether the finding implicates the same flow on other stores.       |
| Legal / IP claim                                  | Escalate to Lilith-Rights and legal owner; freeze marketing for the affected platform.                      |

## Comms Plan

- Owner: communications lead, with release-captain sign-off; templates live
  with the incident-communications operator action.
- Internal: rejection logged in the Operator Console within 1 hour of store
  notice (`operator.release.store_rejection.logged`), with platform, class,
  and the pre-decided call from the matrix above.
- Public, decoupled platform: listing page and `/v3/landing` store-readiness
  section switch the platform to "coming soon"; status page (`/status`) stays
  green — a store delay is not a service incident. No public mention of the
  rejection reason without legal sign-off.
- Affected pre-registered users (store pre-orders / platform waitlist): e-mail
  within 24 h offering the web path with a one-tap pxstream join link.
- Marketing: all creative mentioning the affected platform is pulled before GA
  push; never advertise an install path that 404s.

## Slip-GA vs Ship-Partial Criteria

Ship partial-platform (the default) when ALL of:

- web tiers (74% of traffic) are unaffected,
- at least one Win64 storefront (Steam or Epic) is approved OR pxstream
  headroom ≥25% on the three large POPs covers the desktop-native shift,
- the rejection class is platform-local (not a policy/legal finding that
  invalidates a region dossier or rating across stores),
- paid commitments (ticketed Saraswati events, instructor schedules) are
  deliverable on the remaining platforms.

Slip GA (release captain decision, executive approver informed) when ANY of:

- both Win64 storefronts blocked AND pxstream headroom <25% on `us-east-1`,
  `us-west-2`, or `eu-west-1`,
- a policy/content rejection invalidates the age-rating or compliance basis of
  any wave-1 region dossier — region integrity outranks the calendar,
- platforms carrying a combined ≥40% of expected sessions are blocked,
- a legal/IP rejection raises a claim that plausibly applies to the web
  surfaces too.

The slip decision is recorded via the `release-readiness-decision` operator
action; the rollout token is revoked and GA moves to blocked until the matrix
re-evaluates green.

## Fail-Closed Criteria

This contingency is GA-blocking when any of the following holds:

- any platform in `V3/CROSS_PLATFORM_CERTIFICATION.md` lacks a row in the
  decoupling matrix;
- the two-store rule's POP headroom check has no current reading from the
  pop-capacity dashboard;
- comms templates for the decoupled-platform path do not exist;
- the rejection log audit event is not wired in the Operator Console;
- the matrix has not been reviewed by the release captain within 14 days of
  the GA date.