Unit Data Schema - Omega War

Stage 1 research-scope review · staged cycle: unit-data-schema · page created 2026-06-13 · confirmed 2026-06-15

alignment_status: confirmed - Stage 3 canonical artifact written.
Current-cycle note: this Stage-1 hub is superseded for active working status by the per-topic unit-schema packet under research/unthinkable/_working/unit-data-schema/ and the topic pages linked from alignment/index.html. The canonical synthesis now lives at research/unthinkable/unit-data-schema.md. The legacy research/_working/preliminary-unit-data-schema.md path below is preserved as the original Stage-1 proposal, not the current routing surface.
This page proposes the scope, schema design questions, input sources, entities, assumptions, output paths, and post-approval route for the unit-data-schema cycle - the shared unit/division data schema for the tactical layer, the deck builder, and the campaign map. The cycle origin is the confirmed game-genre-map forward route confirm-unit-data-schema (genre-map §10 / E15). This page does not introduced no combat stats, prices, card counts, trait buff/debuff numbers, or balance. The Stage-3 schema synthesis is confirmed and remains amendable through later specs.

1. Proposed Cycle Summary

Section feedback notes

Purpose: draft the shared unit/division data schema for Omega War - the structured shape that every layer reads from. The schema is the substrate the tactical layer (units on the battlefield), the deck builder (decks/bands/card-rosters), and the campaign map (divisions, refit, persistence) all reference, so a single agreed shape prevents three divergent ad-hoc models.

Primary boundary: this cycle defines shape, not values. It enumerates entities, fields, enums, and relationships with a few illustrative filled rows for clarity. It does not assign combat stats, prices, exact card counts, trait buff/debuff numbers, or balance - all of which are explicitly deferred across the source files.

Immediate downstream use: a confirmed schema unblocks the tactical vertical-slice spec, the deck-builder spec, and the campaign-map persistence model by giving each a stable contract to build against.

1.1 Inputs already approved

research/unthinkable/arsenal-1945.md §4A - unit-category taxonomy (12+4 card-class set, ACCEPTED); §3 - per-faction equipment tables; §4A.1 - variant/upgrade model; §4B - zone dial + one-wonder-slot.
research/unthinkable/divisions-1945.md §4 - To&E → card-class proportions (flagged "schema inputs").
research/unthinkable/proposed-divisions-and-decks-roster.md §6/§7/§8 - deck/band/card-roster model, command-post (CP) unlocks, and wonder/anti-rush governance.
research/unthinkable/game-genre-map.md §3 - veterancy (must-have), unit trait tags (Prototype), cover/suppression conventions.

1.2 Shape-not-values boundary

The proposed Stage-2 deliverable is a shape-not-values data spec: entities, fields, enums, and relationships, with a few illustrative filled rows. No combat stats, prices, exact counts, or balance. This is the UDQ2 default the user ratifies below.

Gate - UDQ1 Scope required

Approve this cycle scope - draft the shared unit/division data schema (shape, not values) from the inputs above - as the Stage-2 scope for unit-data-schema?

Approve as proposed Approve with additions in notes Narrow the scope before research Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

2. Schema Design Questions

Section feedback notes

These are the questions Stage 2 will answer when it drafts the schema shape. They are listed for scope agreement, not answered here.

ID	Question	Expected decision output
UDQ-a	What is the entity set the schema must cover, and how do the entities relate?	Entity list + relationship map (unit/card, equipment item, variant/upgrade, faction, deck, deployment band, card-roster, trait tag, division/To&E, command-post surface, wonder slot).
UDQ-b	How are fields and enums defined for each entity (names, allowed values, optionality)?	Per-entity field tables with enum value sets and required/optional markers.
UDQ-c	How is the match-phase vs campaign era-band split represented?	Two distinct fields - match-phase A/B/C and campaign era-band E0/E1/E2 - never conflated (arsenal §2/§4).
UDQ-d	How is the variant/upgrade model encoded?	Encoding for the three §4A.1 variant/upgrade patterns.
UDQ-e	How are veterancy and trait-tag fields represented on a unit?	In-battle veterancy field now; trait-tag field with deferred catalogue/numbers (Prototype).
UDQ-f	How are deck, deployment band, and card-roster modeled (deck × band × cards)?	Relational shape for deck-as-roster, band A/B/C, and the per-deck card-roster.
UDQ-g	How are wonder-slot constraints expressed?	Wonder-slot entity + the one-slot / anti-rush governance constraint as a shape.
UDQ-h	What is the deferred-values policy?	Explicit "shape only" markers; no stats/prices/counts/balance authored.

Gate - UDQ2 Deliverable Shape required

What shape should the Stage-2 working packet produce?

Shape-not-values data spec: entities, fields, enums, relationships + a few illustrative rows (default) Also add a machine-readable skeleton (e.g. JSON/YAML schema stub) Conceptual entity map only (relationships, defer field-level detail) Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

3. Input Sources / Evidence Coverage

Section feedback notes

The schema is built from already-confirmed internal artifacts. No external research is required - this is a design-synthesis cycle over approved sources.

Source section	What it supplies to the schema
`arsenal-1945.md` §4A	Unit-category taxonomy - the accepted 12+4 card-class enum.
`arsenal-1945.md` §3	Per-faction equipment tables - the equipment-item entity and its faction/category attributes.
`arsenal-1945.md` §4A.1	Variant/upgrade model - the three variant/upgrade patterns.
`arsenal-1945.md` §4B	Zone dial + one-wonder-slot - zone/phase fields and the wonder-slot constraint.
`divisions-1945.md` §4 / DRQ2	To&E → card-class proportions - the division/To&E entity and proportion fields.
`proposed-divisions-and-decks-roster.md` §6.1/§6.2/§6.3/§7.2/§8	Deck/band/card-roster model, CP unlocks, and governance.
`game-genre-map.md` §3	Veterancy (must-have), unit trait tags (Prototype), cover/suppression context.
`glossary.md`	Term anchors: deck-as-roster, deployment band, unit trait tag, reward shelf, plausibility tier, era-band, refit culture.

Gate - UDQ3 Coverage required

Approve these input sources as the evidence base for the schema?

Approve all listed sources Approve with added source(s) in notes Drop some sources (describe in notes) Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

4. Entities to Model

Section feedback notes

Proposed entity set for the schema. Each row lists already-documented attributes and the gap Stage 2 must close. Attributes describe shape; no values are assigned here.

Entity	Already-documented attributes	Gap to close in Stage 2
unit / card	class enum, faction, category, era-band, plausibility tier, zone, phase band, veterancy, transport, trait tags, framing note, source/reliability	Field names, enum value sets, optionality, and which attributes are shared vs per-faction.
equipment item	faction, category, plausibility tier (arsenal §3)	Relationship to unit/card; whether equipment is a separate entity or a unit attribute.
variant / upgrade	three §4A.1 patterns	How each pattern is encoded as a shape (base + delta vs distinct rows).
faction	identity, roster ownership	Field set; link to decks, units, equipment.
deck	status, archetype, strength/weakness, refit culture, wonder slot	Field set; relationship to division and card-roster.
deployment band A/B/C	band identity (roster §6/§7)	Representation as an enum/field on the card-roster relation.
card-roster (deck × band × cards)	per-deck card listing across bands	The relational join shape (deck × band × card).
trait tag	shock / commando / militia / leader (Prototype)	Field shape only; catalogue + buff/debuff numbers deferred.
division / To&E	card-class proportions (divisions §4)	How proportions map onto deck/card-roster as a shape.
command-post surface	CP unlock model (roster §8)	Representation of unlock gating as a shape.
wonder slot	one-slot constraint, anti-rush governance (arsenal §4B, roster §8)	Constraint expressed as a schema rule.

Gate - UDQ4 Entities required

Approve this entity set as the schema's modeling scope?

Approve the entity set Add entities (describe in notes) Remove entities (describe in notes) Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

5. Assumptions and Constraints

Section feedback notes

UD-A1: the schema defines shape, not values - no combat stats, prices, exact counts, or balance.
UD-A2: match-phase A/B/C and campaign era-band E0/E1/E2 are two separate fields, never conflated (arsenal §2 ARQ5r2 / §4).
UD-A3: the accepted §4A 12+4 card-class taxonomy holds without amendment in this cycle.
UD-A4: the full trait-tag catalogue and buff/debuff numbers are deferred (Prototype tier); the schema provides only the field shape.
UD-A5: an in-battle veterancy field is in scope now; the campaign refit/upgrade economy is a persistence hook only, deferred.
UD-A6: the roster-file definitions of deployment band and refit culture are treated as canonical where the glossary status has drifted.
UD-A7: German depot-stock scale and sub-army Soviet granularity stay confidence-capped (inherited from arsenal/divisions caveats).

Gate - UDQ5 Assumptions required

Accept these assumptions and constraints for the schema cycle?

Accept all assumptions Revise assumptions in notes Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

6. Outputs, Paths, and Route

Section feedback notes

Stage	Path	Purpose
Stage 2 working packet (superseded proposal)	`research/_working/preliminary-unit-data-schema.md`	Original non-canonical schema draft path proposed by this Stage-1 hub. Current active topic packets live under `research/unthinkable/_working/unit-data-schema/`.
Stage 2 review page	`alignment/unit-data-schema-omega-war.html`	Converts the working packet into approval gates (this page advances in place).
Stage 3 canonical artifact	`research/unthinkable/unit-data-schema.md`	Approved unit/division data schema (shape, not values).
Stage 3 glossary updates	`research/unthinkable/glossary.md`	Only if the Stage-2 artifact proposes and the user approves new terms.

Gate - UDQ6 Working Packet Path required

Approve the Stage-2 working packet path?

Approve research/_working/preliminary-unit-data-schema.md Use a different path (describe in notes) Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

Gate - UDQ7 Canonical Path required

Approve the proposed Stage-3 canonical path?

Approve research/unthinkable/unit-data-schema.md Use a different path (describe in notes) Do not write a canonical artifact yet Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

Gate - UDQ8 Route After Approval required

After a confirmed schema, what should the next project route be?

Continue to the tactical vertical-slice design spec Run a Three.js performance/prototype spike first Draft the deck-builder spec first Choose another route in notes Other / None of the above (describe in notes) Need clarification

Additional notes (optional)

7. Compile Approval YAML

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