coerce(): when the code overrules the model
coerce() is the last word on every decision. It drops forbidden actions, enforces gates and confidence floors, refuses moves the character cannot afford, and puts every override on screen in amber.
The model answers; coerce() decides whether that answer survives contact with the rules. It sits between the call and the effect, and everything it changes is recorded instead of swallowed.
What it checks
- Forbidden actions. A class rig may simply not have a move: Bo cannot expose, and Quill cannot whip, leak or undercut.
- Gates. A move may be locked until a beat (Nyx before 12) or by state.
- Confidence floors. Below a character's floor, their own read does not count and they fall back.
- Empty tanks. You cannot spend energy you do not have, and a rig may have made the move cost more than it looks.
- Targets. The target must still be reachable and still in play by the time the answer lands.
Overrides are the show, not the plumbing
"The code overruled the model" is the most interesting event on the screen, so the guest's board prints it in amber: what was chosen, what happened instead, and which rule did it. A simulation that hides its overrides is asking to be taken on trust.
It is also how a watcher learns the rules without reading any. Watch Nyx's reads get thrown away three times and you have learned her floor.
Why not constrain the prompt instead
Partly because it is not reliable, and partly because the override is worth having. A prompt that forbids a move produces a model that mostly avoids it. A rule that forbids a move produces a character who wanted to and could not, which is both more interesting and more legible.
The legal option set is narrowed before the call too. Coercion catches what remains: state that moved while the call was in flight, and anything the rig prices out.
Read next
Personality as arithmetic, not flavour text
A character in Parlour is a class, meaning what they are allowed to do, plus a rig of code-level modifiers: prices halved or raised, moves forbidden, confidence floors, effects that bounce. No character has a personality paragraph.
Typed questions: choice, score, boolean
Parlour asks three shapes of question: a choice over options, a score on ordered levels, and a boolean. The option sets are built per character per beat from the rules, so the model can only pick something legal.
The state object: what one character can see
Each call carries a JSON state built for one character: their own condition, the people in reach, what they can remember of the last few beats, and the arithmetic of the prize. Never the whole world, and never the rules.
Two clocks: real time, not turns
Characters act on their own clocks. Each one wakes when its cadence comes round, makes its call, and moves the instant the answer lands, while the slow physics and the room's decisions run on beat boundaries.