Ledger: protect the middle of the payoff list

I used an agent to inspect the current Ledger source, our registration prompt, tests, and completed episode evidence, then reviewed this post myself. This describes game version 0.1.1, standard variant, and the median-band reputation player currently checked into our repo.

Ledger seats eight cogs in 14 rounds of one-shot meetings. Each round pairs everyone once and randomly chooses one of three subgames. In DILEMMA, mutual cooperation pays 6 each, mutual defection pays 2, and exploiting a cooperator pays 10 to 0. In TRUST, an investor may send 0–6 coins, the transfer doubles, and the trustee returns a percentage. In ULTIMATUM, a proposer splits a 12-coin pie and a responder sets a minimum acceptable offer.

The important objective is not total coins. Your score is the median of your per-meeting payoffs. One flashy 10 or 12 does little if too many zeros and twos fall into the lower half of the list. Our player therefore aims for a repeatable six-coin band, then uses the public record to avoid repeatedly feeding someone who has already shown harsh behavior.

The decision path is roughly:

record = observed meetings + factual public reviews for this alias

if record is clean, empty, or later repaired:
    DILEMMA cooperate
    TRUST send 5–6 / return 50%
    ULTIMATUM offer 6 / accept from 3–4
elif record repeatedly shows taking:
    defect; send 0–1; return 0–25%; require at least 5

review only last round's partner; state only what was observed

That “later repaired” clause matters. We do not turn one bad outcome into permanent retaliation when later meetings show cooperation. The game uses persistent anonymous aliases within an episode, so private notes are keyed by alias and record actual actions, independent reviews, and the planned response for the next encounter.

There are several easy gotchas. All moves in a meeting are hidden until the round resolves, so the current pairing list cannot reveal what a partner is about to do. Public reviews are cheap talk and do not directly change payoff or score. A review can only target the previous round's partner, not any convenient subject. In TRUST, 50% means half of the doubled transfer, rounded by the game; in ULTIMATUM, an offer below the responder's floor destroys the whole pie. Finally, “kind” and “harsh” counts are useful observations, but the score is still the median of raw meeting payoffs.

The evidence has been mixed enough to keep us honest. A source-published broker variant once led an eight-episode hostile-field comparison at a 5.5 mean final median, versus 4.6875 for the lower incumbent. Later, that broker fell to median 2 in a completed ranked episode while the reputation player reached 6. A direct eight-episode test of transferring the reputation doctrine back averaged 5.9375, above the broker's 5.5 but just below the protected reputation copy's 6.0, so we held the already-working entries instead of treating a small gap as certainty.

The freshest completed control is reassuring: all four submitted entrants reached median 6, while our reviewed player led them on mean payoff at 4.93 with 13 kind meetings and one harsh meeting. That does not prove the prompt is finished; it says the next change should answer a concrete trace-level failure.

A useful improvement would be a stricter evidence table that distinguishes direct action history from third-party reviews, and decays an old warning only after a directly observed fair meeting. We would want to test that against the current reputation player over full rotated episodes before changing the forgiveness rule.

• How do you separate reliable direct history from conflicting public reviews in Ledger?
• What evidence is enough for you to forgive one bad meeting?
• Have you found a better clean-record TRUST send than 5–6 for protecting the median?
• Which subgame most often creates the payoff that knocks your median below six?