This is an old revision of the document!


This page is a work in progress… Most content is currently deprecated while I'm working on a major rules revision.

Core Rules: The Kernel Contract (How the Core Stays Simple)

The Core Rules are designed to be easy to learn and fast to run at the table.
To keep that promise, the Core follows a fixed sequence each Hand, and any optional rules (“Extensions”) are only allowed to plug into specific steps of that sequence.

This is called the Kernel Contract.

What this means

  • Core stays small: you can learn it quickly and play right away.
  • Extensions stay clean: each Extension must say exactly which step it modifies.
  • No exception spaghetti: if a new rule can’t be described as “it changes Step X in this one way,” it probably costs too much complexity.

The Kernel Contract: the 6 Steps of a Hand

Each Hand follows these steps in order:

Step 1: Engagement (Who is interacting?)

The GM identifies which Actors are actually involved with each other *this Hand*.
In big chaotic fights, the GM may split the conflict into smaller interaction groups (clusters) so the table doesn’t bog down.

Step 2: Commit (Everyone locks in their choices)

Each involved Actor:

  • pays the required ante (if used),
  • chooses a Trine Aspect (Mind / Body / Spirit),
  • chooses an Attribute action,
  • chooses how many Power tokens to commit (your bid).

These choices are normally made face-down to preserve bluffing.

Step 3: Reveal (Turn the cards over)

Everyone reveals what they committed: their Trine Aspect, Attribute, and bid.

Step 4: Resolve (Figure out who has the advantage)

Resolve the “who beats who” layers in the same order every time:

  • Resolve TD (Trine Dominance)
  • award the pot (if using antes / pot bonuses)
  • Resolve AD (Attribute Dominance)
  • check for Sweep (winning both TD and AD against the same opponent, if Sweep is enabled)

This step produces each side’s final advantage going into the outcome.

Step 5: Outcome (What happens?)

Use the final results to determine what happens:

  • damage (if this is an attack),
  • progress, control, or Degrees of Success (if this is not damage),
  • any other immediate effects.

Step 6: Update State (Apply changes that carry forward)

Apply lasting changes:

  • reduce Attribute Values from damage,
  • check elimination / defeat conditions,
  • update any ongoing effects that remain active,
  • return any tokens that refresh now (unless an effect keeps them committed).

Extension Rule: “Plug In, Don’t Rewrite”

Optional systems (Extensions) must attach to one or more named steps above, and only modify that step in a stated way.

Examples:

  • Tempo / Phases plugs into Step 5 (it changes *when* outcomes resolve).
  • Range / Movement plugs into Step 1 (it changes who can legally target whom).
  • Equipment plugs into Step 5 (it modifies damage dealt/taken, and sometimes timing if Tempo is enabled).
  • Buffs / Shields / Stances plug into Step 6 (they keep some tokens committed and reduce what you can bid later).

If an Extension needs lots of “except when…” clauses, it should be rewritten until it can fit cleanly into this contract.

Design Workflow (How we avoid rework)

  • It is okay to share a roadmap of future ideas early.
  • But we only “lock” one small, testable rule at a time.
  • The Kernel Contract is the stable backbone that prevents later modules from breaking the Core.