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/landingstore-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, oreu-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.mdlacks 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.