trump-code searches 31.5 million combinations and reports the result on 564 trades

31.5 million combinations searched, and the filter is not described

The headline claims are five: 7,400 or more Truth Social posts analysed from three independent sources and cross-verified, 31.5 million model combinations tested by brute-force search, 551 surviving rules that passed train and test validation, a 61.3 percent hit rate across 566 verified predictions, and a closed loop of predict, verify, learn, evolve and repeat daily.

Only the middle two numbers describe the same pipeline, and the second one is where the method stops being visible. A brute-force search over 31.5 million model combinations produces 551 survivors. What keeps those 551 and discards the other 31,499,449 is stated only as passing train and test validation. There is no threshold, no stated significance level, no description of how the data was split, and no indication of whether the same data that generated the rules was used to test them.

At the scale of the search, the filter is not a detail. If even one in a thousand of the combinations cleared a nominal bar, you would expect tens of thousands of survivors rather than 551, so whatever produced 551 is doing real work. It is just not written down, and the number cannot be interpreted without it.

The post count is also stated twice at two scales. The analysis claims 7,400 or more posts, while the open data table describes `trump_posts_all.json` as a full Truth Social archive of 44,000 or more posts updated daily. The page does not say how the smaller number relates to the larger one.

The top of the leaderboard rests on 8, 11 and 17 trades

The leaderboard has eleven models with codes A1, A2, A3, B1, B2, B3, C1, C2, C3, D2 and D3, and a trades column that makes the ranking legible in a way the hit rates alone do not.

A3, the top model, has a 72.7 percent hit rate over 11 trades. C3, at the bottom, has 37.5 percent over 8. B1 has 64.7 percent over 17, B2 has 57.9 percent over 19 and A1 has 56.5 percent over 23. At the other end sit C1 with 176 trades and D2 with 80, which are the two entries whose hit rates rest on a sample you could defend.

So the ordering puts an 11-sample result first. Three of the eleven models are marked with a warning symbol, meaning they are presented as unreliable, and the worst of them is marked with a wastebasket. Meanwhile the largest sample, C1 at 176 trades, sits in the middle of the table at 65.3 percent.

Adding up the trades column gives 564, not the 566 verified predictions the headline claims. Adding up the implied wins gives 346 hits out of 564, which is 61.35 percent and rounds to the headline figure. The rate and the count therefore come from two different denominators, and 564 is the one the leaderboard can account for.

The stated z statistic matches 564 rather than 566

The headline reports a 61.3 percent hit rate with a z value of 5.39 and p below 0.05. Those numbers are worth checking because they are cheap to check.

Under the usual one-proportion test against a half, the standard error at 346 successes in 564 trials is the square root of 0.25 divided by 564, which is about 0.021054. The observed proportion is 0.613475, so the excess over one half is 0.113475, and the ratio is about 5.3898. That rounds to 5.39.

Running the same arithmetic on the stated 566 predictions gives about 5.38, not 5.39. So the z value published in the headline is the one you get from the leaderboard's 564, while the count printed beside it is 566. The difference is two predictions, which does not change the conclusion, but it does mean the headline's own denominator is not the denominator its statistic came from.

The p value is also framed conservatively. At a z of 5.39 the result is far past any conventional threshold, so p below 0.05 understates it. That direction of sloppiness is harmless. The denominator mismatch is the part worth resolving, because it is the same mismatch that decides whether the leaderboard is measuring what the headline says.

One signal appears twice, once inverted and once not

The findings table and the leaderboard disagree about the same signal, and reconciling them takes a step the page does not take.

Finding 8 in the table is titled late-night tariff tweets as anti-indicator, with the evidence written as 62 percent wrong, arrow to reverse equals 62 percent right, and an impact of auto-inverted. So the rule has been flipped, and the reported accuracy is the accuracy of the flipped version.

In the leaderboard, C3 is titled late-night tariff tweet to gap open, marked as an anti-indicator, marked with a wastebasket, and given a 37.5 percent hit rate. Thirty-seven point five is the complement of sixty two point five, so the leaderboard is showing the rule before the inversion while the findings table shows it after.

The same pattern appears in finding 2, where tariff to short is called 70 percent wrong with an impact of auto-reversed to long, and in A1, whose strategy is tariff during market hours to next-day drop and whose average return is negative at -0.758 percent. A rule that predicts a drop should produce a negative average return, so A1 is internally coherent. C3 is not, because its inversion is applied in one table and not the other, and the two tables sit twelve lines apart.

551 rules means one thing in one table and another in the next

The number 551 appears in three places with three different meanings.

In the headline list, 551 rules are described as surviving rules that passed train and test validation, which makes them a static output of the brute-force search. The open data table describes `surviving_rules.json` as 551 active rules, qualified as brute-force plus evolved. And the architecture diagram describes a daily pipeline of eleven steps, the first three being fetch, analyse and run 551 rules.

The middle one is the contradiction. If the rule set is also evolved, by a file called `rule_evolver.py` writing an `evolution_log.json` described as a rule evolution log with crossover and mutation, then the 551 is not a fixed set of validated survivors. Crossover and mutation produce new rules, and a rule produced that way has not been through the train and test validation that the headline attributes to all 551.

The daily pipeline treats the count as fixed, since it is written as run 551 rules, while the evolver treats it as a moving target. The page does not say whether new rules are validated before joining the set, whether the count is a cap, or whether any rules are retired.

Two dependency lines for eleven endpoints and two market clients

`requirements.txt` contains exactly two entries, `yfinance>=0.2.36` and `torch>=2.0.0`.

The page describes considerably more than that. There is an HTTP API with eleven endpoints including a chatbot endpoint described as Gemini Flash, a data catalogue and a raw file download endpoint. There is live tracking of prediction markets across two venues, Polymarket and Kalshi, with 316 or more active Trump markets tracked. There is a daily pipeline, a real-time loop, a rule evolver, a learning engine, a circuit breaker, an MCP server, an article generator and a sitemap generator.

No web framework, no HTTP client and no LLM client library appear in those two lines. So either the requirements file is not the whole story, or the extra dependencies have to be installed by hand. Given that the root also contains two log files named for the servers, the more likely reading is that this is a working directory rather than a packaged project.

`torch` is the one entry whose role is not explained anywhere on the page. Nothing in the description of the brute-force search, the pipeline or the API mentions a neural network, and the requirements file names no version of the archive or post parsers.

Fifty scripts, four committed logs and three backup copies at the root

The root directory is not laid out as a package. It holds about fifty Python modules side by side, with no `src/` directory, no package directory and no importable top level.

The numbering shows the shape of the work. `analysis_01_caps.py` runs through `analysis_12_big_moves.py`, each one a numbered investigation, plus `analysis_musk_prototype.py` outside that sequence. Alongside them sit the runtime pieces: `daily_pipeline.py`, `realtime_loop.py`, `multi_source_fetcher.py`, `build_own_archive.py`, `clean_data.py`, `deletion_detector.py`, `polymarket_client.py`, `kalshi_client.py`, `arbitrage_engine.py`, `rule_evolver.py`, `learning_engine.py`, `circuit_breaker.py`, `signal_market_mapper.py`, `ai_signal_agent.py`, `chatbot_server.py`, `mcp_server.py`, `trump_code_cli.py` and `trump_monitor.py`.

Three of those are committed alongside dated backups of themselves: `chatbot_server.py.bak-analysis` and `realtime_loop.py.bak-coin-pm`. Four log files are committed too, `archive_build.log`, `pipeline.log`, `realtime.log` and `server.log`, which means the run history of someone's machine is part of the checkout.

There is also a `handoff.md` at the root, which is a working document rather than documentation, and a `public/` directory alongside `data/`. Nothing indicates which of these files are current.

Musk scripts in the tree that the page never mentions

Three files in the repository concern a second subject entirely, and the readme does not reference any of them.

`analysis_musk_prototype.py` is named as a prototype outside the numbered analysis sequence. `fetch_musk_backfill.py` is a backfill fetcher for the same subject. `musk_overnight.py` is named for an overnight run.

The readme's framing is narrower and singular. It describes analysing one person's posting behaviour and its relationship to stock market movements, with the archive file named for his posts and every documented endpoint scoped to that one subject. Nothing in the eleven endpoints, the eleven data files or the model leaderboard covers a second subject.

That gap matters for a reader trying to work out what the system does with its time. Either those three files are dead experiments, in which case they are three modules doing nothing on every scheduled run, or they are part of a pipeline that has grown past what the page describes. Neither reading is documented, and there is no config file in the root listing which modules the daily pipeline actually invokes.

Editorial conclusion

This is a data engineering project first and a trading claim second, and the engineering is the interesting half. The repository ships its own archive of posts, a multi-source fetcher, a daily pipeline, a rule evolver, a circuit breaker, prediction market clients for two venues, an HTTP API with eleven endpoints, an MCP server and a chatbot, with a JSON file for every artefact and a downloadable data catalogue. There is real work in that.

The numbers should be read with the selection procedure in view rather than as a validated edge. The headline is 31.5 million combinations searched and 551 rules surviving train and test validation. Nothing on the page states the validation criterion, the train and test split, or whether the test set was held out from the search. That is the whole question, because a search that large will produce a large number of rules that look good on the data that found them. Likewise the 61.3 percent figure is computed over 564 trades, and the eleven models that make up the leaderboard include one with 8 trades, one with 11 and one with 17.

Two practical notes. `requirements.txt` contains exactly two lines, `yfinance` and `torch`, for a system with eleven HTTP endpoints, two prediction market clients and an LLM chatbot, so expect to install the rest yourself. And the root directory holds fifty scripts, four committed log files and three `.bak` copies of source, which means you will be reading around other people's working state rather than a packaged library.

Treat the readme's marketing register, including the giveaway promotion and the promise of pure data, as part of what you are evaluating. The dataset is genuinely public and the dashboard is genuinely live, and both are worth having regardless of whether the signal survives scrutiny.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sstklen/trump-code on GitHub