Unit Data Schema — Topic 01: Core Unit/Card Entity — Omega War

Define the unit/card entity — the single most-referenced object in the schema. Every other topic hangs off it: equipment & variants (02) attach to it, the phase/era split (03) are two of its fields, the deck/band/card-roster (04) references it, the To&E proportions (05) count it by class, and CP/wonder governance (06) constrains which instances deploy when.

Field types use a deliberately small vocabulary: enum (closed value set defined in §3), string, bool, ref<Entity> / ref<Entity>[] (relationship, resolved in the named topic), ordinal-enum (ordered tiers), deferred (a slot whose value is intentionally not authored this cycle — UD-A1). In the Req? column, required chips mark the authored-required set; optional chips mark optional/attachable fields.

Every field here is static authored data on the card. No runtime/instance state (position, current veterancy progress, suppression) appears in this table — that lives on the unit instance (§1), and its storage is deferred to the vertical-slice spec.

Required-set rationale. A card cannot be authored, placed in a band, or counted in a To&E without id, display_name, card_class, faction, category, both band axes (era_band, phase_band), zone, and a veterancy_track. Everything else is optional/attachable.

Enumerating allowed members is schema shape, not balance. Magnitudes attached to these members (cost, stats) stay deferred. Five enum sets follow.

3.1 CardClass — accepted §4A taxonomy Resolved 2026-06-14 — closed set

Closed enum. The §4A table enumerates the infantry/team classes verbatim:

line_squadassault_eliteengineermg_teammortar_teamat_teamflame_teamsniperreconcommand_logspecialistrecovery

The vehicle/heavy leaves were resolved this review pass — no longer deferred to synthesis — grounded in arsenal §3 category headings, §4A.1 named types, the SD2 nine-tab deck calibration, and the explicitly-added "+4" (spaag / recovery / command / sniper):

3.2 Category — coarse arm/role grouping

Proposed members (shape; final set confirmed at synthesis against §3/§4A):

infantryarmorreconsupportanti_tankanti_airartillerycommand_logisticsrecoveryair

support = MG/mortar/engineer/flame. category is the SD2-tab-style coarse grouping; card_class is the finer leaf. A card has exactly one of each.

3.3 Band axes — EraBand / PhaseBand

Two separate required fields, never conflated (UD-A2). Topic 03 owns the detailed semantics, worked example, and the strong-weapons-locked-out-of-A rule; topic 01 only records that the card carries both.

3.4 Zone — provenance dial (§4B, ADOPTED)

3.5 Tier — plausibility evidence tier

Changed 2026-06-14 The former §3.6 Confidence enum was dropped — source quality is already carried by zone / plausibility_tier / source_ref, so it was redundant.

Veterancy is a must-have in-battle mechanic that persists into the campaign as a persistence surface; the refit/upgrade economy is a campaign-layer deferral (UD-A5). Shape:

Prototype trait_tags: ref<TraitTag>[] on the card. The catalogue and magnitudes wait for the Prototype-tier balance pass (UD-A4). The TraitTag entity shape:

So the schema fixes that a card holds zero-or-more trait-tag references and that a tag declares a polarity, while the catalogue membership and all numbers wait for the Prototype-tier balance pass.

Two rows, marked illustrative. They show field population, not balance — no costs, no stats.

The second row exercises a heavy-vehicle card (tank_destroyer — Elefant = heavy TD) from the now-closed §3.1 set, plus the zone=what_if + framing_note provenance discipline. Changed 2026-06-14 — was (vehicle class — see §3.1 OPEN).

resolved The former item 1, "Full CardClass membership", is resolved — the closed set is now authored in §3.1 (see the cardclass-open resolved record).

1. open Category final set (§3.2) — confirm the coarse grouping list and the class→category mapping against §3/§4A. (CardClass is now closed; only the coarser Category set remains open.)
2. open Equipment as entity vs attribute — resolved in topic 02; topic 01 leaves equipment as a ref list pending that decision.
3. open card vs unit instance boundary — confirm at synthesis that authored fields (this doc) and runtime state (position, veterancy progress, suppression) stay cleanly separated, and that the storage medium lands in the vertical-slice spec.
4. open Air sub-roles (§3.1) — whether aircraft splits into fighter / ground-attack / bomber leaves is a synthesis refinement.
5. open Veterancy level count & labels — values; deferred but flagged so the prototype pass knows the shape expects an ordered ladder.

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

Changed 2026-06-14 The "Vehicle-class enum rows" row was removed from this register — those leaves are now authored in §3.1, not deferred.

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 §4A — ACCEPTED unit-category taxonomy table (12 infantry/team classes; vehicle/heavy leaves authored in §3.1 this pass, reconciled against §4A category headings + §4A.1 named types).
• arsenal-1945 §4A.1 — variant/upgrade patterns (separate-card / munitions / configuration) — referenced; modeled in topic 02.
• arsenal-1945 §4B — adopted three-zone dial (baseline/stretch/what_if) + provenance-honesty discipline.
• arsenal-1945 §2/§3 — plausibility tiers T1–T4; per-faction equipment tables (category/faction/tier attributes).
• arsenal-1945 §4 — era-band E0/E1/E2 vs in-match phase A/B/C (two-axis), full treatment deferred to topic 03.
• game-genre-map §3 — veterancy (must-have, in-battle, persists); unit trait tags (Prototype: shock/commando/militia/leader, magnitudes deferred).
• divisions-1945 §4 — To&E → card-class proportions ("schema inputs"); counts deferred to topic 05.

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.