Component Inventory

What a complete RPG data model needs. Derived from a structural survey of a mature, production AGE-family implementation — shape only, no content, names, values, or setting, per the originality policy.

Priority: P0 the system does not function without it · P1 needed before real play · P2 needed for a campaign · P3 depth.

The gaps that matter most

The surveyed system is a character-and-campaign engine, not a combat engine. Five things it does not model at all are exactly the things C.A.T.S. exists to do. These are the highest-value findings in the survey:

Missing	Why it is fatal for C.A.T.S.
NPC / creature statblocks	GM content was free text with a type tag. A combat game needs adversaries as first-class data or the PA cannot run an encounter
Action economy	No actions-per-turn, action types, movement cost, reactions, or initiative anywhere in the data model. The single largest gap
Range bands	No range table. Our physics engine produces this natively — it is our strongest advantage
Damage type x resistance matrix	No damage typing at all. The brief's 14 weapon properties against 10 armor profiles has no equivalent
Cover, terrain, ammunition, encumbrance	All absent. Supply pressure and positioning are core to military SF

Structural patterns worth adopting

Pattern	What it is	Why
`source` on every grant	Each focus, talent, or item records why the character has it	Enables rebuild, undo, respec, and audit. The single best idea in the surveyed schema
Shared quality/flaw vocabulary	One tag pool with `kind` (positive/negative/variable), `effect`, `threshold`, `repeatable`, reused by gear, armor, vehicles, and implants	Highest-leverage structure found. One hull spawns many variants with no duplicated statblocks
Polymorphic item catalog	One array with sparse optional fields, not one file per item type	Avoids fragmenting the model; one renderer, one resolver
Rules-constants file	Creation order, generation methods, derived formulas, advancement costs, difficulty ladder — all in one tunable data file	Nearly everything a designer rebalances lives in one place
Condition escalation chains	Conditions carry `recovery`, an `escalation` successor, and a `conflictNote`	Fatigue to exhaustion to unconsciousness becomes data, not prose
Injectable randomness	One `RandomSource` interface; nothing else touches the RNG	Every rule becomes deterministically testable
Derivation / validation split	Pure derivation (no I/O, no randomness) separate from a validator returning a list of human-readable problems	Directly serves OQ-17's computability requirement
Stable kebab ids, referenced by id	Never reused, every cross-reference by id	Add a build-time validator that every reference resolves
Per-entry `optional` + `source` flags	One corpus serves core, expansion, and house rules without forking files	Maps onto our complexity modes (OQ-18)

Two weaknesses not to repeat

Derived formulas existed twice — as prose strings in the constants file and as hardcoded TypeScript, with nothing keeping them in sync. C.A.T.S. must evaluate formulas from data.
Prerequisites were free text, so they could not be machine-validated. Model requirements as structured predicates from day one; retrofitting prose is expensive and OQ-17 requires it.

The checklist

Character and creature

P	Component
P0	Attribute list — flat, 6-10, with `covers` and bounds
P0	Skill/focus layer — decide flat-bonus vs ranked once; it propagates everywhere
P0	Derived stat definitions — `formula` in data, evaluated by one engine
P0	Character document schema — identity, version enum, build ids, grants with provenance, cached derived, sync meta
P0	Generation methods — random table and point-buy; both are cheap to carry
P0	NPC/creature statblocks — tier, attributes, defenses, wounds, attack list, special abilities, morale, salvage
P1	Origin/species — auto-grants plus an origin x environment penalty matrix (gravity, atmosphere, radiation, pressure)
P1	Background and profession — grant packages with a typed, discriminated `benefits` table
P1	Tiered abilities — three tiers is a proven shape; make `requirements` machine-readable
P1	Advancement — per-level entitlements plus a cost curve keyed on current score
P1	Rank / clearance — affects authority, requisition ceiling, and social tests
P2	Squad/follower units — competence, morale, covered roles, rally and recovery

Equipment

P	Component
P0	Unified polymorphic item catalog with a category taxonomy
P0	Weapon profile — damage, damage type, range bands, magazine, reload cost, qualities, handling minimum
P0	Armor profile — threshold and capacity per our layered model, mobility penalty, coverage by location, environmental sealing
P0	Damage type x resistance matrix — kinetic, thermal, energy, EMP, chemical, concussive
P1	Shared item quality/tag vocabulary
P1	Ammunition and consumables — type, compatibility, effect override, quantity
P1	Encumbrance — per-item load, capacity derived from an attribute
P2	Modification/crafting — extended test scaffolding, reusable for repair and salvage
P2	Augmentation/implants — slot constraint, split part vs install cost, quality and flaw pools, illicit path priced in drawbacks
P2	Requisition — replace shopping with a test gated by rank and mission priority

Vehicles, mechs, ships

P	Component
P0	Vehicle statblock — class/size, crew requirement, crew quality, armor by location, mobility, sensors, weapons, qualities, flaws
P0	Scale bridging — our logarithmic spine already answers this; it is the first thing that breaks elsewhere
P1	Vehicle quality and flaw pools — same shared tag pattern
P1	Crew roles and stations — what each can do per turn, and what happens when unfilled
P1	System-by-system damage — mobility, weapons, sensors, life support degrading separately
P2	Ownership and logistics — maintenance, endurance, requisition status
P3	Drones and remotes — control range, autonomy level, operator link

Rules metadata

P	Component
P0	Core resolution definition in data — formula, difficulty ladder, explosion rule
P0	Condition catalog with escalation chains, conflict notes, stacking rules. We need far more than a general RPG: suppressed, pinned, stunned, burning, irradiated, decompressed, hypoxic, EMP'd, bleeding
P0	Wound/health track and how it interacts with conditions
P0	Action economy — actions per turn, types, movement cost, reactions, initiative
P1	Stunt/critical-effect table as data — the surveyed system referenced these constantly but never stored them
P1	Range bands and cover — bands, per-band modifiers, cover degrees, concealment vs cover
P1	Environmental hazards — vacuum, pressure, temperature, radiation, contaminants, gravity, each with an exposure interval and escalation
P2	Morale, suppression, and stress for both players and NPC units

World scaffolding

P	Component
P1	Factions — type, what work they generate, inter-faction relationships, standing per faction
P1	Locations — environment tags, hazards, tactical features
P2	Mission framework — type, objectives, opposition budget, reward, failure consequences
P2	Economy — banded logarithmic tiers with gated growth beats currency for a military game
P2	Downtime — length tiers x activity, each an extended test against a progress threshold. Maps directly onto our Margin progress model
P2	Reputation as separate scalars — standing, volatility, and heat — never one number

Infrastructure

P	Component
P0	Stable ids, cross-references by id, plus a build-time validator that every reference resolves
P0	Per-file schema version and provenance
P0	Injectable randomness
P0	Derivation/validation split
P1	Machine-readable prerequisites from day one
P1	Grant provenance on everything
P1	Sync metadata — created, updated, rev, serverRev, dirty, deleted, owner — plus a visibility enum
P2	Canonical data directory mirrored to any published copy; never hand-edit the copy
P2	Content validators in CI — fail on dangling references or missing required fields