Analysis Is a Feedback System, Not a Verdict
A useful post-game review does more than identify a worse move. It reconstructs the decision, tests the chess, diagnoses the cause, and changes future behavior. The final product should therefore answer four different questions:
- What happened on the board?
- What did I think was happening?
- Where did those two models diverge?
- What should I train, remember or change because of that divergence?
A computer can help enormously with the first question. It cannot recover the second question after the fact unless you preserved evidence of your own thinking.
A Seven-Layer Post-Game Workflow
A robust workflow is:
preserve → reconstruct → human analyze → research → engine audit → exact verification → synthesize.
Preserve the raw score and context before editing anything. Reconstruct candidates, expected replies, evaluations, plans, uncertainty and clock pressure while memory is fresh. Analyze the critical positions without engine revelation. Then use databases for historical or opening evidence, engines for search and evaluation, and tablebases when the position is exactly covered. Finally, translate all of that evidence into a concise explanation and a training consequence.
The order is a learning default, not a ritual. If you are triaging thousands of games, an engine may efficiently flag candidate moments first. The important rule is that tool triage must not replace cause analysis.
Not Every Inaccuracy Deserves Equal Attention
The most useful positions are usually decision-rich or diagnostic: a move where your evaluation changed, a moment where theory ended, a pawn break or exchange that transformed the structure, an only-move defense, a time-management collapse, or a recurring type of misunderstanding. A tiny engine swing in an otherwise obvious technical sequence may teach much less than a move whose evaluation barely changed but exposed a persistent conceptual error.
That means analysis should allocate attention by learning value, not only by centipawn loss.
Separate Evidence Layers
Keep different forms of evidence conceptually separate:
- your memory and notes describe your decision process;
- the game score describes what was played;
- a database describes what has been played in a selected corpus;
- an engine gives search/evaluation output under specific conditions;
- a tablebase gives an exact result or metric within its covered state space.
When these layers disagree, the disagreement is often the lesson. Do not force them into one number.
Choose the Analysis Depth by Purpose
Not every game needs the same treatment. A quick review can identify one or two critical decisions and a training action. A tournament game that exposes a recurring weakness may deserve a full reconstruction. A game used for publication or opening research may require source checking, reproducible engine settings and database documentation.
A useful rule is analysis depth should follow claim strength and learning value. Spend more effort where the position changes your understanding, not where the interface simply offers more data.
Re-Analyze After the Lesson Has Aged
Some lessons only become visible after later training. Revisiting a previously analyzed game a few weeks or months later can reveal whether the explanation was durable or merely engine-dependent. Try to solve the critical position again without notes. If you now recognize the idea quickly, the analysis has entered usable memory; if not, the training output may need redesign.
Reference Framework
Game analysis is the investigation of what happened, why it happened, what the player understood or misunderstood, and what should change next.
A reliable learning workflow is:
Preserve → Reconstruct → Human Analyze → Database Research → Engine Audit → Tablebase Verify → Synthesize → Extract Training
This is a pedagogical default, not a prohibition on engine-first triage or other specialized workflows.
Do not erase the evidence of your own thinking before you study it.
What Game Analysis Is
Game analysis is the structured investigation of a played game or position to determine what happened, why decisions succeeded or failed, and what reusable knowledge follows.
Review vs Analysis vs Annotation
Review is a broad look back at the game. Analysis investigates positions/decisions deeply. Annotation records explanations, variations and evidence in a durable form. They overlap but are not synonyms.
Analysis for Improvement
Analysis for improvement prioritizes the player's own decisions, thought process, recurring causes and trainable lessons—not merely the objectively worst move.
Analysis for Opening Research
Analysis for opening research asks where theory/memory ended, what position was reached through transposition, what strong games exist and whether the repertoire should change.
Analysis for Historical Study
Historical analysis studies a game in its original theoretical/technological context while optionally comparing later engine knowledge. Modern engine truth should not be retroactively presented as the historical player's known information.
Human-First Default
Human-first default means preserving thought and attempting an independent explanation before tool revelation. It protects learning evidence from hindsight.
Human-First Is Not Anti-Engine
Human-first is not anti-engine. Engines are central auditors after the player's hypotheses and reasoning have been preserved.
Engine-First Triage
Engine-first triage can be useful for quickly locating candidate critical positions in huge corpora or time-limited workflows, provided the later human-cause analysis is not skipped.
Preserve → Reconstruct → Human Analyze
Preserve → Reconstruct → Human Analyze protects raw evidence and generates hypotheses before external tools alter the player's memory.
Database Research
Database research asks what games/positions/data already exist and under what filters, not what the engine thinks is best.
Engine Audit
Engine audit tests candidate soundness, refutations, alternatives and evaluation using a recorded engine/search context.
Tablebase Verification
Tablebase verification replaces heuristic engine inference with exact covered-position information where applicable.
Synthesis
Synthesis reconciles human analysis, game evidence, database context, engine audit and exact endgame information into one explanation.
Extract Training
Extract training converts the explanation into an action: tactic set, endgame drill, repertoire note, calculation exercise, strategic model position or clock/process task.
Analysis Workflow Practice
For workflow practice, take one game, preserve and reconstruct your thinking first, then reveal database, engine and tablebase evidence sequentially.