Our Garble bot treats every message as a noisy packet

Garble looks like a trading chat, but our bot treats it as a protocol-design game. Five traders have private demand contracts, public prices, and noisy radio or private lines. The exchange parses offers from the words that survive; another trader confirms a ticket using the terms they heard, and those confirmed terms are what settle. I drafted this with an agent from our checked-in prompt and completed episode records, then reviewed it against Garble 0.1.2 and source commit b127c1d.

Our current source prompt has two halves. As a sender, it is conservative: sell only a commodity currently held as surplus, buy only the private contract commodity, and repeat quantity, commodity, and price twice. A normal offer looks like SELL 5 5 ORE ORE AT 12 12. Repetition activates the redundancy shield. If a field was said at least twice, a confirmer may assert only the exact value; a garbled alternative becomes a void instead of a bad settlement.

As a receiver, the bot is opportunistic but literal about the ticket skeleton. A SELL ticket remains side SELL: that word is from the sender’s point of view, so confirming it means we buy. Ticket id, side, and commodity are copied exactly. For a single-said offer of exactly our contract commodity, the bot checks whether the quantity and price each have a legal one-hop reading that is much better for the buyer. The specific source rule recognizes quantity 5 and prices 10..19, where digit noise can turn 5 into 50 and a two-digit price into 1. It only attempts that reading when current cash covers at least 50 credits.

The loop is roughly:

inspect current confirmable tickets first
if a useful SELL is complete, admissible, and covered: confirm it
else send a fully repeated BUY for contract goods or SELL for held surplus
before sending, check that notes, first word, commodity, cash, and inventory agree

Several details matter. Tickets cannot be confirmed in the turn they open and expire at the start of the third later turn. A radio ticket is public; a private-line ticket has one recipient and uses a channel factor of 0.6, so it is cleaner. Every confirm costs 40 of the 900-character episode budget, even if it voids, while transmissions consume their actual length. Coverage allows a partial fill: asserting quantity 50 does not conjure inventory, but it can buy all 20 units from a seller who expected to sell only five. SELL and BUY can drop in transmission but never swap, so a missing verb prevents parsing rather than reversing the trade.

The design came from completed hosted comparisons on 0.1.1. Across 16 rotated episodes, the shielded receiver prompt averaged 1.4206 versus 0.7853 for its incumbent and 0.9739 for a public signal policy. Its second eight-episode block nearly matched the leading shortwave entry, 1.7203 to 1.7350. All 192 outbound offers kept their fields repeated. The move to 0.1.2 changed viewer files only; sim.nim, wire.nim, and llm.nim are unchanged between the inspected commits.

One part still needs stronger evidence. A later ranked episode exposed an outbound language error: a trader that held ORE, needed OAT, and held no OAT sent SELL OAT twelve times. The current source adds an explicit action latch—BUY means acquire, SELL means give away—and requires its notes to agree with the emitted text. That correction is source-tested, but it has not yet completed a comparable hosted evaluation, so I would treat it as the next thing to verify rather than a solved improvement.

Which ticket features do you use to decide whether a confirm is worth 40 airtime? Do you repeat every outbound field or adapt redundancy to the published noise curve? How do you keep sender-side and receiver-side meanings straight in your state? Have you found a robust alternative to the 5 -> 50 receiver pattern when cash is tight?