How it works
One invariant loop with everything else built around it: seats and roles, rounds and phases, a decision queue with real due dates, standing rules, shared meters, and a retro at the end.
Seats and roles
A scenario defines four seats. Each carries its own verbs: the engineer can investigate, mitigate, fix; the product manager can commit-scope, prioritize, talk-to-stakeholder; the engineering manager can protect-team, open-requisition, set-standards.
The powers are asymmetric on purpose. No single seat can clear a card alone: relieving a pressure means chaining verbs together, which means agreeing with someone. That is what produces the conversation, not the chat feature.
Information is asymmetric too. The same event is revealed differently per seat: one player sees the error rate, another sees the angry customer, another sees the messy code path.
Unfilled seats are driven by the engine. Every scenario declares a player range – in all five packaged scenarios that is one to four. Bots take the empty seats: when a round closes, a bot plays its seat down a chain of standing rules, so a partial table never deadlocks. One seat per scenario is marked as never bot-filled. That is the seat the driving player takes, and handing it to a bot would mean handing the bot the scenario’s own question.
Rounds and phases
The round is the atomic unit of play, and it is not tied to a wall clock: a round closes when the seats have checked in, not when real time has elapsed.
One round: a pressure lands → each seat sees its slice → deliberation → players spend capacity on intents → the engine applies deterministic effects → the meters move → next round.
Phases are gates between rounds. A phase has a goal and an advance condition written as an expression over the meters: in The Quarter Commit, the commit phase only ends at scope <= 55. A condition like that cannot be passed by working harder, only by deciding what you are not going to build.
A seat has checked in if it acted, passed, left a standing order that covers this round, or timed out. Absence never blocks the others; it only resolves through a weaker path.
Decisions with a due date
Decisions are objects here, not lines of dialogue. Anything raised during a round queues up: expiring standing orders, armed fuses about to fire, work-in-progress overruns needing a call, items pending quorum.
Each item carries its options, a due round, the rule for who actually closes it (owner decides, quorum, consensus), and the list of seats holding relevant private information. Running past due does not pause the game: the item auto-resolves, worst case.
Deferring is an explicit move. It is recorded, and the deferral chain surfaces at the retro.
Actions are split by blast radius:
| Tier | What it covers | When it resolves |
|---|---|---|
| Solo | local and reversible: investigate, prepare, a small local fix | any time, nobody else needed |
| Quorum | medium: adopt a policy, reprioritize the backlog | async approval by N teammates |
| Gate | irreversible: ship to prod, a big spend, a hire | only at a sync window |
Standing rules
Two kinds of rule keep working while you are away.
Standing orders are personal. “If an incident fires, mitigate first.” “Auto-approve infra spend up to X.” “Ops holds my vote until I am back.” You leave a rule behind, and it plays your seat for you.
The best drama in the model lives right here: an order can be wrong for the situation that actually arrived. “I said always roll back” – and this rollback nuked the migration. The present team lives with the absent player’s rule until it can muster quorum to override it.
Policies are collective. They are adopted, amended and repealed at the governance meeting, and they sit in a ledger everyone can see. The content rule is strict: a policy must carry a coupled downside. A policy that is all upside does not pass the build.
The meters
The meters are shared. When the developer cuts a corner to hit the date, quality drops for everyone; when the PM over-promises, trust rises now and scope pressure crushes the team next round.
Soft meters are trust, morale, quality, scope, techDebt, outcome. Events and actions nudge them; letting one hit its floor is a lose condition.
Hard resources are spent rather than nudged: capacity (actions per round), the deadline (a clock that always ticks), and whatever actually runs out in this particular world. Deliberately not a universal wallet: a startup runs out of money, a large company runs out of approved headcount and executive attention.
Scenarios declare their own meters. consistency in Design Debt, bench in The Second Team, conversion and revenue in The Growth Squeeze. Declaring the name is what makes it legal in that scenario’s conditions, effects and triggers.
Capacity is coupled to work already started: free = total − committed. That coupling creates the game’s main recurring choice: pull people off their in-progress work to fight the fire, or let it burn.
The retro
A session ends with a retro, and the retro is not an appendix to the game. It is what the game was played for.
The retro is compiled from the event log: what happened, which decisions you made and which path closed them, what you deferred and how many times, how the meters moved, and which chains pulled one thing out of another. There is a personal slice as well: only your own actions and only your own data, with nobody else’s hidden incentives in it.
One rule is hard: no lecturing. Phrasing like “the lesson here is” or “in real life” is rejected at validation. The single takeaway a retro is allowed to state has to be grounded in this session (“we cut quality and it came back”), never in product management in general.
What the language model does, and what the engine does
It is easy to get this wrong in both directions, so let me be exact.
The game runs fully without a language model. With no key the gateway degrades and every session runs on the scripted tier. That tier is not a stub: the requirement is that it must be able to run a whole session alone. The standup becomes a templated digest, the agenda a list, the retro a timeline from the event log with an engine-computed outcome. A lesser text, but still a session with a beginning, a middle and a reckoning.
The model never mutates game state. Every output enters the server as a proposal and is validated against engine rules before anything is committed. The engine counts the votes, applies decision rights and commits the outcome. The model narrates, facilitates and compiles proposals, but never closes a decision.
What the model adds: language. The connective narration between standup beats, the voices of engine-driven characters, engine-computed numbers framed in human words, and depth in the retro.
So the exact description is not “a game built on a language model” but “a deterministic engine with a model speaking on top of it”.