On this page
Overview
The idea is simple: a betting market is made of many sportsbooks, and they don’t all update at the same speed.
When the fast, professional books move and the rest of the market hasn’t caught up yet, there’s a brief, measurable gap between the current price and the “true” price. THE BRAIN watches for that gap across about 30 books, decides whether it’s real, and places a bet with no human in the loop. Then it grades the result and retrains overnight. It’s a closed loop: collect data, decide, record, learn, repeat.
What makes it a real engineering project rather than a script is everything built around that loop to keep it honest: a full automated test suite, a permanent record that can’t be quietly edited, and a validation step that has to approve any change before it’s allowed to risk money.
I designed the system and made every real decision about how it works. AI coding tools helped me implement it faster. The architecture, the testing, and the judgment calls are mine.
How it works
Data flows in one direction, from raw prices to a placed bet. Every step only uses information that existed at decision time, and if data is missing or stale, the system stops instead of guessing.
When it bets
The system stays out of the market by default. It only bets when the fast books are leading, the wider market agrees on a price, and at least four of these six checks line up:
- 1 sharp books leading
- 2 the game model agrees
- 3 the close-price forecast agrees
- 4 the line moved toward the side
- 5 no late money against it
- 6 it agrees across both markets
I didn’t hand-pick that rule. I found it by testing thousands of candidate rules (3,315 of them), confirmed it held up on data it had never seen, and checked it against a “shuffled-data” test, re-running the same search on 120 versions of the data with the outcomes randomized, to show what pure luck could produce with that much searching.
Engineering highlights
Most of the work is infrastructure. These are the parts that took real engineering:
- Real-time data pipeline. Collects and stores millions of price updates from about 30 sources, keeping only actual changes so the full history stays compact and can be replayed exactly.
- Statistical validation. Every proposed change is tested on data it wasn’t built on, and against a luck baseline, before it’s allowed to affect real money. This has repeatedly killed my own ideas that only looked good in hindsight.
- Automated testing. 335 checks run before any deploy. They confirm the system behaves correctly and that removed features stay removed, so nothing quietly creeps back.
- Safe execution. Bets are placed with exact fee accounting and reconciled against the account every night. Any unexplained gap halts trading automatically until I review it.
- Fail-safe by default. Missing, stale, or inconsistent data blocks a decision rather than triggering a guess.
- Lines of Python
- 50,600
- Lines of React in the control room
- 9,500
- Automated tests, green before every deploy
- 335
- Versions shipped
- 115
- Market price updates stored
- 7.8M
- Replayable market database
- 1.7 GB
- Games tracked
- 6,465
Integrity by design
Several of the hardest design decisions are security principles applied to a data system. They’re the same instincts I bring to security work:
Tamper-evident record
Every decision is written to a permanent, hash-verified event log. Nothing can be retroactively edited, and if the underlying source files change unexpectedly, the system refuses to act until it re-verifies.
Security parallel
Audit logging and integrity monitoring: you can’t trust a record that can be quietly rewritten.
Fail closed
Stale quotes, missing lines, or inconsistent data block a decision. The system would rather do nothing than act on a number it can’t stand behind.
Security parallel
Secure defaults: when inputs can’t be validated, deny rather than allow.
Automatic halt on anomalies
A nightly reconciliation checks every cent against the account. Any gap it can’t explain stops all execution until I review it.
Security parallel
Detection with containment: an unexplained discrepancy is treated as an incident, not a rounding error.
Gated changes
No change reaches the live decision path without passing the full test suite and an out-of-sample validation. New research signals are recorded but can’t alter the rule that’s currently live.
Security parallel
Change control and separation between production and experimentation.
The control room
The React control room is the cockpit. It shows every game the system is watching, a live market feed, a performance page, and the safety switches that decide whether it can place real bets. There’s also a chat panel where I can ask, in plain English, why it did or didn’t bet a game and get the real reasoning back, which turned out to be the fastest way to audit a decision.
Built with AI tools
This project is where my interest in AI reliability became a real tool instead of a study. I worked as the architect: I decided what to build, defined how it should behave, and wrote the tests. Claude Code did most of the implementation inside the codebase and ran the test suite. ChatGPT was a thinking partner for the design and the math.
What stayed with me is the judgment: the overall design, every decision about risking money, and the discipline to throw out my own ideas when the data proved them wrong.
An AI can write a betting script in an afternoon. What it won’t do on its own is tell you your results are overstated, build the test to prove it, and then delete the flattering number. Directing that loop (decide, build, test, stay honest) is the real work. The AI made it possible to build at this scale as one person; it didn’t decide what was worth building or whether it was true.
How it evolved
I built THE BRAIN across 115 versions. Each one was an experiment that either survived contact with reality or got cut. The through-line is a steady move from “trust my model” to “trust the measured market, and prove everything.”
The foundation
Model vs. market, with strict guardrails
A basic model-vs-market bet with a permanent decision log and strict “stop if the data is bad” rules.
Market-as-truth
The market becomes the anchor
The market replaced my model as the source of truth, after I proved the model lost money on its own.
The validation harness
Every rule has to earn its way in
A proper testing and validation layer that any new rule has to pass before it can risk money.
The current system, live
One validated rule, a deeper market engine
One clear, validated betting rule, plus a deeper market-reading engine that feeds the next one.
Honest about results
The engineering I’m confident in. The profits I’m careful about, on purpose.
The record looks strong, but most of it comes from replaying the strategy on past data, which is not a promise about the future. The real-money sample is small, the stake is tiny by design, and one sport (baseball) does most of the work right now. The control room shows these limits plainly, with real and backtested bets always labeled separately, because a system that flatters its own record is worse than useless.
The point of the project was never the betting. It’s the engineering around it: a real-time data system, careful statistical testing, honest record-keeping, and a workflow that gets the most out of AI coding tools.
Stack & skills
Where it started: Iterative Prompt Engineering, the multi-year project that taught me how to keep AI output grounded.