This FAQ is for the kind of reader who would not be satisfied with a quick demo and a few marketing sentences. It is based on the current final version of the project, the finished appendix, and the way the app actually behaved when we tested it through the notebook interface.
The project is trying to build a chess tutor, not just a strong chess bot. That idea sits behind almost every design choice in the final version. A normal engine is built to find the strongest move. Our tutor is built to say something useful to a student at a chosen rating level. So the goal is not only correctness. The goal is understandable, level-aware feedback that helps someone improve from the position they are actually facing.
No. The tutor itself is built around Maia-2, not Stockfish. That distinction matters because Maia-2 is designed to model how humans play at different rating levels, while Stockfish is designed to play the strongest chess possible. We used engine comparisons in the report to show the difference in style, but the live system the user interacts with is Maia-based.
Because the project is about improvement, not just objective move quality. If the project only wanted the strongest move, then a standard engine would already solve that problem. But a tutor has to do more than solve the board. It has to respond in a way a student can learn from. Maia lets the project ask a different question: not only “what is strong here?” but also “what would a human at this level plausibly play here?” That makes the feedback feel more like coaching and less like judgment from a machine that is too strong to imitate.
Yes. It changes much more than a label. In the current version, the Elo setting affects at least four things at once:
We checked this directly. The same board position could receive a different set of candidate moves, a different tone of advice, and a different practice pool depending on whether the slider was closer to 1200 or 1900.
It means: how likely is a player at the chosen rating to make that move?
This is one of the most important ideas in the whole project.
Human-Likelihood is not the same as “best move,” and it is
not the same as “winning move.” In testing, we saw all three cases:
So the move panel is really giving three kinds of information at once:
That separation is part of what makes the tutor more interesting than a single engine score.
No. It only means Maia does not think players at that rating choose it very often. The move can still be playable, and sometimes it can even improve the position. We saw that in testing. The tutor is careful about this distinction, which is one of the strengths of the project. It does not flatten everything into one judgment word.
A practical way to read the panel is this:
Human-Likelihood tells you whether the move fits the
usual habits of players at that level.Win Probability tells you whether the resulting
position looks better or worse inside the tutor’s evaluation
pipeline.If those signals all point the same way, the move is usually easy to trust. If they split, the explanation becomes the most important part. The numbers help, but the real educational value is in the interpretation.
They are related, but they are not doing the same job.
Making a move gives move-level coaching. The tutor reacts to the exact move that was played. It tells the user how typical that move was, whether the position improved or worsened, what tactical theme was detected, and what next priority to keep in mind.
Evaluate Position gives position-level coaching. It
treats the current board as a study position and answers a different
question: who is to move, what side you are playing, what candidate
moves make sense here, and what kind of middlegame or opening plan this
position is about.
This difference showed up clearly in our testing. We used
Evaluate Position from:
In all four cases, it behaved like a planning tool rather than a move grader.
It can definitely be used from move one. Starting from a new game, the tutor gave sensible opening-stage guidance such as developing pieces, supporting the center, and keeping king safety in mind. Once a move was played, the panel switched naturally into move-by-move coaching.
So the sample middlegames are important, but they are not the only way the app works. The project supports both:
FEN is a compact text way to describe a chess position. It matters here because the whole tutor is built around the idea that a player should be able to stop at a specific board state and ask, “What should I be thinking about here?” The FEN box is what makes that possible. A user can paste in a position from their own game, from a class example, or from the app’s own sample pool and study it immediately.
That feature is not a side detail. It is one of the main reasons the tutor feels useful beyond just playing a full game from move one.
The app handles that case cleanly. When we tested an invalid string, the app did not crash and did not dump a notebook traceback into the interface. It returned a short readable message saying that the FEN could not be parsed. That is the right behavior for a student-facing tool.
Because once a sample middlegame is loaded, its FEN is sitting in the
input box. If the user then clicks Load FEN without
changing anything, they are just reloading the exact same position. That
is expected. The two buttons are not duplicates, though:
Load Sample Midgame chooses a built-in position from
the current practice poolLoad FEN loads whatever exact position the user
currently has in the text fieldSo they can coincide, but they are still serving different purposes.
No, not in the broad sense. The app does not generate arbitrary legal chess positions. Instead, it gives the user curated sample middlegames. That is a good decision for this project. Truly random positions would often be strange, unrealistic, or pedagogically useless. The current design is narrower, but much more defensible as a tutoring tool.
It can handle Black properly. In the final version, the user can start a new game as Black, and the tutor will open as White. The coach panel then switches its wording so the user is clearly told they are playing Black from that position. We checked this directly, and the recommendations still made sense from Black’s side.
That helps the app feel complete. It is not only a White-side opening sandbox.
The arrows are visual tactical hints. The app explains the legend right in the coach panel: blue attack, green check, orange hanging piece, red king danger. They are not decorative. They are tied to the tutor’s tactical detectors, so when the panel says a move uncovered an attack or left something hanging, the board can also show where that idea lives geometrically.
We saw this directly in the final interface. When a move created a tactical theme, the arrow overlay appeared and matched the panel text. That makes the app much easier to read than a pure text-only tutor.
No. The tutor is not simply biased toward passive chess. In our testing, active moves sometimes increased the win-probability estimate and received positive coaching. But the app also punished random-looking aggression when it lacked a clear purpose. That feels believable. The tutor is not saying “never attack.” It is saying that active ideas should still make sense in the position.
That is the kind of distinction a real human coach would try to make.
The best rule is: try the move whose purpose you can explain most clearly.
If one candidate obviously develops a piece, improves king safety, or supports the center, that is usually the best first move to test. If another move is sharper and harder to understand, it often makes sense to compare it second.
This is also where the current app becomes genuinely useful. Because
it has Regret, the user does not have to guess once and
live with it. They can:
That made a real difference in our testing.
Not every single time. The safest way to say it is this: following the message usually helps at the level of plan, but not every suggested move is guaranteed to raise the exact numeric estimate on the next line.
That sounds subtle, but it actually fits the project well. The tutor is usually most convincing when it tells the user what kind of move belongs in the position. Then the move-by-move panel shows whether a particular follow-up really held together. In our testing, some recommended moves worked beautifully, while others felt more like sensible candidates than absolute commands.
That does not make the system incoherent. It makes it feel more like coaching than oracle behavior.
It rewinds the last full turn so the user can compare another move from the same position. In practice, that means the app restores the board and the coach panel to the earlier branch, then tells the user to choose a different move from that position.
We used this a lot in testing, and it became one of the most useful features in the final version. It turns the app from a one-path demonstration into a comparison tool. That matters because chess improvement often comes from comparing two plausible ideas, not just seeing one answer once.
The final system supports several learning workflows inside one interface:
RegretThat combination is what makes the project feel finished. It does not only show that a model can score moves. It gives the user a way to study, test, compare, and replay ideas.
A good workflow is:
Evaluate Position first to get the overall
planRegret and compare
another candidateThat way, the app becomes more than a move scorer. It becomes a structured way to ask, “What kind of move belongs here, and how does that compare to what I was about to do?”
The strongest reason is that it changes the question from “What is the best move?” to “What kind of feedback would actually help this player improve?” Once you take that question seriously, the rest of the system starts to make sense: the Elo slider, the Maia model, the candidate moves, the tactical arrows, the practice pools, the Black-side support, and the regret feature are all serving the same teaching idea.
That is why the project feels more ambitious than a normal notebook demo. It is not only about chess strength. It is about building a tutoring experience.
Not necessarily. The board UI assets are cached locally after the first successful launch. That means later launches can reuse the local copy instead of downloading the board resources again. The first launch still needs network access if the cache has not been created yet, but after that the notebook is more self-contained.