Difficulty that reads the player, not the spreadsheet.

A model estimates how a player is coping from what they do inside the round — how many attempts a level took, where each attempt ended, how the input pace changed as the round wore on — and moves the next round toward the edge of their ability rather than away from it. Someone drowning gets a kinder board. Someone bored gets a harder one. Neither gets a curve tuned to an average player nobody has ever met.

The subsystem is handed gameplay events and nothing further. No read path to purchase history, wallet balance, offer state or the store catalogue; no write path to anything that can put an offer in front of you. It cannot know whether you have ever spent money, so it cannot respond to whether you have. That is a wall in the code, not a sentence on a marketing page.

Levels that are solvable, that are not trivially solvable, and that do not read as the same level with the furniture moved. A generator paired with a solver: nothing reaches a player until the solver has completed the board and the difficulty estimate lands inside the intended band.

The unsolvable levels are the easy failures, and the solver catches those. The interesting ones are the boards a solver clears in seconds and a person finds miserable — a different measurement entirely, and the one that decides whether a generated level reads as authored or as assembled.

Every game has one: the level where the graph bends and people stop coming back. It is almost always a difficulty step somebody tuned by eye against that same average player, or a board the tooling called fair and a human called unfair.

Those are exactly the two failures the systems above exist to catch, and one real example is worth more to us than any quantity of synthetic play. If you know where yours sits, write it down and send it to [email protected]. The reply comes from the people who write the code, inside five business days.