Burbubot review: an automated betting system not ready for real money

Validating an automated betting system requires separating prematch research from live execution, freezing parameters before confirmation, and not accepting a statistical test that ignores dependence between leagues. Without enough prospective data and without an execution contract that prevents rounding and duplicates, the system is not ready to operate with real money.

There is a very human temptation with these automated systems: building the perfect machine before checking that the machine measures what it thinks it measures. The case at hand has working code, a roadmap and an independent audit that has found concrete problems. And above all, it has an uncomfortable question: is the system validated, or just well built?

The short answer is that it is well built in some parts and poorly validated in almost all of them. The long answer is this article.

## The problem of mixing prematch research with live execution

The system has two lines that are not connected. On one hand, a historical live betting engine with statistics, classifiers and HOME/AWAY/DRAW/OU15/OU25 markets, which contains the CSV emitter for Betting Toolkit. On the other, a prematch research platform for 1X2 at T-30, with a Dixon-Coles model, prospective capture and statistical evaluation.

The audit warns of something elementary: proving that a prematch 1X2 model beats the market does not validate the live engine or its goal markets. They are two different things. And the active research tasks do not by themselves complete the historical engine's publishing and execution chain.

The sensible decision is to finish a small, verifiable prematch 1X2 version first, keeping in-play as a separate line. What conditions would allow reusing components without improperly transferring validation? The answer lies in the separation of responsibilities: the capture code, the CSV serializer and the file system can be shared if their tests are independent of the model. What cannot be shared is the statistical validation. A model that works prematch says nothing about another that operates live with different markets.

## Dixon-Coles, odds and the C(M) control

The current predictive design combines two sources. On one hand, 1X2 probabilities from a Dixon-Coles model trained on results available before the temporal cutoff. On the other, probabilities derived from Bet365 odds arriving via API-Football, removing the margin through proportional normalization. It then recalibrates the market with a temperature T and combines both with a weight α in a log-linear formula.

The hypothesis is that combining the model with the market improves on the recalibrated market. It is measured with multiclass log-loss, and α and T are estimated in development, then frozen for confirmation.

Is this C(M) control adequate? It has an underlying problem. Presenting F and C(M) as models with "one free parameter each" is misleading when A incorporates prior training and selection. The Dixon-Coles model is not a parameter: it is a procedure with specification decisions, training windows and variable selection. Comparing F with C(M) without acknowledging that asymmetry is like comparing a stock car with one that has been through the workshop and saying both have "an engine".

The comparison with Elo and league frequencies helps, but it does not solve the problem. Reporting Brier, RPS, calibration and coverage is fine. What is missing is a negative control that reveals whether the improvement comes from the model or from the selection process.

## Feed freshness and the mirage of the closing odds

Here is a problem anyone who has worked with real-time data recognizes immediately. A real test found that the receipt of an odds response occurred at 13:01:31 UTC, but the upstream update was from 12:00:21 UTC. In other words, receiving a response now does not miccionan receiving a current odd.

The provider's documentation describes prematch updates roughly every three hours, with variations. That means a capture at T-30 and another at T-5 can be two readings of the same upstream update. In that case, a closing differential close to zero does not measure market efficiency: it measures feed immobility.

The roadmap adds captures at T-5 and T-1 for evaluation only and computes D_close as the difference in log-loss between the T-30 odd and the closing one. The problem is that this diagnostic may be measuring nothing.

What can really be concluded with this provider? Little, as long as freshness is not measured systematically. Should D_close be removed from decision rules when there is no sufficiently fresh closing odd? Yes. A diagnostic that does not distinguish between an efficient market and a frozen feed is not a diagnostic: it is noise dressed up as data.

The freshness policy cannot be chosen based on favourable results. It must be set beforehand: for example, requiring that the difference between the reception timestamp and the upstream update timestamp be below a predefined threshold, and treating captures that fail this as invalid for closing analysis. A pilot should measure the distribution of that difference, the real update frequency and the correlation between successive captures.

## The statistical test: the main blocker

The roadmap proposes a one-sided test with level α=0.025 on the unweighted miccionan effect across leagues. The statistic is an Ibragimov-Müller t over league means. The audit questions assuming independence between leagues and describing the method as immune to any temporal dependence.

The numbers that deserve close attention are those of the existing calibration. The base empirical scenario gives a type I error of **0.0394** when the nominal is **0.025**. The heterogeneity scenario rises to **0.0536**. The 12-league scenario stays at **0.0378**. And the power for an MDE of **0.002** does not exceed **0.2946** in the best case.

PASS was declared because all errors were ≤0.060. That does not accredit control at the one-sided nominal of 0.025. Nor is there power anywhere near 80%. A system that fails to detect an effect of 0.002 even with 30% probability is not validated: it is waiting for chance to prove it right.

The audit's independent simulation used 26 Gaussian means under an exact null with common correlation ρ and 20,000 replicas. The results are telling: with ρ=0.05 the rejection rate rises to **0.0936**; with ρ=0.10 to **0.1555**; with ρ=0.20 to **0.23185**; with ρ=0.50 to **0.3468**. This does not estimate the project's real correlation. It is a counterexample to the general guarantee and shows why common shocks must be studied.

What inferential procedure would be defensible with dependence by league, team and calendar? There are several options, but none is free. A block bootstrap that preserves the temporal and cross-sectional structure requires estimating the dependence, and three weeks of data do not allow estimating it reliably. A Bayesian hierarchical model would allow incorporating the dependence, but requires specifying a structure that is also unknown.

The criterion for accepting calibration should include Monte Carlo uncertainty. With 5,000 replicas, the standard error of a rejection rate of 0.025 is approximately 0.0022. That means a 95% confidence interval for the observed rate runs from 0.0207 to 0.0293. If the system declares PASS with 5,000 replicas when the roadmap requires 20,000, it is accepting a precision it does not have.

## Operational defects that keep reproducing

The audit found defects that remain reproducible after 52 selected unit tests and 804 documentary checks. That is not a testing problem: it is a design problem.

The first is ambiguous retries. In the status/fixtures client, a ticket is reserved before sending. If there is a timeout reading the response, it retries and, once exhausted, deletes the reservation. With simulated transport, two cycles of the same ticket produced six sends and zero durable records remaining. These are data GETs, not bets, but traceability and consumption accounting are lost.

The second is the false HEALTHY. The capturer can report state=RUNNING and network_status=OFFLINE_AWAITING_RECONNECT; the supervisor ignores the second and returns HEALTHY. That is a system claiming to be fine when it is not.

The third is the false clock success. The panel can emit ok=true and "synchronization completed" even though both NTP commands fail and no sample exists.

The fourth is windows and latencies. There are tasks every minute, requests that can block for 45 seconds and sequential shutdowns with a 120-second timeout. The priority of T-30 within a cycle does not guarantee attending to the next one if the previous one is still blocked.

A minimal state machine for reservation, sending, response, uncertainty and recovery would have to distinguish between "not sent", "sent without confirmation", "confirmed" and "failed". GET retries cannot erase evidence: each attempt must be recorded with its timestamp and its result. And load tests would have to simulate blockages, timeouts and recoveries to verify that the system does not lose traceability.

## The CSV contract and execution

The existing CSV contains Provider, SelectionId, MarketId, SelectionName, MarketName, MarketType, BetType, EventName, EventId, Handicap, Price, MinPrice, MaxPrice and Points. It is published via temporary file and atomic replacement. It contains neither signal_id nor expiration.

Synthetic tests of the serializer detected that it accepts NaN and rounds: MinPrice 2.005 becomes 2; MaxPrice 2.999 becomes 3. No real signals were found with those values, but the defect is that the last publishing barrier does not prevent widening a limit through rounding. A price limit that is widened by rounding is a limit that does not exist.

The full contract would have to cover unambiguous identification of match, market and runner; price limits derived from API-Football that the executor respects; effective expiration; deduplication after restarts; the gap between publishing and receiving acceptance; rejection, partial execution, cancellation and reconciliation; and executed price and actual commission.

The economic test must be done on real or faithfully simulated executions, not assuming bets are placed at the API price. A Bet365 odd received via API-Football can serve as a reference, but it is not the price at which Betting Toolkit will execute on Betfair. That distinction is the difference between a backtest and a fantasy.

## What is missing and what needs to be measured

The system has 29,719 historical FT results, a historical proxy of 709 matches with 504 evaluable in three weeks, 26 league IDs and a new campaign with 124 matches and 125 recorded occurrences. One valid prospective odds observation and zero complete common pairs for evaluation.

With those numbers, the minimum missing evidence is clear: enough prospective pairs to estimate dependence between leagues, a null generator that preserves the temporal and cross-sectional structure without assuming structures that three weeks do not allow estimating, and a stopping criterion that distinguishes between "no evidence" and "evidence against".

The confirmed API-Football plan expires on 17/11/2026. The system runs on Windows, with four scheduled tasks and a runtime separate from the documentary folder on Drive. It depends on the PC and the session. That is not a production architecture: it is a prototype with an expiry date.

The conclusion, if frankness is permitted, is that the system is not ready for real money. Not because the code is bad, but because the validation does not support the decisions that want to be made with it. A wide interval compatible with improvement is not favourable evidence. An old closing odd with no changes is not the absence of opportunity. And a PASS with 5,000 replicas when 20,000 are required is not a PASS: it is impatience.

Before risking a single euro, it must be proven that the system measures what it says it measures. And that, with the current data, is still pending.