Unit Data Schema — Topic 04: Deck / Band / Card-Roster — Omega War

Author the deck-authoring layer: the Deck entity (a faction's playable card pool), the deployment Band A/B/C that groups a deck's cards by command-post tier, the card-roster join that places each card into a band, and the command-post unlock surface that opens a band in-battle. Then resolve the deck join topic 03 deferred: how the deck-side deployment band relates to the in-match phase_band.

A deck is the player's faction-and-division-scoped pool of cards taken into a match — the deck-builder unit of selection above the individual card. Source: roster §6.2 (per-deck card-roster table, one row per playable deck) and §8 (every deck row states a status).

DeploymentBand ∈ {A, B, C} — the deck-authoring grouping that sorts a deck's cards by which command-post tier unlocks them in battle. Source: roster §6.1 (band contract) — the deck-side A/B/C ladder, named Vanguard / Main Body / Commitment.

The roster is not a bare list of card refs — each entry slots a card into a deployment band within a deck and records its eligibility flags. This is the join that makes "the deck × band × card" relationship explicit. Source: roster §6.2 (cards grouped by band per deck) + §6.3/§8 (wonder eligibility).

The same card can appear in different decks at different bands (a TD card that is Band B for an armor deck but an attachment for an infantry deck), so band is a property of the entry, not of the card. Card-level fields (era_band, phase_band, phase_min from topics 01/03) stay on the card; the entry adds the deck-scoped band placement on top.

CommandPost — the in-battle unlock surface

Command-post surfaces are the in-battle structures whose unlock opens a deployment band's cards. Source: roster §7.1 (naming — "Forward Command Post" as the umbrella, concrete wartime facility names beneath) and §7.2 (the unlock mapping).

The reconciliation topic 03 deferred. Two A/B/C ladders touch the same deck: phase_band (topic 03, on the card) — the in-match escalation window (Recon / Frontline / Breakthrough), a card-intrinsic property; and deployment_band (this topic, on the CardRosterEntry) — the deck-side grouping (Vanguard / Main Body / Commitment), a deck-scoped, command-post-gated property.

Model: two related-but-distinct gates that compose (logical AND). A card in a deck becomes deployable when both (1) the match's phase window has reached the card's phase_band (respecting its phase_min floor, topic 03 §2.1), and (2) the command-post surface for the entry's deployment_band is unlocked in-battle. They are correlated — authors put Recon-window cards in Vanguard and Breakthrough-window cards in Commitment, and CP escalation tracks phase escalation — but not the same field: phase_band is intrinsic to the card and gated by the match clock; deployment_band is per-entry and gated by a player build choice. Keeping them distinct lets a card be phase_band A yet placed in a deck's Band B (gated behind the Motor Pool) — the two gates compose rather than collapse.

The contract: (phase_band, deployment_band) compose as an AND of two gates; neither replaces the other, and synthesis preserves both. Whether deployment_band is stored on the entry or derived from phase_band + the deck's CP layout is an open question (§7) — this topic fixes the relationship model, not the storage.

Three roster entries showing the join populated, values-free — placement, not counts or costs.

Deck/card ids are illustrative shape, not a roster assertion. Sourced from roster §6.2 / §6.3 US 2nd Armored row — labels and placements, no counts or costs.

1. open deployment_band storage vs derivation (§5) — whether the band is stored on each CardRosterEntry or derived from the card's phase_band plus the deck's command-post layout is a synthesis decision.
2. open cp_unlock modelling (§4) — whether the command-post surface is a referenced entity, an enum, or a constraint derived from deployment_band is open.
3. open Division ↔ deck identity (§2) — the Deck.division link and how To&E proportions shape a deck's roster is owned by topic 05; named here only as a slot.
4. open Faction entity — Deck.faction / card.faction share an unmodelled Faction entity; its full shape is a synthesis/topic-05 item.
5. open Campaign evolution of decks — roster §7.3's short-vs-long-campaign deck changes (replacements, cannibalization, rebuilds) are a campaign-economy layer, deferred (not authored here).

The disposition of these open questions is carried by the route gate below.

This is a design-synthesis topic over already-approved internal sources — "evidence" here is the source-section → schema mapping below, not external research.

• proposed-divisions-and-decks-roster §6 (RDQ4) — the band contract (§6.1: Band A/B/C = Vanguard / Main Body / Commitment + command-post unlock surfaces), the per-deck card-roster table (§6.2), and wonder eligibility (§6.3) — the Deck, DeploymentBand, and CardRosterEntry shapes (placements only, no counts).
• proposed-divisions-and-decks-roster §7 (RDQ5) — command-post naming (§7.1) and the unlock mapping (§7.2: which surface unlocks which band/scope) — the CommandPost shape; campaign-evolution rules (§7.3) noted as deferred.
• proposed-divisions-and-decks-roster §8 (RDQ6) — governance: deck status set (§8.1), per-card zone (§8.2), the strict one-wonder-slot rule (§8.3) — the DeckStatus enum and the wonder_eligible constraint shape.
• 01-core-unit-card-entity.md — the card entity the roster join references.
• 03-phase-vs-era-band.md — the in-match phase_band axis (and phase_min floor) this topic joins to the deck-side deployment_band (the deck join, §5).

10. Compile Responses

Answer the required gates above, add optional section feedback, then compile and copy the YAML into the next execution message. You may compile partial responses.