How ChessIQ Generates Training Positions

How ChessIQ generates training positions.

Training positions in ChessIQ are not generic puzzles. They are not scraped content. They come from your games, filtered hard, and stored with the proof of why they matter. This post explains how that pipeline works end to end.

The core loop

The simplest version of the story is this:

You review a real game. The analysis pipeline identifies meaningful turning points. The system reconstructs the exact position before each mistake. The engine verifies the better move. The position is saved locally. Then your future attempts determine when it comes back.

That loop — review, identify, reconstruct, verify, save, schedule — is the entire system.

When generation happens

Training positions are not created during analysis. They are generated after it completes.

Once a full game review finishes, the pipeline looks for candidates. It skips study mode games and games played from custom starting positions. It also skips games where the analyzed player does not match the stored username preference, if one is set.

That means the positions you train are always from your own games, not imported content or generic exercises.

What qualifies as a candidate

Not every mistake becomes a training position. The pipeline is selective.

Candidates fall into three buckets:

• Blunders and severe mistakes. Moves that meaningfully changed the expected result of the game, not just moves with high centipawn loss.
• High-impact inaccuracies. Inaccuracies that pass a stricter validation check based on opportunity gap.
• Missed chances. Positions where a significantly better move was available — tagged by tier as minor, strong, or winning.

Conversion positions are handled separately. If you had a winning advantage and played suboptimally, that gets tagged as a conversion training moment rather than a mistake.

What the generated object contains

Each training position carries more than just a FEN and an answer. The stored object includes the position, the solution moves in both move notation and SAN, the source move number, the classification, the player color, the original played move, the previous move for context, the puzzle type, the game phase, the opportunity tier where applicable, the eval gain, the confidence score, and a proof block.

That proof block is the important part. It exists so that validation — and future debugging — can verify the position is legitimate, not just plausible.

How blunder positions are built

When a blunder candidate is identified, the pipeline does not simply record the position and move on. It reconstructs the exact board state before the mistake occurred. It re-runs engine analysis on that position. It collects the best available moves plus close alternatives. It verifies the best move holds at deeper depth. It compares the played move against the better line. And it records proof fields: the score gap in centipawns, the confidence level, and whether the best move is stable.

The goal is not just to know that a mistake happened. It is to know that the better move is genuinely better and that the puzzle will teach the right lesson.

How opportunity and conversion positions are built

Missed opportunity puzzles use a different signal: the gap between what was played and what was available, measured in expected result rather than raw centipawns. Positions are tiered — minor, strong, or winning — based on how significant the missed chance was.

Conversion puzzles are tagged separately with their own phase marker. If the mistake was about converting an advantage rather than avoiding a blunder, the training experience reflects that framing.

Why generation is capped and deduplicated

A game can produce many candidates. The pipeline does not save all of them.

Candidates are sorted by quality and capped at five high-value positions per game. If the strict filters produce too few results, the pipeline makes a fallback pass with slightly relaxed criteria. Positions that are too similar to each other are deduplicated.

Five positions per game is not a limitation. It is a design decision. A training queue full of near-duplicate positions from the same game is not useful. Quality over volume.

Validation before saving

Before any position is saved, it passes a validation check. A candidate is rejected if:

• The source position cannot be reconstructed
• The solution moves are illegal
• The puzzle FEN does not match the source FEN
• The solution accidentally includes the played blunder
• The position has fewer than two legal moves
• The blunder or opportunity validation check fails

That last point matters in practice. Early versions of the system could construct puzzles where the "correct" move set included the very mistake the puzzle was supposed to teach. Validation now explicitly blocks that.

Storage

Positions are saved to local storage. Nothing is sent to a server. Each position gets a deterministic stable ID and a source fingerprint derived from the game and move number. That means if analysis is run again on the same game, regenerated positions do not overwrite your attempt history — the existing records are recognized and preserved. Storage is capped at 500 positions. Older lower-priority positions are evicted first when the cap is reached.

Training queue and scheduling

Generation is a one-time event. Scheduling is ongoing. The training queue scores each available position using several signals: active weakness patterns, recent failure rate, challenge level relative to current performance, spaced repetition due dates, lifecycle state, and immediate-repeat penalties so the same position does not appear twice in quick succession.

Positions surface in two lanes: missed opportunities and blunders. Each lane has its own queue, and the lanes stay separated so training reflects the type of error being worked on.

How solving feeds future scheduling

Every attempt updates the position's training record. Clean solves push the due date forward. Failed attempts, hints used, repeated misses, and escalating severity all affect how soon the position returns. Positions that are failed repeatedly can escalate into active weakness training — a higher-priority state where they reappear more frequently until the pattern is resolved.

The system is tracking whether you have actually learned from a position, not just whether you have seen it.

Handoff from analysis

After a game review, the analysis recap can drop you directly into the relevant training lane. The handoff preserves the puzzle queue, the source game ID, the reason for the handoff, and a return path back to the analysis view. You finish reviewing, see what went wrong, and train it immediately.

What makes this different from generic puzzles

The mechanism matters because generic puzzles are not the same as positions you actually reached.

A puzzle from a database tests a pattern. A position from your own game tests whether you can find the move you missed in a position you played — a context your memory of the game can make either harder or easier depending on what you remember. Training positions also carry the full context of the mistake: what the game state was, what the alternative was, why the alternative was better, and how confident the engine was in that judgment. That is not available in a generic puzzle database.

The short version: training positions work because they are generated from proof, not from vibes. ChessIQ waits for a real reviewed game, reconstructs the exact moment before the mistake, checks the better move against the engine, stores the position with its source context, and lets your future attempts decide when it comes back.