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/unthinkable/_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/unthinkable/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.
Compiled from the topic-03 review YAML. Three gates approved
(era-band-model, two-axis-contract, route); one was a revision —
phase-band-model: revise-phase-band. The change is an additive display layer on
the PhaseBand axis: the internal window names (Opening / Buildup / Commitment) stay for design
use, and players now see fixed flavor labels —
A = Recon B = Frontline
C = Breakthrough. The stored enum is unchanged (A/B/C), no new
card field is introduced, and UD-A1 holds (a naming map, not magnitudes). The labels were chosen
to stay clear of §6's separate deployment Band (Vanguard / Main Body / Commitment) — see §2 and §6.
The cycle stays in review — no canonical artifact, no glossary output. The
route gate (proceed-topic-04) fires alongside this revision (topic-01 precedent), so
topic 04 (deck / band / card-roster) is authored this pass. The phase-band-model gate stays live,
re-framed so "approve" now confirms the A/B/C semantics including the player labels.
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 Changed 2026-06-14 — player-facing labels added
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 (internal) | Player-facing label | Meaning |
|---|---|---|---|
A | Opening | Recon | Available from the start of the match — the cards fieldable in the earliest window. |
B | Buildup | Frontline | Unlocks mid-match as the escalation window advances. |
C | Commitment | Breakthrough | The late/heavy window — the strongest commitments arrive last. |
Two naming layers Changed 2026-06-14 — player labels added.
The schema carries one axis with one stored enum value set —
phase_band ∈ {A, B, C}. Over that single field sit two naming layers: the
internal design vocabulary (Opening / Buildup / Commitment), kept for docs and tooling, and
the player-facing UI labels (Recon / Frontline / Breakthrough), shown in-game. The player
labels are a fixed enum→label display map — A is always "Recon", B
always "Frontline", C always "Breakthrough" — not a new card field and
not a second axis. UD-A1 holds: this is vocabulary/shape, not a magnitude.
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 Re-framed 2026-06-14 — confirm player labels
Confirm the in-match PhaseBand A/B/C semantics (internal windows opening / buildup / commitment)
including the player-facing labels — A = Recon, B = Frontline, C = Breakthrough (a fixed
enum→label display map, no new card field) — 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.
The PhaseBand player-facing labels (Recon / Frontline / Breakthrough, §2) are deliberately
distinct from this deployment Band's labels (Vanguard / Main Body / Commitment) so the two A/B/C ladders don't
read alike — "Frontline" avoids colliding with "Main Body" and "Breakthrough" avoids reusing "Commitment",
keeping the in-match window and the deck-side band visually separable even though both run A/B/C underneath.
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.