One engine — the modes are policy.

Clause order carries the semantics. The first clause matches on the type alone — the _golden wildcard discards the marker, so type: "golden" reaches the blind, sealed mode whatever the flag reads. The second clause requires the marker: policies_for(_classic, true) is the Golden Room, a live top-K tournament on the classic base. The third clause is the floor — an ordinary classic game, live feedback and a winner-take-all pool.

The comment above the room map in create_room/3 pins the distinction: golden: true is a tournament marker, orthogonal to the type — a Golden Room is type: "classic" and fans out live; the blind mode is reached only by an explicit type: "golden".

One label carries its own gloss. In the second clause, "proportional" labels top_k_split — a rank-weighted split over the pool — not Economy.proportional/2, a different function. The fork’s own comment records this.

And one value never moves: scoring: "linear" appears in all three clauses. The distance math — 100 - 20·d per position, summing to 600 for a perfect crack — is the one path every mode shares. The fork moves only what a guess reveals, when settlement runs, and how the pool pays.

The map row lands in one table. Codemojex.Schemas.Game declares schema "games" — one table for every mode, with the discriminator and the four policies as plain columns: field :type, :string, default: "classic" · field :feedback, :string, default: "score" · field :scoring, :string, default: "linear" · field :settlement, :string, default: "live" · field :economy, :string, default: "winner_take_all". The schema’s own comment names the shape: the engine discriminator + the four policies the type selects (snapshotted from the room at start).

One table, not a table per type, because in BCS the brand is the type. The 14-byte GAM id is the one value that crosses every boundary — the Postgres row, the near-cache entry, the bus message, the channel topic. A per-type table would fork that one identity; the discriminator keeps one entity whose behaviour is data.

The snapshot also protects a game in flight. The comment beside the golden props reads: Golden Rooms props are snapshotted, so a game in flight is unaffected by a later edit to its room. The split weights carry the same note — a game settles by the split it was created under.

All three branches end the same way: the game is written back settled and the room returns to waiting for its next game. The difference is the pay. close_live ranks the board and pays the whole pool to the max-score player through Economy.winner_take_all. close_split reads the board wide enough to cover every member, drains the pool to the top-K by the split weights through Economy.top_k_split, and grants every other member div(score, 10) consolation clips in one Wallet.distribute_pool transaction — no reveal phase. close_sealed first exposes the secret and nonce (status :revealing), then pays the top-K and broadcasts one fat revealed event carrying the secret, the nonce, the commitment, the final board, and the payouts.

The dispatch reads r — the game’s own map — not the room. The policy value chosen at start selects the behaviour at close. The three closes in depth are C4’s territory: Scoring and Settlement.

The design’s claim, and the shipped history behind it: a radical variant is a new set of policy values on the same entities, not new code.

The Golden Room tournament arrived exactly this way (cm.5) — a third settlement value, live_split, with its economy label proportional, on the same GAM, the same games table, the same linear scoring, the same secret path. No new table, no new branded namespace, no second engine.

Four (type, golden) combinations land on three clauses today; a new mode is a new clause returning a new map of the same four keys. Modes thread the course rather than owning a chapter: the secret and its commitment are C2, the three closes in depth are C4, the buy-in-funded pool is C5.