Oshun Platform · Planning

V1 Risk Register

every launch-gate meeting).

4sections15 minread3tables

On this page

Status: living document. Created 2026-06-12 to close the gap identified in V1_V7_PLAN_SET_AUDIT_2026-06-12.md §6.1(5) and §6.2 (V1). Companion documents: CAPACITY_MODEL.md, CRYPTO_REGULATORY_REVIEW.md, CHILD_SAFETY_COMPLIANCE.md, SLO_AND_DR.md, LAUNCH_TIMELINE.md.

Rating scales#

Likelihood (L), per launch-year horizon

L Meaning
1 < 5 % chance
2 5–20 %
3 20–50 %
4 50–80 %
5 > 80 % / near-certain

Impact (I)

I Meaning
1 Negligible; absorbed inside error budget
2 Minor: SLO dent, < $10k unplanned cost, single-surface degradation < 1 day
3 Material: multi-day degradation, $10k–$100k, single-tenant data issue, launch-feature gating
4 Severe: launch slip ≥ 30 days, multi-tenant incident, regulatory inquiry, $100k–$1M
5 Existential-class: payments shutdown by regulator, child-safety incident, physical-harm event, > $1M

Score = L × I. ≥ 12 = RED (mitigation mandatory before GA, reviewed at every launch-gate meeting). 6–11 = AMBER (quarterly review, mitigation funded). ≤ 5 = GREEN (monitor).

Owners are roles, not names; the Launch Director maintains the role→person map.


Register#

R-01 — RunPod GPU unavailability at launch — VENDOR — L4 × I4 = 16 RED#

Living Scenes' only V1 backend is chained-clip generation on GPU workers (V1/features.md:4427-4432); RunPod is the only GPU cloud named (V1/DEPENDENCIES.md:255,559). H100 spot/secure capacity is routinely oversubscribed at exactly the moment a launch needs to scale.

  • Mitigation (concrete failover):
    1. Committed primary capacity: reserve 60 % of the modeled design-point fleet (78 of 130 H100, CAPACITY_MODEL.md §3) as RunPod Secure Cloud committed instances for launch quarter; remainder on-demand.
    2. Alternate provider = AWS EC2 P5 (H100) — AWS is already the primary cloud with IAM/VPC/S3/Secrets paths in place (V1/DEPENDENCIES.md §20), so no new vendor integration is needed. Hold 20 % of modeled peak (26 GPUs) as warm capacity via an EC2 Capacity Block spanning launch week: images pre-pulled, workers registered in the Conductor worker pool in drained state, promoted by one config flip.
    3. The carry-state protocol is node-portable by spec (no node-bound latents, V1/features.md:3728-3732) and provider failover is per-segment and user-transparent (V1/features.md:3740-3742), so failover requires no session migration logic beyond what the spec already mandates. Failover is drilled in load test LT-5 (CAPACITY_MODEL §7).
    4. Determinism constraint: failover nodes must run the identical SKU/driver/CUDA/container digest (see R-08).
  • Trigger indicators: RunPod API error rate > 2 % over 10 min; pod-provision p95 > 120 s; realized fleet < 90 % of target for 15 min; RunPod status-page incident.
  • Owner: SRE Lead (infrastructure) + Generation Platform Lead (Yemaya).

R-02 — ElevenLabs / ASR vendor outage — VENDOR — L3 × I3 = 9 AMBER#

ElevenLabs is the named voice-synthesis provider for Tara teachers, Metis tutors, and Living Scenes narration (V1/DEPENDENCIES.md:260); Psyche's voice budgets (V1/features.md:2218-2228) cannot be met without a live TTS/ASR path.

  • Mitigation — Psyche degradation ladder (instantiates the spec'd fallback chain avatar+voice → voice → text, V1/features.md:2239-2246):
    • Stage 0 (normal): ElevenLabs primary TTS via the provider adapter (libs/isis/ai-providers/.../elevenlabs-provider.ts).
    • Stage 1 (provider failover, no mode change): route TTS to the secondary provider (OpenAI speech APIs, authorized per V1/DEPENDENCIES.md:235) through the voice-provider abstraction (libs/oshun/persona-registry/src/voice-provider-abstraction.ts). Entry: 2 consecutive synth failures on a session, or fleet-wide first-chunk p95

      1.5 s for 5 min.

    • Stage 2 (voice → text): spec fallback with user-visible disclosure and "thinking" indicator within 200 ms (V1/features.md:2226-2228). Entry: both TTS providers failing, or ASR unavailable.
    • ASR leg: failover to self-hosted Whisper-class ASR (large-v3 on 2 warm GPUs borrowed from the render fleet — planning assumption adopted 2026-06-12; sized at 2 GPUs because ASR fallback only needs to cover text-upgrade-eligible sessions, not full fleet concurrency) at degraded latency, else text-input mode.
    • Stage 3 (recovery): automatic upgrade attempt after stable interval per spec (V1/features.md:2245-2246).
    • Contracted ElevenLabs concurrency ≥ 1.5× modeled peak voice sessions (CAPACITY_MODEL §4) so a partial brownout is absorbed before the ladder engages.
  • Trigger indicators: provider 5xx > 1 % over 5 min; synth first-chunk p95 breach; ElevenLabs concurrency utilization > 85 % of contract.
  • Owner: Realtime Lead (Psyche).

R-03 — Anthropic / model-provider price or availability shock — VENDOR — L3 × I4 = 12 RED#

Anthropic is the primary LLM for assistant, Sophia synthesis, Metis tutoring, Lilith policy guards, and agentic AI (V1/DEPENDENCIES.md:234) — a single vendor under five load-bearing surfaces. Shock scenarios: ≥ 50 % effective price increase, deprecation of the pinned model, capacity rationing (429/529), or regional restriction.

  • Mitigation:
    1. The Isis provider abstraction (libs/isis/ai-providers/) already isolates the vendor; keep evaluated fallback routes warm: OpenAI alternate endpoint (V1/DEPENDENCIES.md:235), Azure OpenAI swap-in (:561), Vertex AI supplemental (:560). "Warm" = monthly gold-set parity runs per surface so switching is a config change with a known quality delta, not a leap.
    2. Per-surface token budgets and metered billing caps (V1/features.md:5408-5411) bound runaway cost exposure to one billing cycle.
    3. Commercial: negotiate committed-use pricing with ≥ 90-day price-change notice before GA; treat absence of such terms as an open launch risk at the go/no-go gate.
    4. Safety decoupling: hard safety paths must not share the vendor failure domain (see R-18).
  • Trigger indicators: provider pricing/deprecation announcement; modeled LLM cost per DAU > 1.3× plan for 2 consecutive weeks; 429/529 rate > 0.5 %.
  • Owner: Governance Lead (Isis) + Finance Lead.

R-04 — Living Scenes GPU cost blowout — OPERATIONAL/FINANCIAL — L3 × I4 = 12 RED#

Modeled cost is ≈ $0.12 per paid 8-min scene and ≈ $0.03 per free 90-s scene at H100 $2.99/GPU-hr (CAPACITY_MODEL §5). Blowout vectors: missing the ≤ 6 s p50 segment budget (cost scales linearly with gen time), cache-hit shortfall, higher-than-modeled attach, and Live-Direction dwell loops (linger/recall extending sessions).

  • Mitigation:
    1. Tier caps are already spec'd (free ≤ 6 segments/≤ 90 s; paid ≤ 24 segments/≤ 8 min, V1/features.md:3803-3808) — enforce at the Conductor, not just the UI.
    2. Per-user daily render budget: free 5 scenes/day, paid 40/day (planning assumption adopted 2026-06-12; derived as ~6× the median expected daily sessions so genuine users never hit it).
    3. Cache enforcement: Nyx tonight-briefing materializes once per location-bucket (V1/features.md:4072-4074); kept-artifact MP4s cached 30 days post-share (V1/features.md:4196-4199); replays must never re-render when a valid cache exists.
    4. $/session-by-template dashboard with weekly Finance review.
    5. Kill criterion: blended GPU cost per active-Living-Scenes user-month

      $1.80 (3× model) for 2 consecutive weeks → free tier degrades to the reduced-motion offering (still-carousel + narration, V1/features.md:4444-4448) until unit economics recover; paid tier unaffected.

  • Trigger indicators: GPU-hours per 1k sessions > 1.5× model; fleet utilization < 50 % (waste) or queue-red state > 1 h/day (under-provisioning masking as cost control).
  • Owner: Generation Platform Lead (Yemaya) + Finance Lead.

V1 is crypto-primary, non-custodial, no-KYC at the payment layer (V1/features.md:5421-5427) with Monero in the catalog (V1/features.md:5497-5509). Scenarios: a state money-transmitter inquiry, an EU AMLR interpretation hostile to merchant privacy-coin acceptance, an exchange refusing swept funds, an OFAC enforcement action on a missed screen.

  • Mitigation: full analysis and per-region go/no-go gates in CRYPTO_REGULATORY_REVIEW.md. Headlines: per-region rail gating config (any rail disableable per region within 24 h); outside-counsel memo per launch region before that region's gate opens; sanctions screening at invoice issuance, payment confirmation, and sweep; blocked-property procedure for SDN hits; Monero disabled at launch for JP/IL/AE-resident billing.
  • Trigger indicators: regulator contact in any launch region; counsel advisory; off-ramp exchange refusing swept funds; any sanctioned-address screening hit.
  • Owner: General Counsel + Payments Lead.

R-06 — Metis institutional data incident — LEGAL/OPERATIONAL — L2 × I5 = 10 AMBER#

Metis carries rosters, gradebooks, integrity verdicts with evidence packs, and guardian roles (V1/features.md:1553-1578, :1246-1252) — education records under FERPA and state student-privacy laws. A cross-tenant leak or BYOM exfiltration is a company-defining incident.

  • Mitigation: tenant-isolation suite is launch-gating (tests/security/tenant-isolation/, V1/ARCHITECTURE.md:1237-1239); BYOM per-tenant sandbox with kill-switch effective ≤ 5 s (V1/features.md:1532-1546, :1590-1591); KMS encryption at rest (V1/DEPENDENCIES.md §24); evidence-pack access scoped to operators with the right scope (V1/features.md:1573-1575); breach-notification runbook with the state-by-state timeline matrix in CHILD_SAFETY_COMPLIANCE.md §8.
  • Trigger indicators: any cross-tenant test failure in CI (treat as Sev-1); BYOM abuse-pattern monitor quarantine event; anomalous bulk-export volume on a school tenant.
  • Owner: Metis Product Lead + Privacy Lead (DPO).

R-07 — BFF overload at launch — TECHNICAL — L4 × I3 = 12 RED#

A single BFF fronts every Oshun-side domain (V1/ARCHITECTURE.md:292) — the one chokepoint every launch-day request crosses.

  • Mitigation: HPA 4 → 16 pods at 800 RPS/pod design capacity (CAPACITY_MODEL §6); per-client rate limiting already spec'd at the BFF (V1/ARCHITECTURE.md:1069-1071); signup throttle is structural via the canary ramp (LAUNCH_TIMELINE Phase 3); waiting-room page engages at > 85 % saturation; load-shed order: experiments → recommendation candidates → nothing else (entitlement, auth, and safety paths are never shed). k6 spike test at 5× modeled peak is a beta-exit gate (LT-2, CAPACITY_MODEL §7).
  • Trigger indicators: BFF p99 > 800 ms for 5 min; pod CPU > 75 %; 5xx

    0.5 %.

  • Owner: Platform/BFF Lead.

R-08 — Determinism release gate unachievable on a mixed GPU fleet — TECHNICAL — L3 × I3 = 9 AMBER#

Pixel-equivalence within tolerance "on any approved GPU node" is a release gate (V1/features.md:3669-3672, :4193-4194). Cross-SKU kernels, driver and CUDA drift, and nondeterministic attention implementations are well-known reproducibility breakers.

  • Mitigation: define "approved node" narrowly — one SKU + driver + CUDA + container image digest per workflow class; nightly determinism eval renders the same Score+Envelope on N = 3 nodes (per spec eval, V1/features.md:4209-4212); failover capacity (R-01) must run the identical image on the identical SKU; tolerance pinned in Isis as per-frame SSIM ≥ 0.995 (planning assumption adopted 2026-06-12; chosen as the tightest threshold distilled video models reliably meet across same-SKU nodes — validated, and revised only via Isis gate review).
  • Trigger indicators: any nightly determinism eval failure; any driver or base-image change without a gate re-run.
  • Owner: Generation Platform Lead (Yemaya).

R-09 — Watermark channel-survival gate blocks share launch — PRODUCT — L3 × I2 = 6 AMBER#

Release of each share path requires 100 % recovery of at least one provenance signal per channel (V1/features.md:4231-4236), and the C2PA mint/verify SDK is explicitly an unclosed launch-readiness gap (V1/DEPENDENCIES.md §19).

  • Mitigation: the four-channel redundancy (visible mark, audio watermark, C2PA, attestation page) is the design defense; treat the attestation-page short-code as the guaranteed-recoverable floor; close the C2PA SDK gap before dogfood starts (LAUNCH_TIMELINE Phase 1 entry); run the channel-robustness eval weekly against current channel encoder behavior (WhatsApp/Telegram re-encodes change without notice).
  • Trigger indicators: any channel survival < 100 % in the weekly eval; a share-channel announces media-pipeline changes.
  • Owner: Provenance/Media Lead (Yemaya).

R-10 — Stablecoin issuer freeze of receiving addresses — VENDOR/FINANCIAL — L2 × I3 = 6 AMBER#

USDC and USDT issuers hold freeze authority, documented on the invoice surface (V1/features.md:5479-5481).

  • Mitigation: per-invoice addresses bind one customer payment each (blast radius = one invoice); sweep cadence at least daily above threshold keeps hot-address balances under ~2 days of revenue; DAI remains the no-freeze stablecoin alternative on every EVM rail (V1/DEPENDENCIES.md:427); incident path: re-invoice the affected customer on an alternate rail and grant the entitlement manually with audit.
  • Trigger indicators: any freeze event touching an Oshun address; issuer policy/blacklist-criteria update.
  • Owner: Payments Lead.

R-11 — iOS App Store rejection of the crypto paywall — PRODUCT/VENDOR — L4 × I3 = 12 RED#

Mobile paywalls render per-invoice crypto addresses/QRs and never redirect to a custodial processor (V1/features.md:5391-5394). Apple guideline 3.1.1 requires IAP for digital goods; an in-app crypto invoice for entitlements is a canonical rejection.

  • Mitigation: iOS build ships entitlement display only; purchase happens on web (reader-app pattern) or via the Telegram bot invoice surface (V1/features.md:5444); no purchase links or invoice rendering inside the iOS binary; App Review dry-run submission during private beta wave 2 with full reviewer notes; contingency: ship iOS with account-based entitlement sync only.
  • Trigger indicators: App Review rejection or guideline revision; Google Play policy drift (same mitigation applies).
  • Owner: Mobile Lead + Payments Lead.

R-12 — Air-gapped signing-station loss / keyholder dependency — OPERATIONAL — L2 × I4 = 8 AMBER#

Refunds and sweeps require cold signing through the air-gapped station with 2-of-3 multisig vaults per chain family (V1/DEPENDENCIES.md:433).

  • Mitigation: three keyholders across two physical sites plus one bank-safe-deposit backup share; quarterly signing drill that includes one simulated keyholder absence (must still complete a refund within SLA); recovery runbook versioned beside the payments-bridge code; customer-facing refund SLA of ≤ 5 business days holds even in a one-key-lost state.
  • Trigger indicators: failed or skipped quarterly drill; keyholder departure/role change; any vault descriptor mismatch at audit.
  • Owner: Payments Lead + Security Lead.

R-13 — Self-hosted node fleet sync failure at launch — TECHNICAL/OPERATIONAL — L4 × I2 = 8 AMBER#

V1 self-hosts eight chains' nodes (bitcoind, litecoind, monerod, Erigon, cardano-node, ergo-node, java-tron, TON; V1/DEPENDENCIES.md:394-419). Sync lag silently delays payment confirmation and therefore entitlement grants.

  • Mitigation: chain-tip lag monitor per chain (alert at > 2 blocks or

    2× nominal block time); weekly chain-data snapshots to S3 so a corrupted node restores in < 6 h instead of a multi-day resync (Erigon and cardano-node initial syncs are multi-day); multi-RPC N-of-M consensus fallback where the trust tier allows it (Tier B/C and Ethereum L1, V1/DEPENDENCIES.md:399,403-419); per-chain row on the public status page; invoice surface shows honest "confirmation pending" state rather than guessing.

  • Trigger indicators: tip-lag alert; N-of-M provider divergence; node process restart loops.
  • Owner: Payments Infrastructure Engineer.

R-14 — PSE/strobe or crisis-detector miss in continuous video — PRODUCT/SAFETY — L2 × I5 = 10 AMBER#

The rhythmic-pattern + strobe hard-kill is the physical-safety floor for Living Scenes (V1/features.md:4165-4169); a miss is a physical-harm event.

  • Mitigation: two independent detector implementations (ITU-R BT.1702-2 analyzer and a WCAG-2.x flash-threshold heuristic) — frames pass only if both pass; fail-closed: detector unavailability fades the stream to still; red-team fixture suite of known PSE-triggering clips runs per release; zero tolerance — any miss blocks release, consistent with safety regression blocking (V1/features.md:5367-5369).
  • Trigger indicators: any detector disagreement in production (one fires, one doesn't); any user report tagged photosensitivity; fixture-suite miss.
  • Owner: Safety Lead (Lilith).

R-15 — Locale-parity slip across the 8 launch locales — PRODUCT — L3 × I2 = 6 AMBER#

Launch locales are en-US, es-US, fr-FR, de-DE, ar, he, ja-JP, pt-BR (V1/features.md:2679-2680), with cue-policy semantic parity required across all of them (V1/features.md:3708-3711) and two RTL locales.

  • Mitigation: locale-parity evals sit inside workflow-class release gates (already spec'd); translation freeze at dogfood start; explicit decision point at beta wave 2 — a locale failing parity launches dark (locale gated off, features intact) by Product decision, never by silent descope.
  • Trigger indicators: parity eval failure for any locale; > 10 % of strings untranslated at T-30 before canary.
  • Owner: Localization Lead + Product Lead.

R-16 — Cloned-voice abuse / persona-rights incident — LEGAL/PRODUCT — L2 × I4 = 8 AMBER#

Cloned-voice abuse is a named adversarial eval class (V1/features.md:5363-5364); ElevenLabs-class cloning makes this cheap for attackers.

  • Mitigation: strict Lilith voice-abuse policy (V1/DEPENDENCIES.md:260); per-voice-profile consent records with share-out grants (V1/features.md:4318-4323); takedown cascade mutes retired voices across kept and shared artifacts with re-render offers (V1/features.md:4340-4343); audio watermarking on all outputs (V1/features.md:4222-4224).
  • Trigger indicators: voice-abuse report; adversarial-suite regression; rights-holder complaint.
  • Owner: Safety Lead (Lilith) + Rights Lead.

R-17 — Per-domain database provisioning gap — TECHNICAL — L4 × I2 = 8 AMBER#

V1/DEPENDENCIES.md §21 flags that ARETE_DATABASE_URL, VERITAS_DATABASE_URL, NYX_DATABASE_URL, and METIS_DATABASE_URL are not in .env.example. If these domains silently share oshun_dev in production, the DR data-class mapping (SLO_AND_DR.md §4) and isolation assumptions are wrong.

  • Mitigation: resolve before dogfood entry: provision per-domain databases
    • PgBouncer fronting (V1/ARCHITECTURE.md:1210-1211), document URLs in .env.example; add a CI check asserting every BFF-routed domain declares a database URL (or an explicit, documented shared-DB decision).
  • Trigger indicators: the CI check failing; any prod service connecting to oshun_dev outside the documented allowlist.
  • Owner: Platform Lead.

R-18 — Correlated failure of product and safety layer on one LLM vendor — TECHNICAL/SAFETY — L3 × I4 = 12 RED#

Lilith policy guards run on the same primary vendor as the product surfaces (V1/DEPENDENCIES.md:234). A vendor outage that takes down both generation and its safety checks invites "ship unchecked" pressure at the worst moment.

  • Mitigation: the hard safety paths — crisis-signal classification, cue pre-screen, PSE-adjacent checks — run on a locally hosted classifier tier (small model served from the render fleet; planning assumption adopted 2026-06-12 — sized at 2 inference replicas because cue/crisis classification is lightweight relative to video generation). Vendor outage may degrade quality, never safety. Fail-closed: if a policy check is unavailable, the cue is rejected / the generation refuses (consistent with the fail-closed norms across the spec, e.g. V1/features.md:4382-4383).
  • Trigger indicators: vendor-outage game day showing any hard safety path blocked on the external vendor; latency of local classifier tier > cue budget share.
  • Owner: Safety Lead (Lilith).

Summary heat map#

Score band Risks
RED ≥ 12 R-01, R-03, R-04, R-05, R-07, R-11, R-18
AMBER 6–11 R-02, R-06, R-08, R-09, R-10, R-12, R-13, R-14, R-15, R-16, R-17
GREEN ≤ 5 (none at register creation)

Maintenance#

  • Register reviewed at every launch-gate decision (LAUNCH_TIMELINE) and monthly thereafter; RED risks additionally reviewed at each canary promotion.
  • Every Sev-1/Sev-2 incident postmortem must either map to an existing risk (update L/I from observed reality) or add a new row.
  • Likelihood/impact re-scored with observed beta data at Phase 2 exit; assumptions labeled above are replaced with measurements as they land.