Scenarios

Five scenarios ship with the engine. Each has its own deck of events, its own set of seats, and its own bet that the result is scored on.

A scenario is a YAML file: names and descriptions in both languages, seats and their powers, the starting meter state, phases with advance conditions, and a pool of events. All five live in backend/content/scenarios/.

Overview of the five packaged simulation scenarios
Overview of the five packaged simulation scenarios

The event cards are not assembled out of generic phrasing. Each one is retextured to a specific team, a specific product and a specific quarter: a card that arrives in someone else’s fiction teaches nothing.

The seat with the accent is the leading one. Whoever drives the session takes it, and it is the only seat that is never bot-filled.

Signal Triage

signal-triage

A production alert is firing. Stabilize the system, then find the root cause before the clock runs out.

The incident half of the job: stop the bleeding first, find the cause second, and pay for both. A rollback buys stability and costs a week of somebody's work.

Players
1-4
Roles
  • Incident Lead
  • Engineer
  • Comms
  • Stakeholder
Meters
  • trust
  • morale
  • quality
  • sev
  • stability

The Quarter Commit

quarter-commit

You promised your biggest customer a launch this quarter. The team, the roadmap and the renewal date all disagree about what that means.

You cannot ship everything you promised, keep the quality you claim to have, and keep the team you need next quarter. The first phase cannot be passed by working harder, only by deciding what not to build.

Players
1-4
Roles
  • Product Manager
  • Engineering Manager
  • Tech Lead
  • Designer
Meters
  • trust
  • morale
  • quality
  • scope
  • techDebt
  • outcome

Design Debt

design-debt

Six years of shipping fast left a product with four button styles and no system. A rebrand deadline is now forcing the question of what consistency is worth.

A system everyone uses, a date the business believes, a team that still enjoys the work: pick two, on purpose, and be able to say which one you dropped. The seats that lead here are the design lead and the tech lead.

Players
1-4
Roles
  • Design Lead
  • Tech Lead
  • Product Manager
  • Engineering Manager
Meters
  • trust
  • morale
  • quality
  • scope
  • techDebt
  • outcome
  • consistency

The Growth Squeeze

growth-squeeze

A consumer subscription app with one quarter to turn free users into paying ones. Every lever that moves the number faster also moves it further from the product people liked.

Growth tactics that work now and cost trust later, monetization that moves revenue and moves users away, and metrics that improve while the product gets worse. Quality is scored here on purpose.

Players
1-4
Roles
  • Product Manager
  • Growth Analyst
  • Engineering Manager
  • Product Designer
Meters
  • trust
  • morale
  • quality
  • users
  • conversion
  • revenue
  • techDebt
  • outcome

The Second Team

second-team

Your team outgrew the number of people one manager can hold. It has to become two teams this quarter – the same quarter you promised a delivery.

The new person costs you the quarter they arrive in. You can split ownership fast or split knowledge properly, not both by the deadline. And every hour you spend doing the work is an hour nobody else learns to do it.

Players
1-4
Roles
  • Engineering Manager
  • Tech Lead
  • Senior Engineer
  • Product Manager
Meters
  • trust
  • morale
  • quality
  • scope
  • techDebt
  • outcome
  • bench
  • runway

What all five have in common

No card has an obviously right option. This is checked automatically: the lint fails a card where one option is strictly better than the rest on the scored meters.

Delayed consequences are telegraphed. An effect landing several rounds later has to be shown in advance, so the cheap moment to prevent a problem passes before the problem becomes expensive. That is a build lint too.

The first phase cannot be passed by doing nothing. The starting values sit on the wrong side of the gate on purpose: opening it requires deciding something.

Writing your own

The format is open. The schema is in docs/scenarios/schema/scenario.schema.json, the scenario model in docs/scenarios/scenario-model.md. The condition grammar that phase advances and event triggers are written in lives in docs/architecture/condition-grammar.md.

A file goes through load, validation and composition before a session pins it. A schema error, an unknown meter name in an expression, or a card with a dominant option is a failed build, not a review comment.