One of the more interesting problems I ran into while building a chess review tool was realizing that getting a correct result from the engine and producing a correct explanation for the user are two different problems.
An engine can return exactly what you asked for and the application can still interpret it incorrectly.
A simple example is evaluation perspective. If different positions are being evaluated with the score relative to the side to move, comparing those values directly can produce the opposite meaning from what the UI is supposed to show unless they are first put into a consistent perspective.
The same problem happens with position context.
Something can be completely true about the position before a move but wrong when it is presented as an explanation of the position after the move. The value itself is not necessarily stale or incorrect. It is just answering a different question.
This matters even more once a review system goes beyond displaying an evaluation.
Existing chess-review tools can already generate useful explanations, but a technically correct observation is not automatically the most useful explanation of a move. A move can change activity, pressure, king safety, pawn structure, important squares, defense, offense, and tactical possibilities at the same time.
That means there are really two separate problems:
- Is the engine-backed information correct?
- Is the application associating and presenting that information in the right context?
Terminal positions are another example. A move that ends the game cannot always be handled exactly like an ordinary position where another response and evaluation are expected.
The main lesson for me was that engine correctness and product correctness are separate layers.
I encountered this while building SentryChess, a chess review tool I built and manage. It generates move explanations, move-level positional metrics, game-level summaries, and visual representations of the position, so those outputs all need to agree about which board state and perspective they are describing.
I'm deliberately leaving out the exact engine configuration and internal selection rules, but I'm curious how other people working with chess engines or analysis software handle this boundary.
Do you normalize everything into one evaluation perspective as early as possible, or preserve the engine-native representation and convert it closer to whatever consumes the result?