Building + Testing ApproximationBot: Reliability 1st Lichess Chess Bot Project.

1. Why Did I Create ApproximationBot?

I wanted to see whether I could turn the way I think about chess, decision-making, and problem solving into a working chess bot. Lichess gave me a practical environment where I could build it, test it, find mistakes, and eventually let other people play against it.
ChatGPT has been my development and reasoning assistant throughout the project. Instead of simply trying to make the strongest chess engine possible, I became interested in building something reliable: a bot that knows the exact board state, makes only legal moves, manages its time, responds correctly to Lichess events, and can gradually improve from what happens in completed games.
ApproximationBot grew from that experiment. What began as an idea has gradually become a real Lichess bot that can now play controlled public-beta games.

2. Reliability Before Chess Strength

One of the biggest lessons from developing ApproximationBot was that chess strength means very little if the underlying system cannot be trusted to represent the board correctly and make legal moves.
During early testing, I encountered failures involving board geometry, occupied squares, pins, king safety, and other legality conditions. Those failures changed the direction of the project. Instead of treating them as minor bugs while continuing to optimize playing strength, I began treating legality and exact game-state tracking as hard requirements.
The development priority became: first know the exact position, then determine what moves are actually legal, then evaluate those legal moves, and only after that worry about making the bot stronger.
This led to additional safeguards around FEN state, move generation, attack detection, king safety, candidate verification, and a final legality check before a move can be released. A clever move is useless if it is illegal.
That reliability-first principle has remained one of the central ideas behind ApproximationBot.

3. How ApproximationBot's Architecture Developed

ApproximationBot did not begin with its current architecture. It developed in stages as testing exposed problems that needed stronger safeguards.
At the center of the design is a deterministic live chess path. The bot receives the current game state from Lichess, reconstructs the exact position, determines the legal moves, evaluates the available candidates, selects a move, and performs a fresh legality check before anything is transmitted back to Lichess.
The system also separates responsibilities. Exact board state, chess legality, king safety, clocks, and move execution belong to the live deterministic system. Higher-level reasoning and experimentation can help with evaluation, testing, and analysis, but they do not get to override those hard requirements.
Outside an active game, completed games can be reviewed for mistakes, recurring weaknesses, time-management problems, and possible improvements. This keeps learning and experimentation separate from the live move-control path.
As the project progressed, I also added the surrounding Lichess service: challenge handling, controlled game authority, reconciliation after games, and eventually a persistent service capable of waiting for appropriate playing opportunities. The result is not just a chess evaluator, but a larger system designed to play reliably on Lichess.

4. Qualification and Controlled Testing

I did not give ApproximationBot unrestricted authority to play games immediately. The live Lichess integration was introduced gradually, with each stage increasing what the bot was allowed to do only after the previous stage worked correctly.
The earliest tests were read-only and shadow tests. ApproximationBot could observe the current Lichess game state and determine what it would do, but it was not permitted to send a move. This allowed me to verify authentication, board-state reconstruction, legality, and the connection between the chess system and Lichess without risking an incorrect live action.
After that came tightly limited live tests. First the bot was authorized to transmit a single verified move. Later it was allowed several moves, with the game state checked again before each one. Only after those tests succeeded did I allow it to play a complete controlled game.
The next stage was a full 5+0 game against my own Lichess account. ApproximationBot played autonomously until the game reached a terminal state, after which its authority automatically stopped. This helped verify not only move selection, but also clocks, game-state updates, move transmission, termination handling, and post-game reconciliation.
From there, testing expanded cautiously toward games against other Lichess players. I kept the same basic principle throughout: increase authority only after the narrower version has been tested and verified.
This qualification process has sometimes made development slower, but it has also made failures easier to isolate and repair. Instead of asking only, "Can the bot play chess?" I have tried to answer the harder question: "Can I trust the complete system to play a game correctly from beginning to end?"

5. Moving Into Public Beta

After the controlled qualification games worked, ApproximationBot moved into a limited public beta on Lichess.
The goal of the beta is not simply to accumulate games. It is to expose the complete system to real-world conditions: different opponents, incoming challenges, varying game situations, network interruptions, game completion, and the process of returning safely to an idle state afterward.
At the time of writing, the beta remains deliberately limited. ApproximationBot plays one game at a time and operates within a capped testing window rather than accepting unlimited games. These limits give me time to inspect what happened, reconcile completed games, and repair problems before increasing its authority.
A persistent service now listens for appropriate Lichess opportunities and manages the transition between waiting, accepting a compatible challenge, launching the chess controller, completing the game, reconciling the result, and returning to an idle state.
This part of the project has introduced a different kind of reliability problem. A chess bot can make perfectly legal moves and still fail as a service if it mishandles a challenge, loses synchronization with Lichess, fails to recover from a network interruption, or does not return correctly to its waiting state after a game.
For that reason, the public beta is testing both the chess player and the surrounding system. ApproximationBot is becoming less like a program that can play one chess game and more like a service that can wait, play, recover, and be ready for the next opportunity.

6. What Have We Learned So Far?

The biggest lesson has been that failures are often more useful than successes when they expose a weakness in the system.
Some early chess tests failed because of illegal moves involving board geometry, occupied squares, pins, or king safety. Those failures were serious, but they showed exactly where the architecture needed stronger verification. Each one became a reason to improve the legality path rather than simply move on to another game.
I also learned that stronger chess is not just a matter of searching longer. Time is limited, especially in games such as 5+0. The bot has to decide where deeper calculation is valuable and where it is better to make a reliable decision quickly and preserve time for later positions.
Another lesson is that chess reliability and service reliability are different problems. A bot may choose good legal moves but still fail if it mishandles a challenge, loses synchronization with Lichess, or does not recover properly after a game. Both layers have to work.
The project has also reinforced the value of separating live play from learning. During a game, the authoritative system must know the exact position, legal moves, clock state, and permitted action. After a game, there is much more freedom to review mistakes, test alternatives, search for recurring weaknesses, and consider improvements for future versions.
Most importantly, I have learned not to increase the bot's authority simply because something appears to work once. A successful test is evidence, not proof. I would rather expand the system gradually, find the weak points, repair them, and then test again.

7. What Comes Next - The Future!

ApproximationBot is still a beta project, so the next step is not simply to remove the limits and let it play indefinitely. I want to keep expanding what it can do only as the underlying system proves that it can handle the additional responsibility reliably.
One goal is broader accessibility. I would eventually like ApproximationBot to support several common Lichess time controls rather than being centered mainly on 5+0 testing. I am also interested in having it participate in appropriate bot competitions and tournaments once that part of the system has been tested and qualified.
Another direction is continued learning from completed games. When ApproximationBot is not actively playing, completed games can be reviewed for tactical mistakes, strategic weaknesses, time-management problems, recurring patterns, and possible improvements. Those lessons can then be tested offline before any change is promoted into a future version.
I also want the surrounding service to become increasingly reliable when operating unattended: waiting for challenges, choosing appropriate opportunities, playing one game at a time, reconciling completed games, recovering from interruptions, and returning safely to its waiting state.
The long-term goal is not just to build a stronger chess engine. It is to build a dependable Lichess chess bot whose chess ability, reliability, and surrounding automation can continue improving together.
There is still a lot to test, and I expect there will be more mistakes to find. That is part of the project. Each verified failure gives me another opportunity to make the next version better.

8. Lichess Players Can Participate :)

ApproximationBot is now on Lichess, and real games against different players are an important part of the beta-testing process.
You can find the bot here:
https://lichess.org/@/ApproximationBot
Because the project is still in a controlled public beta, ApproximationBot may not always be available to accept a challenge immediately. It currently plays one game at a time, and testing limits remain in place while I continue checking reliability and completed-game results.
If you do play against ApproximationBot, I am interested in more than whether it wins or loses. Unusual positions, strange behavior, timing problems, challenge-handling problems, and anything else that looks unexpected can all provide useful information for improving the project.
Thanks to everyone who has followed the project, offered suggestions, challenged the bot, or simply taken an interest in seeing where this experiment goes next. :)