Unit Data Schema — Topic 03: Phase vs Era-Band Split — Omega War
Stage 2 · per-topic review · topic 03 of 6 · cycle unit-data-schema · page created 2026-06-14
This page reviews topic 03 only — the two-axis availability model: the in-match
phase_band (A/B/C) and the campaign era_band (E0/E1/E2) as two separate
required card fields, never conflated (UD-A2) — compiled from the working doc
research/_working/unit-data-schema/03-phase-vs-era-band.md. The cycle was decomposed (at the
user's direction) into six per-topic docs reviewed one by one; the canonical artifact
research/unit-data-schema.md is the later synthesis of all six topics, not this
page. This page authors no canonical artifact and no glossary output, and
it stays review.
Boundary (UD-A1): this topic defines shape, not values — the two axis fields, their enums, the orthogonality contract, a worked example, and a few illustrative rows. It assigns no magnitudes: no era-band unlock cadence, no phase-gate minute marks, no lock thresholds, no costs, no balance. The strong-kit phase-lock is authored as a structural flag/constraint shape, not a tuned number.
era_band: enum EraBand and phase_band: enum PhaseBand — were placed on the
card by topic 01 with full semantics deferred to topic 03. Topic 02's ConfigAxis enum
already names phase as a configuration axis that references this topic's phase_band
field. No new entity is introduced here; topic 03 authors the semantics of two existing card fields.
1. Purpose & scope of this topic
Fix the two-axis availability model as schema shape. A card's availability is governed by two
orthogonal questions that must not be confused: when in a match may it appear?
(phase_band — the in-match escalation window) and when in the campaign is it on the
shelf at all? (era_band — the calendar/progression gate). These are different clocks: phase
is the ~30-minute battle clock; era-band is the campaign-progression clock spanning many matches.
UD-A2 — never conflated. The rev-1 "Early/Mid/Late" table (arsenal §4) was really the
era-band axis masquerading as a single time field. Topic 01 placed both phase_band and
era_band on the card and deferred their semantics to here. This topic keeps them apart
as two required fields and authors what topic 01 deferred: per-axis semantics, the
orthogonality contract, and the strong-kit phase-lock rule — all as shape, not values (UD-A1).
2. The PhaseBand axis — in-match escalation window
PhaseBand ∈ {A, B, C} — a required card field. Semantics from arsenal §2 ARQ5 r2
("phase semantics reworked"): phase is the in-match escalation window — the timed/earned tier at
which a card becomes deployable within a single battle. Precedent: Steel Division 2's 10-minute timed
phase gates — phase is timed/earned within the match, not bought from a campaign shelf.
| Member | Window | Meaning |
|---|---|---|
A | Opening | Available from the start of the match — the cards fieldable in the earliest window. |
B | Buildup | Unlocks mid-match as the escalation window advances. |
C | Commitment | The late/heavy window — the strongest commitments arrive last. |
Structural rule — strong kit locked out of Phase A. The schema must express that strong-tier
kit is locked out of Phase A in every match, regardless of campaign date. A card's heaviest
commitments cannot open the battle; they belong to B/C. This is authored as a per-card phase floor
(a phase_min / lock shape — see §5), not as a tuned threshold. What counts as "strong-tier"
and the exact gate values are deferred to the balance pass (UD-A1). The rule is
campaign-date-independent: even when a unit's era_band has long unlocked it for the
deck, its phase floor still keeps it out of the opening window — which is exactly why the two axes are separate
fields (§4).
Gate — phase-band-model required
Approve the in-match PhaseBand A/B/C semantics (opening / buildup / commitment) and
the structural rule that strong-tier kit is locked out of Phase A in every match (as a schema flag/constraint
shape, magnitudes deferred under UD-A1)?
3. The EraBand axis — campaign-calendar availability
EraBand ∈ {E0, E1, E2} — a required card field. Semantics from arsenal §4 (the renamed
era-band table): era-band is the campaign-calendar availability of a card — is it on the shelf at
all, given campaign progression? §4 notes the rev-1 "Early/Mid/Late" table was really this axis; renaming to
E0/E1/E2 disambiguates it from the in-match phase window.
| Member | Shelf | Meaning |
|---|---|---|
E0 | Standing kit | On the shelf from campaign start — always available to field. |
E1 | In-production | Becomes available as the campaign advances (mid-campaign production). |
E2 | Reward shelf | Late/earned campaign unlocks — the top of the availability ceiling. |
"Moves the ceiling, never the floor." Era-band raises what becomes available as the
campaign advances; it never removes the standing kit. An E0 card is fieldable throughout;
E1/E2 cards are added on top as the campaign clock turns. Era-band says
whether a card is available across the campaign, not when in a given match it
appears — that second question is phase_band (§2). The cadence of E1/E2 unlocks is a
campaign-economy value, deferred (§9).
Gate — era-band-model required
Approve the campaign-availability EraBand E0/E1/E2 semantics (standing kit / in-production /
reward shelf) and the "moves the ceiling, never the floor" rule, with unlock cadence deferred (UD-A1)?
4. The orthogonality contract — why two fields, not one
The two axes answer different questions on different clocks, so a card needs a value on each
independently: phase_band (A/B/C) is the battle clock — when within a match;
era_band (E0/E1/E2) is the campaign clock — whether available across the campaign. A
single conflated field cannot represent a card that is always on the shelf but only deployable late in each
match, nor one that is a late-campaign reward yet fieldable from a battle's opening once unlocked.
| Card | era_band | phase_band floor | Reading |
|---|---|---|---|
| T-54 | E2 (reward shelf) | Phase C only | A late-campaign reward and a late-match commitment — gated on both clocks. |
| SU-76M | E0 (standing kit) | Phase A–C (no floor) | Standing kit from campaign start and fieldable from a battle's opening window. |
The contract: (era_band, phase_band) is a pair; neither value implies the
other. Synthesis must preserve both fields as required and independent. (Worked example source: §2 ARQ5
r2 — values shown are axis labels, not stats.)
Gate — two-axis-contract required
Approve keeping phase_band and era_band as two separate required
card fields (UD-A2) — the orthogonality contract, demonstrated by the T-54 vs SU-76M
worked example — rather than collapsing them into one availability field?
5. How the two axes attach to card
Both are already required fields on the topic-01 card. Topic 03 adds
no new entity — it authors their semantics plus, at most, a small helper shape for the phase
floor.
| Field | Type | Req? | Notes |
|---|---|---|---|
era_band | enum EraBand | required | Campaign-availability shelf (§3). One value per card. |
phase_band | enum PhaseBand | required | The in-match window a card can reach (§2). |
phase_min | enum PhaseBand | optional (shape) | Per-card phase floor — earliest deployable window; encodes the §2 lock (strong kit ⇒ floor ≥ B). Shape only; floor values + the strong-tier definition deferred. |
phase_min is the only candidate new shape, and it is a flag/constraint on the
card, not a new entity. Synthesis decides whether the lock is best modelled as phase_min,
as a rule derived from a trait/tier, or as a validation constraint — this topic only fixes that the lock
is representable as card shape and that phase_band/era_band stay two distinct
required fields.
6. Relationship note — the deck join is topic 04
The roster (§6) carries a deployment Band A/B/C = Vanguard / Main Body / Commitment, tied to
command-post unlocks — the deck-authoring view of the same A/B/C ladder. Whether the schema's
in-match phase_band and the roster's deployment-band + command-post unlock are the same axis
viewed from deck-side, or two related-but-distinct gates, is the deck join — and it is
deferred to topic 04 (deck / band / card-roster). This topic does not resolve
that reconciliation; it only flags it (§8) so topic 04 owns it.
7. Illustrative filled rows (shape demonstration only — NO values)
Two rows showing both axis fields populated, values-free — field population, not balance.
card.id | era_band | phase_band | phase_min | Reading |
|---|---|---|---|---|
us_rifle_squad_45 | E0 | A | — | Standing kit, fieldable from the opening window — no phase floor. |
| (heavy example) | E2 | C | C | Reward-shelf unlock, locked to the commitment window — floor keeps it out of A. |
Row 1 reuses the topic-01 illustrative us_rifle_squad_45 (E0 / A — always available,
opens the battle). Row 2 is a generic late commitment (E2 / C with a phase floor of C), mirroring the T-54 reading
in §4 without asserting any stats.
8. Open questions & route
- open Phase-lock representation (§5) — whether the
strong-kit-out-of-A rule is modelled as
phase_min, a derived rule from trait/tier, or a validation constraint, is a synthesis decision. - open Deployment-band reconciliation (§6) —
phase_bandvs the roster's deployment Band A/B/C + command-post unlock is the deck join, owned by topic 04; synthesis confirms the final relationship. - open Era-band unlock cadence — when E1/E2 unlock across the campaign is a campaign-economy value, deferred (not authored here).
- open "Strong-tier" definition — what kit triggers the Phase-A lockout is a balance threshold, deferred to the balance pass.
The disposition of these open questions is carried by the route gate below.
Gate — route required
How should the cycle proceed? This also disposes the §8 open questions (they carry to synthesis unless you direct otherwise in notes).
9. Deferred-values register (this topic)
| Deferred | Why | Where it lands |
|---|---|---|
| Era-band unlock cadence (when E1/E2 open) | UD-A1 shape-not-values; campaign economy | campaign-economy / balance pass |
| Phase-gate timings (the SD2-style minute marks for A/B/C) | UD-A1; in-match balance | prototype balance pass |
| Phase-A lock threshold ("what counts as strong-tier") | UD-A1; balance | prototype balance pass |
| Per-card axis assignments across the roster | content (values) | balance/content pass |
10. Source log (topic 03)
This is a design-synthesis topic over already-approved internal sources — "evidence" here is the source-section → schema mapping below, not external research.
arsenal-1945§4 — the renamed era-band table (E0/E1/E2 = standing kit / in-production / reward shelf) + the note that the rev-1 "Early/Mid/Late" table was really the era-band axis (theEraBandsemantics; labels only, no cadence).arsenal-1945§2 ARQ5 round 2 — "phase semantics reworked": the canonical two-axis definition (phase = in-match escalation window A/B/C, SD2 10-min timed precedent; era-band = calendar availability, "moves the ceiling, never the floor") and the worked T-54 vs SU-76M example (§4).proposed-divisions-and-decks-roster§6 — deployment Band A/B/C (Vanguard / Main Body / Commitment) + command-post unlocks; the deck-side view of the A/B/C ladder. The join is topic 04, flagged here as an open question.01-core-unit-card-entity.md— topic-01 hand-off: theera_bandandphase_bandcardfields this doc gives full treatment.
11. 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.