Rules Data Model

Contents

Overview
Design Constraint
Structured Rule Objects
Table Language and Data Language
Ranged Subsystem Schema Sketches
Coding Readiness Checklist
Future Use

Overview

The TTRPG should remain open, fiction-facing, and comfortable at the table. At the same time, its recurring mechanics should be easy to translate into a computer RPG or digital rules engine.

This does not mean every table ruling needs software precision. It means that durable rules elements should have a clear possible data shape behind them. If a mechanic appears often, changes dice, creates pressure, grants permission, affects wounds, or changes encounter flow, it should be possible to express it as structured rule data.

Design Constraint

Use this constraint when developing new mechanics:

A rule may be described in natural table language, but its repeated mechanical effect should be expressible as a small structured object.

This keeps the tabletop version flexible while preventing the rules from depending on purely interpretive phrases that would be difficult to implement later.

Structured Rule Objects

The following object types are the current first-pass targets for digital adaptation.

Object Type Table Role Data Needs

Object Type	Table Role	Data Needs
`Talent`	Defines capability, permissions, dice support, and high-match effects.	Name, tier, category, triggers, dice effects, permissions, high-match table, costs, limits.
`Condition`	Tracks harm, exposure, pressure, impairment, or temporary state.	Name, severity, source, duration, dice effect, permission limits, removal conditions.
`Burden`	Represents a durable liability or obligation.	Name, source, pressure trigger, escalation trigger, relief condition, linked people or factions.
`Bond`	Represents a durable support tie or relationship.	Name, linked person/group/place, help trigger, demand trigger, strain condition.
`EquipmentTag`	Gives gear tactical identity without full item math.	Name, category, trigger, positional effect, pressure effect, wound interaction, drawback.
`EraProfile`	Defines the expected baseline for tools, threats, vehicles, vessels, sensors, magic-tech overlap, and scale assumptions.	Code, name, reference band, common tags, common threat types, range profile, scale assets, digital content filters.
`CombatExchange`	Resolves one burst of combat action.	Momentum side, spotlight actor, intent, active threat, movement intent, dice pool, outcome band, match result, consequences.
`SpellEffect`	Represents a magical action or ongoing magical result.	School or method, pace, target, source, cost, duration, maintained requirement, backlash profile.
`CastingMethod`	Defines how a spell is shaped and interrupted.	Method channel, required components, vulnerability, fallback method, interruption consequence.
`Backlash`	Represents magical failure, overstrain, or unstable side effect.	Trigger, severity, method channel, school signature, Condition output, containment option.
`NonlethalObjective`	Defines a combat intent that removes a threat without relying on lethal wounds.	Objective type, allowed tools, success effect, partial effect, escape condition, lethal fallout risk.
`DistanceBand`	Defines range relevance for melee, ranged, magical, vehicle, and sensor actions.	Name, theatre-of-mind meaning, square range, hex range, metric freeform range, meter thresholds, optional imperial equivalents, adjacent bands, permission requirements, pressure triggers, default movement effect.
`MovementMode`	Defines how far a character can reposition during an exchange and what the movement costs.	Name, meter threshold, grid threshold, freeform threshold, whether it can be incidental, pressure triggers, terrain modifiers, state changes.
`WeaponRangeProfile`	Defines the range permission for an attack form without creating full item statistics.	Name, comfortable bands, pressured extension bands, required tags or permissions, blocked bands, scale handling, CRPG range filters.
`TargetingState`	Defines whether one observer can identify, aim at, lock onto, or affect one target.	Observer, target, state name, source, confidence, valid attack types, bypass methods, break conditions, false-positive risk.
`DetectionMethod`	Defines how stealth, detection, locks, traces, and spoofing change targeting state.	Method name, source tag, sense type, required permission, target states it can improve or worsen, duration, break condition, false-positive behavior.
`ResourceState`	Defines ammunition, charge, heat, fuel, ritual load, or unstable buildup when the scene tracks it.	Resource name, current state, source item or spell, trigger, recovery method, consequence on cost, empty behavior, overload behavior.
`CoverState`	Defines protection, concealment, and line-of-effect limits.	Name, detection effect, wound interaction, bypass methods, break conditions.
`Threat`	Represents an opponent, group, hazard, or creature.	Threat scale, role, Talent tier, wound capacity, pressure options, cohesion triggers, special tags.
`ThreatTemplate`	Provides reusable defaults for creating threats quickly.	Scale, role defaults, wound capacity, pressure menu, tags, special rule, cohesion trigger.
`ConflictScale`	Defines whether action is personal, squad, force, vehicle, vessel, or strategic.	Scale name, acting unit, valid targets, mismatch handling, zoom triggers.
`Force`	Represents an army, company, formation, crew, fleet element, or other large group.	Size, quality, cohesion, command, supply, position, special assets, objective.
`VehicleOrVessel`	Represents a platform with systems rather than ordinary wounds.	Scale, crew roles, systems, tags, current position, mission objective, system damage.
`CrewRole`	Defines a player-facing station in vehicle or vessel conflict.	Role name, action menu, linked systems, valid pressures, spotlight status, fallback actions.
`SystemDamage`	Represents harm to a vehicle, vessel, force asset, or strategic system.	System name, severity, source, pressure effect, repair condition, escalation trigger.
`Pressure`	Represents short-lived disadvantage or tactical danger.	Name, source, die penalty, affected action type, duration, removal condition.
`Wound`	Represents combat harm as a Condition-like state.	Severity, source, body/system affected, treatment need, defeat contribution.
`Permission`	Answers whether an action is allowed cleanly.	Required Talent, tag, role, faction standing, tool, position, location, or prior action.
`MomentumState`	Tracks which side is pressing in combat.	Current side, last exchange, spotlight cycle, valid next actors, momentum change trigger.
`HighMatchEffect`	Adds extra effect beyond the base outcome.	Match size, matched value band, Talent link, allowed effects, cost or limit.

Talent

Defines capability, permissions, dice support, and high-match effects.

Name, tier, category, triggers, dice effects, permissions, high-match table, costs, limits.

Condition

Tracks harm, exposure, pressure, impairment, or temporary state.

Name, severity, source, duration, dice effect, permission limits, removal conditions.

Burden

Represents a durable liability or obligation.

Name, source, pressure trigger, escalation trigger, relief condition, linked people or factions.

Bond

Represents a durable support tie or relationship.

Name, linked person/group/place, help trigger, demand trigger, strain condition.

EquipmentTag

Gives gear tactical identity without full item math.

Name, category, trigger, positional effect, pressure effect, wound interaction, drawback.

EraProfile

Defines the expected baseline for tools, threats, vehicles, vessels, sensors, magic-tech overlap, and scale assumptions.

Code, name, reference band, common tags, common threat types, range profile, scale assets, digital content filters.

CombatExchange

Resolves one burst of combat action.

Momentum side, spotlight actor, intent, active threat, movement intent, dice pool, outcome band, match result, consequences.

SpellEffect

Represents a magical action or ongoing magical result.

School or method, pace, target, source, cost, duration, maintained requirement, backlash profile.

CastingMethod

Defines how a spell is shaped and interrupted.

Method channel, required components, vulnerability, fallback method, interruption consequence.

Backlash

Represents magical failure, overstrain, or unstable side effect.

Trigger, severity, method channel, school signature, Condition output, containment option.

NonlethalObjective

Defines a combat intent that removes a threat without relying on lethal wounds.

Objective type, allowed tools, success effect, partial effect, escape condition, lethal fallout risk.

DistanceBand

Defines range relevance for melee, ranged, magical, vehicle, and sensor actions.

Name, theatre-of-mind meaning, square range, hex range, metric freeform range, meter thresholds, optional imperial equivalents, adjacent bands, permission requirements, pressure triggers, default movement effect.

MovementMode

Defines how far a character can reposition during an exchange and what the movement costs.

Name, meter threshold, grid threshold, freeform threshold, whether it can be incidental, pressure triggers, terrain modifiers, state changes.

WeaponRangeProfile

Defines the range permission for an attack form without creating full item statistics.

Name, comfortable bands, pressured extension bands, required tags or permissions, blocked bands, scale handling, CRPG range filters.

TargetingState

Defines whether one observer can identify, aim at, lock onto, or affect one target.

Observer, target, state name, source, confidence, valid attack types, bypass methods, break conditions, false-positive risk.

DetectionMethod

Defines how stealth, detection, locks, traces, and spoofing change targeting state.

Method name, source tag, sense type, required permission, target states it can improve or worsen, duration, break condition, false-positive behavior.

ResourceState

Defines ammunition, charge, heat, fuel, ritual load, or unstable buildup when the scene tracks it.

Resource name, current state, source item or spell, trigger, recovery method, consequence on cost, empty behavior, overload behavior.

CoverState

Defines protection, concealment, and line-of-effect limits.

Name, detection effect, wound interaction, bypass methods, break conditions.

Threat

Represents an opponent, group, hazard, or creature.

Threat scale, role, Talent tier, wound capacity, pressure options, cohesion triggers, special tags.

ThreatTemplate

Provides reusable defaults for creating threats quickly.

Scale, role defaults, wound capacity, pressure menu, tags, special rule, cohesion trigger.

ConflictScale

Defines whether action is personal, squad, force, vehicle, vessel, or strategic.

Scale name, acting unit, valid targets, mismatch handling, zoom triggers.

Force

Represents an army, company, formation, crew, fleet element, or other large group.

Size, quality, cohesion, command, supply, position, special assets, objective.

VehicleOrVessel

Represents a platform with systems rather than ordinary wounds.

Scale, crew roles, systems, tags, current position, mission objective, system damage.

CrewRole

Defines a player-facing station in vehicle or vessel conflict.

Role name, action menu, linked systems, valid pressures, spotlight status, fallback actions.

SystemDamage

Represents harm to a vehicle, vessel, force asset, or strategic system.

System name, severity, source, pressure effect, repair condition, escalation trigger.

Pressure

Represents short-lived disadvantage or tactical danger.

Name, source, die penalty, affected action type, duration, removal condition.

Wound

Represents combat harm as a Condition-like state.

Severity, source, body/system affected, treatment need, defeat contribution.

Permission

Answers whether an action is allowed cleanly.

Required Talent, tag, role, faction standing, tool, position, location, or prior action.

MomentumState

Tracks which side is pressing in combat.

Current side, last exchange, spotlight cycle, valid next actors, momentum change trigger.

HighMatchEffect

Adds extra effect beyond the base outcome.

Match size, matched value band, Talent link, allowed effects, cost or limit.

These objects do not need to become visible character-sheet fields unless play benefits from that. They are a design discipline behind the rules.

Table Language and Data Language

A rule can have two layers.

Layer Purpose Example

Layer	Purpose	Example
Table language	Easy to read, quick to use, and open to fictional judgment.	"`Reach` controls distance before shorter weapons can answer cleanly."
Data language	Clear enough to implement or simulate.	"`Reach` may create position advantage when the wielder controls approach distance; may cancel one close-quarters pressure until bypassed."

Table language

Easy to read, quick to use, and open to fictional judgment.

"Reach controls distance before shorter weapons can answer cleanly."

Data language

Clear enough to implement or simulate.

"Reach may create position advantage when the wielder controls approach distance; may cancel one close-quarters pressure until bypassed."

The table-facing layer should stay primary. The data layer exists to keep design choices concrete, testable, and portable.

Ranged Subsystem Schema Sketches

Use these sketches as implementation guidance for Ranged Combat and Distance. They are not final engine schemas; they show the minimum useful state shape.

{
  "object": "DistanceBand",
  "id": "short",
  "label": "Short",
  "max_meters": 18,
  "max_grid_units": 12,
  "max_tabletop_cm": 30,
  "adjacent_bands": ["near", "long"],
  "default_permissions": ["field_ranged", "short_ranged", "many_spells"]
}

{
  "object": "MovementMode",
  "id": "rush",
  "max_meters": 12,
  "max_grid_units": 8,
  "max_tabletop_cm": 20,
  "incidental": false,
  "typical_use": ["close_fast", "retreat", "reach_cover_under_pressure"],
  "default_pressure_triggers": ["exposed_under_fire", "difficult_terrain", "engaged_retreat"]
}

{
  "object": "WeaponRangeProfile",
  "id": "field_ranged",
  "comfortable_bands": ["short", "long"],
  "pressured_extension_bands": ["near", "far"],
  "typical_tags": ["precise", "reload", "limited"],
  "blocked_without_permission": ["engaged", "beyond_scene"]
}

{
  "object": "TargetingState",
  "observer_id": "pc_scout",
  "target_id": "hidden_shooter",
  "state": "concealed",
  "source": "smoke_and_partial_sound",
  "confidence": "medium",
  "valid_attack_types": ["area_ranged", "sensor_sweep"],
  "false_positive_risk": true
}

{
  "object": "DetectionMethod",
  "id": "thermal_scan",
  "source_tag": "revealing",
  "sense_type": "heat",
  "can_improve": ["hidden", "concealed", "obscured"],
  "can_create": ["locked"],
  "break_conditions": ["insulated_cover", "jammed_sensor", "lost_line"]
}

{
  "object": "ResourceState",
  "resource_id": "rifle_magazine",
  "source_item": "service_rifle",
  "state": "low",
  "trigger": "sustained_fire",
  "recovery_method": "reload_exchange",
  "consequence_on_cost": ["empty", "exposed_while_reloading"]
}

These sketches share a few assumptions.

Use stable IDs for states and profiles, with table-facing labels layered on top.
Store metric thresholds first; grid, hex, tabletop, and optional imperial values are display or adapter data.
Targeting is observer-target state. It should not be stored only as a global property on the target.
Resource state is optional until a tag, scene rule, or consequence makes it relevant.
Table rulings can still override the data layer, but repeated overrides should become new tags, permissions, or state rules.

Coding Readiness Checklist

Before a recurring mechanic is treated as stable, check the following.

Does it have a clear trigger?
Does it have a clear mechanical effect?
Does it say what kind of roll, scene, target, or state it applies to?
Does it say how long it lasts?
Does it say how it is removed, spent, resisted, or exhausted?
Does it interact cleanly with System Design Principles, Conditions, Talents, , , Ranged Combat and Distance, Nonlethal Combat and Capture, Threat Templates, Magic Under Pressure, and Scale Conflict and Vehicles?
Can it be simulated without needing a human to invent a new rule each time?

If the answer is no, the rule can still exist as table guidance, but it should not yet be treated as a stable mechanical component.

Future Use

Later digital-adaptation work should define optional schema examples for Talents, Conditions, era profiles, equipment tags, spell effects, casting methods, backlash, distance bands, movement modes, weapon range profiles, targeting states, detection methods, resource states, cover states, nonlethal objectives, threats, threat templates, conflict scales, forces, vehicles, vessels, crew roles, system damage, combat exchanges, and scene objectives.

The current document is not a programming standard. It is a design guardrail: table rules should remain expressive, but repeated mechanics should be concrete enough to codify.