Why almost everything I build has “sim” in the name

Looking back at this year I noticed something. It is right there in the names:

• Fly4cast — can this drone take off today?
• Mutfaksim — what comes out of what you have?
• ArenaSim — how does this squad play this match?
• QuantDesk — what does this strategy do in this market?
• StageLightning — what light does this track want?
• Mind Compiler — what does this concept require?

Six separate projects. All six ask the same question: can I say what will happen to something that has not happened yet?

Where the habit comes from

From the nature of my work, I think. I build metering systems. There, the cost of a mistake is not abstract: a building’s bills come out wrong, sixty families pay the wrong amount, and undoing it takes months.

Working in that environment removes the luxury of “I tried it, it did not work”. You learn to run it on paper first.

That habit then spreads everywhere.

The same four rules keep appearing

Writing them up separately made it obvious: I keep rediscovering the same four things.

1. Same input, same output

ArenaSim taught me this in the hardest way. The server plays a match and the browser replays it — they must be bit for bit identical. Otherwise there is no “watch from the archive”, no verification, no fairness.

And what broke it was not my code: it was the language’s own random number generator. The engine now carries its own mathematics.

The same constraint appeared in StageLightning wearing different clothes: a light show must be a pure function of time, because rewinding the track has to rewind the show.

2. The input has to be honest

Fly4cast taught me this early. Take wind as “6 m/s today” and you give the wrong answer — because the pilot does not fly at ground level. At a hundred metres the wind is different.

Simplifying the input does not simplify the simulation — it falsifies it.

3. Cost must be modelled

QuantDesk delivered the most expensive lesson here. One strategy looked excellent gross. Add realistic fees and order-book slippage and it was negative.

A simulation’s easiest lie is forgetting friction. In Mutfaksim the equivalent is waste and cooking loss; in ArenaSim, fatigue; in a light show, the fixture’s response time.

4. Without a control group there is no result

This is the rule I learned last and it changed the most.

QuantDesk made money. I was pleased. Then I ran a second engine: one that bought at random from the same universe. Same period, same costs, the only difference being the selection rule.

The strategy beat random — but by less than I thought. Most of the return came not from the strategy but from the direction of the period.

Without a control group, “it made money” is not a statement. It is a wish.

I then applied the rule backwards. Is a recipe suggestion actually good, or would any recipe have done? Does a light cue fit this track, or does it look good on every track? Uncomfortable questions with instructive answers.

Simulation versus prediction

I do not call these prediction engines, because they are not.

ArenaSim does not predict a score; it plays the match and the score falls out at the end. The difference: when you dislike the score you can walk back through 21 steps and see exactly what happened at which move.

In a system that emits a number, that is impossible. And I stopped trusting unexplainable numbers a long time ago.

Where AI sits in this

There is a reason so many simulations appeared this year: writing the engine got cheap.

Writing a regime classifier or a wind-profile layer used to eat an entire weekend. Now it is an afternoon. That changes the answer to “is this worth trying?” — and when more ideas get tried, more of them stick.

But be careful: AI does not make a simulation correct. It makes it fast. Correctness still comes from the four rules above, and all four are human decisions.