The Personal Assistants (PAs)
C.A.T.S. is designed to be played with a digital assistant at every seat — and a different one behind the screen.
There are two assistants, not one. They are different products with different jobs, and conflating them produces a tool that serves neither.
| Player PA | GM PA | |
|---|---|---|
| Runs on | Every player's phone, tablet, or laptop | The GM's machine |
| Owns | One unit and its crew | The encounter, the opposition, the world |
| Sees | Only what that player knows | Everything |
| Core loop | Declare, roll, read the outcome | Frame, adjudicate, run opposition |
| Key screens | Unit record, damage state, action menu, roll entry | Encounter board, NPC statblocks, initiative, terrain and environment, secrets |
| Must never | Choose the player's action | Override the written rules silently |
The information boundary is the hard part. The GM PA holds things the Player PA must not reveal — hidden units, unrevealed damage, ambushes, faction intentions. That boundary has to be enforced at the data layer, not by hiding UI, because anyone can open dev tools. Any shared state must be authored so that the player client is never sent what it must not show.
This is the same discipline as keeping GM material out of a published site: the answer is not to hide it client-side but to never ship it.
Platform path
Web first, everywhere eventually.
| Stage | Target | Note |
|---|---|---|
| 1 | Web app, offline-capable | Same Deno/TypeScript/Cloudflare stack as the design site. Works on every device with a browser today |
| 2 | Installable PWA | Offline-first, home-screen icon, no app store. Covers most of the value of a native app at a fraction of the cost |
| 3 | Native iOS and Android | Only if the PWA proves genuinely insufficient — push, background sync, or store presence |
Design consequence for stage 3: keep every rule in the shared TypeScript model (tools/lib/) rather than in UI code. If the rules live in the model layer, a native client is a new front end over the same engine. If they leak into the web UI, every platform becomes a reimplementation and the platforms will drift.
The offline requirement from the rules below is not negotiable at any stage: a table in a basement with no signal must work.
The Player Assistant
C.A.T.S. is designed to be played with a digital assistant at every seat.
This is a foundational architectural assumption, not an optional convenience. Each player is expected to have a phone, tablet, or laptop running an app or web client. The game is still played at a table with physical dice — the PA handles the crunch so the table keeps moving.
The system is designed around this. It is not a paper game with an optional helper app.
What this actually changes
The obvious reading is "the PA makes complexity cheaper." That is true but it is the less useful half. The important consequence is that it changes which kind of complexity is worth having.
| Cost type | Example | Paid by | PA effect |
|---|---|---|---|
| Bookkeeping | Tracking 14 component states, recomputing derived stats, cross-referencing three tables | The PA | Collapses to near zero |
| Decision | Choosing among 12 actions, weighing Heat against alpha strike, picking a called shot | The player | Unchanged |
| Comprehension | Understanding why a shot bounced, what a condition means, what changed since last turn | The player | Improved, but only with deliberate design |
A PA cannot think for you. So the design should push crunch toward the first row and away from the second, and spend the freed budget on making the third row excellent.
This inverts one of the brief's original constraints. "Bounded bookkeeping — detail should create decisions, not require constant arithmetic or excessive lookup" was written as a limit on mechanical depth. With a PA it becomes a limit on decision breadth instead. Arithmetic and lookup stop being the enemy. Option paralysis and opaque outcomes become the enemy.
Restated goal: detail should create decisions. The PA absorbs everything that isn't one.
Division of labor
| Stays at the table | Handled by the PA |
|---|---|
| Rolling dice, physically | All arithmetic and derived values |
| Declaring intent and targets | Hit location and facing resolution |
| Choosing how to spend Edges | Penetration Margin and band lookup |
| Tactical decisions and tradeoffs | Armor, Structure, and Component state tracking |
| Table talk, arguments, GM rulings | Heat and Power accounting |
| Reading results aloud | Ammunition states, conditions, timers |
| Fiction and description | Legal-action filtering and range/arc checks |
| Post-combat damage records, repair, salvage |
The dividing principle: the PA computes and remembers; the player decides and rolls.
Which rolls stay physical
Not every roll should be a physical one. The distinction worth designing around is dramatic weight, not mechanical importance.
| Roll | Where | Why |
|---|---|---|
| Attack check (2d10) | Physical | The moment of tension. This is why people came to the table |
| Damage, where dice are involved | Physical | Directly felt consequence |
| Component Check | Physical | High drama — this is where a unit loses a weapon |
| Hit location | PA | Administrative. Rolling and cross-referencing a table adds nothing |
| Initiative | PA | Pure sequencing |
| Ammunition and reliability checks | PA | Background state |
| Opposed rolls the player doesn't own | PA | Not their moment |
Rolling dice is the ritual the physical table exists for. Spending it on table lookups wastes it. A rough target: two to three physical rolls per player turn, all of them consequential.
This has a direct bearing on OQ-09 (exploding dice) — every explosion is an additional physical roll and an additional input step, so the cost is real even though the arithmetic is free.
What the PA must never do
The PA is a calculator and a memory, not a player and not a referee.
- Never choose a player's action. It may show options and consequences; it must not recommend or rank them by default.
- Never hide the math. Every computed result must be expandable to show its inputs. A player who wants to verify a Penetration Margin by hand must always be able to.
- Never enforce a GM ruling. Every automated result must be overridable. The GM's word outranks the app, always.
- Never become the rulebook of record. The written rules are authoritative; the PA implements them. Where they disagree, the PA has a bug.
- Never require connectivity to play. A table in a basement with no signal must work.
That fourth point is the one most likely to erode in practice, and it matters most. If the rules only exist as code, the game cannot be learned, argued about, house-ruled, or played without the app — and it stops being a tabletop RPG.
Consequences for the rules design
Rules must be computable
Any mechanic the PA is expected to handle must be a deterministic function of game state. That is a real design constraint, and a new one:
- No rule that depends on unstated GM judgment in its automated path.
- Every table must have total coverage — no gaps, no "GM decides" fallthrough in a computed step.
- Every condition needs an explicit trigger, duration, and end condition.
- Every modifier needs a defined stacking rule.
Where human judgment genuinely belongs — the brief's "the fiction clearly exposes a particular component," for instance — it must be marked as an explicit, deliberate handoff to the GM, not left as an ambiguity for an implementer to guess at.
The data schema is now the critical path
The schema stopped being documentation and became an application specification. It needs to be machine-readable (JSON Schema), versioned, and validated. Every unit, weapon, component, and condition becomes data the PA consumes.
This raises the schema's priority in the build order — it now sits immediately behind scale numerology rather than well behind it.
Complexity modes mean something different
The brief targets Standard as the default, with Tactical and Engineering as add-ons. With a PA, the calculus shifts: the cost of Tactical mode was mostly bookkeeping, which the PA absorbs.
The modes may be better understood as presentation layers over one full simulation — the PA always computes at full fidelity, and the mode controls how much is surfaced and how many decisions the player is asked to make. That is a materially different architecture than four separate rulesets, and it should be decided deliberately. See OQ-18.
Speed target changes
The brief asks whether an attack resolves in under 45 seconds. With a PA the bottleneck is no longer lookup — it is roll, input, read, decide. The meaningful measures become taps per turn and time from roll to stated outcome. Lookup time is no longer the thing to optimize.
Failure modes to design against
| Risk | Mitigation |
|---|---|
| Players heads-down in screens instead of at the table | PA output should be glanceable. Results belong spoken aloud, not read silently |
| Dead battery, lost device, no signal | Offline-first, plus a genuine paper fallback path (OQ-15) |
| The app becomes the rules | Written rules stay authoritative and complete on their own |
| Automation hides the game | Every result expandable to its inputs; players should learn the system by playing, not be insulated from it |
| Complexity creep because it's "free" | It is free for the PA, never for the player's attention. Decision cost still binds |
That last one is the discipline this whole document exists to enforce. "The PA can handle it" is not a justification for a mechanic. "This creates an interesting decision" remains the only justification.