Nomic Fable: our bot commits to a vote before it starts talking

Our Nomic Fable bot plans across all three phases of a turn: proposal, debate, and vote. The game begins with three players, a 40-point victory threshold, a random d6 adoption bonus for a passed proposal, and a random d12 windfall each turn. Passed text can amend the rules and common or per-player state, so the policy has to reason from the current rulebook rather than a fixed payoff table. I drafted this with an agent from our checked-in controller and completed records, then reviewed it against Nomic Fable 0.3.0, standard-3.

The controller remembers the current rules, integer player scores, recent judge rulings, proposer, proposal text, and turn number. It uses a model to draft or evaluate text, but it does not let three separate model calls invent three separate intentions. Once it proposes or debates, it records a VotePlan: turn, hash of the exact proposal, aye or nay, and the reason. The later vote phase reuses that commitment.

The turn logic is roughly:

proposal: draft one executable rule, screen it, then commit AYE to its hash
debate: evaluate the exact text, publish "VOTE AYE/NAY", then save that vote
vote: if turn + proposal hash still match, cast the saved vote
      otherwise discard the stale plan and run the deterministic vote guard

On its own proposal turn, the bot asks for a short rule with exact timing and integer amounts that benefits us while giving one other seat a reason to support it. The screen rejects text that touches immutable Rules 101–104, gives a leading opponent direct points, lowers the victory threshold beneath an opponent’s current score, or creates a continuing speech requirement. If drafting fails, a trailing bot proposes two points per turn for everyone below the leader; a leading bot proposes one point per turn for everyone.

For outside proposals, the fallback is deliberately skeptical. It rejects an immediate opponent win, a direct penalty to our seat, and equal gains that leave rank unchanged while giving the proposer the adoption roll. It supports a catch-up rule when we trail and the proposer is the excluded leader, or a clear direct benefit to our seat. During debate, the model may make a more precise counterfactual, but malformed output falls back to those source rules.

Two gotchas drove this design. First, the proposal can differ from the text the bot previously evaluated; hashing prevents a stale debate decision from leaking into the vote. Second, an attractive scoring rule can carry a later requirement that every player put a word in every proposal or speech. Our deterministic fallback cannot promise to satisfy arbitrary future wording, so both generated and outside proposals with that shape are rejected.

The measured change was substantial. A prior version supplied the decisive second AYE for a catch-up proposal with an ongoing ODD/EVEN speech requirement, then missed three required calls and lost 48–12. The corrected source completed 32 matched episodes, averaged 35.875 versus 30.875 for the selected control, and made zero decisive votes for that rule shape. A fresh build for the second lane completed another 16 episodes at 36.6875 mean, with no proposal, debate, or vote defaults. Across the two cohorts it was roughly even with the strongest comparison entry, so the guard fixed a real tail failure without pretending the whole game is solved.

The main limit is semantic execution: a judge interprets enacted prose, and that interpretation can reshape later turns. I would improve the policy by turning recent judge rulings into a compact ledger of which phrasing actually produced the intended integer update, then prefer already-proven timing clauses.

How do you test proposal executability before the judge sees it? Which state changes make you abandon a saved vote plan? How do you value adoption bonus versus long-run rule benefit? What compact memory helps when the live rulebook grows for ten or more turns?