A delivery round is worth 71 coins, not 9

In Sillon, the station counter pays out earnings at the end of each stop: passenger waits, parcel deliveries, everything fell under the same "bonus" label. On a full run's report you would read "bonus 384" with no way to tell whether freight weighed ten coins in it or three hundred. A code comment owned up to this quite calmly. That did not make it a measurement.

Freight is my recent worksite: a parcel basket, rounds loaded in the city, destinations at the line's regulars. Before deciding what to build around it, one basic question: what does it actually earn, in an actual run?

First move: separate the accounting line. The label splits in two, the amount paid does not move by a cent: 108 coins of deliveries plus 276 of bonuses make the 384 from before. Measured on my completionist player profile, 42 trips: freight weighs 108 coins out of a full run's 1083, ten percent, for twelve parcels delivered at 9 coins each, the code's constant rate.

The assertion guarding this split checks both halves: the freight line rises by the exact rate, and the bonus line does not rise by that amount. Without the second half, counting the same payment twice would pass for a success. And the existing conservation assertion stays green: the sum of the lines still equals the coins earned, nothing was invented.

That left the round itself, the worksite's showpiece: in the city you load four to twelve parcels and distribute them going back down the line. My autopilot, which plays entire campaigns for me, had almost nothing to say about it: its only useful city visit fell on trip 47 of 52, it loaded seven parcels and delivered just one before returning to the depot. Read naively, the report said: a round pays 9 coins, which is to say nothing.

I almost took that number for a verdict. A round worth nothing is a mechanic to rework, maybe to cut. It would have been a measurement error mistaken for a design conclusion: the pilot had not measured the round, it had measured its own inability to finish one.

The probe that settles it calls the game's real code, the one that fills the basket in the city, and reads what it placed in the queue. Copying the draw rule into the probe would have created a second version of it, which would have diverged at the first tuning pass; that very morning, two scene builders had just pulled that trick on me.

Four hundred draws: size from four to twelve parcels, average 7.85, the code's bounds hold. An average round pays 71 coins, at 9 coins per parcel. And those 71 coins are added on stops you make anyway for the passengers: on the descent from the city to the depot, that is well over half again as much income, without a single extra trip. Even the minimal four-parcel round is not a loss. The "losing floor" announced by my risk sheet is not confirmed by the measurement.

The 400 draws returned a fact I was not looking for: destinations are not uniform. Two stations receive nearly three times more parcels than the others. It is not a defect, it is a traceable consequence of my own rules: a share of parcels targets a regular's home station, and from the city only two regulars are eligible. A design consequence worth knowing: a round is mostly a race over the first third of the descent. That kind of fact never comes out of reading the code; it comes out of a distribution.

Before tuning an economy mechanic, you need three things I did not have: an accounting line of its own, a distribution instead of an anecdote, and a probe that queries the code's real path. All of it fit in one session, and it reversed the verdict: the round did not need saving, it was already profitable. The worthless number was my hurried pilot's.