# V2 Diagram Atlas This atlas is the visual orientation layer for V2. It condenses the product, runtime, durable records, lifecycle, module ownership, mode estate, production journey, and release order into complementary models. The focused feature and architecture pages remain authoritative for detail; current code, tests, builds, platform evidence, and operations determine support status. ## Product and runtime landscape ```mermaid flowchart TB Player[Player surfaces] --> Shell[Menus HUD accessibility and input] Shell --> Modes[Combat training replay events racing and world modes] Modes --> Sim[Integer-frame deterministic simulation] Sim --> GAS[GAS abilities effects and authored frame data] Sim --> Rollback[Rollback resimulation and replay] Modes --> Presentation[Animation camera audio VFX stages and broadcast] Modes --> Online[Identity matchmaking ranked tournaments and integrity] Online --> Services[Progression store community support and companion] GAS --> Data[(Roster moves balance modes and content versions)] Rollback --> Evidence[(Hashes replays receipts telemetry and audits)] Services --> Evidence Presentation --> Build[Cook patch platform certification and release] ``` V2 is one product spine with several peer experiences. The racing and open-world paths are not decorative side modes, but they still share identity, entitlements, content/version, telemetry, accessibility, and release controls with combat. ## Authoritative online match sequence ```mermaid sequenceDiagram actor P1 as Player one actor P2 as Player two participant Client as V2 client participant Online as Online services participant Server as Authority or peer coordinator participant Integrity as Integrity and replay P1->>Client: Queue with ruleset roster and region Client->>Online: Auth entitlement build and preferences P2->>Online: Compatible queue request Online->>Server: Allocate match and signed configuration Server-->>Client: Seed frame zero peers and policy loop Every simulation frame Client->>Server: Bounded input frame Server-->>Client: Confirmed frame and corrections Client->>Client: Predict rollback and resimulate end Server->>Integrity: Result hash replay and anomaly evidence Integrity-->>Online: Accepted held or disputed result Online-->>P1: Ranked progression and replay reference Online-->>P2: Ranked progression and replay reference ``` The exact authority model varies by mode. The invariant is that compatible content, signed configuration, deterministic input, result evidence, and idempotent progression are established before a competitive result is final. ## Durable competitive records ```mermaid erDiagram ACCOUNT ||--o{ PLATFORM_LINK : owns ACCOUNT ||--o{ FIGHTER_PROFILE : progresses ACCOUNT ||--o{ RANKED_ENTRY : earns SEASON ||--o{ RANKED_ENTRY : groups RULESET ||--o{ MATCH : configures CONTENT_VERSION ||--o{ MATCH : pins MATCH ||--|{ PARTICIPANT : includes ACCOUNT ||--o{ PARTICIPANT : controls MATCH ||--|| REPLAY : records REPLAY ||--o{ FRAME_HASH : verifies MATCH ||--o{ INTEGRITY_SIGNAL : produces MATCH ||--o{ RESULT_RECEIPT : settles RESULT_RECEIPT ||--o{ PROGRESSION_EVENT : emits ``` Account, fighter progression, season/rank, match participant, replay, integrity, and settlement identities remain separate. A replay can verify a match without being the progression ledger, and a provider receipt cannot be replaced by a client result screen. ## Match lifecycle ```mermaid stateDiagram-v2 [*] --> Assembling Assembling --> ReadyCheck: compatible build content and policy ReadyCheck --> Loading: all required participants accept ReadyCheck --> Cancelled: decline timeout or incompatibility Loading --> Active: frame zero and authority established Loading --> Cancelled: asset network or platform failure Active --> Paused: governed local or tournament pause Paused --> Active Active --> Recovering: disconnect or authority migration Recovering --> Active: bounded rejoin succeeds Recovering --> Abandoned: recovery budget expires Active --> Completed: terminal game state Completed --> Verifying: replay hashes and integrity checks Verifying --> Settled: result accepted idempotently Verifying --> Disputed: anomaly or version mismatch Settled --> [*] Disputed --> [*] Cancelled --> [*] Abandoned --> [*] ``` Lifecycle state must be durable enough to distinguish cancellation, abandonment, dispute, and settlement. Retry or reconnect cannot double-apply rank, rewards, challenge, or commerce effects. ## Shared and specialized module composition ```mermaid classDiagram class V2GameHost { activateMode() pinContentVersion() } class CombatSimulation { fixedFrame seed stepInputs() } class RulesetPlugin { rosterPolicy tagPolicy damagePolicy } class RacingSimulation { vehicleModel trackRules } class OnlineBoundary { authorize() allocate() settle() } class EvidenceEnvelope { replayRef hashRef auditRef } V2GameHost --> RulesetPlugin : activates V2GameHost --> CombatSimulation : hosts V2GameHost --> RacingSimulation : may host CombatSimulation --> OnlineBoundary : bounded by RacingSimulation --> OnlineBoundary : bounded by OnlineBoundary --> EvidenceEnvelope : emits ``` Shared hosting and evidence do not flatten ruleset or vehicle specialization. The host owns activation/version boundaries; each simulation owns its deterministic rules; the online boundary owns admission and settlement. ## Mode and surface estate ```mermaid mindmap root((V2 estate)) Combat Versus and ranked Tag and assist Training and replay Signature events Racing Vehicles and tracks Online racing Fighter-driver crossover Open-world activities Community Tournaments and esports Spectator and broadcast Creator suite Companion and support Platform Accessibility and localization Store progression and entitlements Telemetry and integrity Build certification and live operations ``` Use the estate to find the owning focused page; use the runtime landscape to trace shared dependencies. A feature may appear in several branches while still having one canonical data and authority owner. ## Production journey ```mermaid journey title From V2 design change to supported release section Define Specify player contract ruleset and platforms: 5: Design, Product Update canonical data and compatibility rules: 5: Design, Engineering section Implement Change simulation presentation services and tools: 4: Engineering Add telemetry accessibility and recovery behavior: 5: Engineering section Verify Run determinism rollback balance and journey tests: 5: QA Validate performance cook security and certification: 5: Release, QA section Operate Stage cohort inspect evidence and roll back safely: 5: SRE, Release Publish docs patch notes and support guidance: 5: Owners ``` No one test substitutes for this journey. In particular, deterministic combat, online settlement, presentation, platform packaging, accessibility, and live operations have different evidence owners. ## Release evidence order ```mermaid timeline title V2 evidence progression Contract : Player promise and compatibility policy : Canonical authored data and schema Runtime : Deterministic simulation and presentation : Online authority persistence and providers Verification : Unit integration replay and end-to-end journeys : Performance accessibility security and balance evidence Candidate : Cook patch certification and support readiness : Staged rollout observability and rollback proof Supported : Named platforms modes regions and content versions : Current operational and regression evidence ``` The timeline is an ordering of evidence, not a calendar. A later artifact never retroactively supplies missing proof from an earlier boundary. ## How to use this atlas Start with the landscape and estate, follow a match through the sequence and state machine, use the ER and class models for data/contract reviews, and use the production journey and evidence order during release review. Continue to the [V2 guide](./README.md), [feature index](../features/README.md), and [architecture index](../architecture/README.md). The generated gallery links every additional diagram to its source page and heading.