What is broken, what broke, and what we did about it.

The software behind the mathematics on this site is a family of models called TRINITY. The one that produced everything published here is the generic test model, build test_min_max_0, and its stage is pre-alpha — the reasoning for that word, rather than alpha, is on Methodology. What follows is the report from that build: what was aboard, what failed to light, how far it got on each problem, and where it is still wrong. It is written the way a test flight is written up, which means the failures are the content and not the footnotes.

The engines, and the one that did not light

Measured on 2026-10-05 by starting the system and recording what happened — not read off a list. There are 91 plugin files in the tree; 37 of them register through the domain mechanism and are what the loader actually tries to bring up. Of those, 36 lit and 1 did not, exposing 17 tools and 0 backends. The one that did not light fails at import, which means it never runs at all — not that it runs badly.

• bsd_formula_completa — the PARI bindings it needs (cypari2) are not available in the measurement environment, and its computation has not yet been moved to a host that has them

One engine is off, and the reason is one library. PARI’s Python bindings (cypari2) are not available in the environment that runs these measurements, and until 23 September that switched off both engines that compute the global side of Birch and Swinnerton-Dyer. The rank engine now sends its PARI computation to a separate host that has the library, and keeps the answer — a fixed curve always has the same rank, so the result is worth remembering, and the engine starts even when that host is switched off. The one still off is the engine that predicts the order of Ш from the full BSD formula: its chain of PARI calls is longer and has not been moved yet, which is exactly why that row below stops where it stops.

The remaining files are not all dead weight and not all alive either: beyond the 37 registered, some are imported directly by other modules, and 22 are orphans that contain real logic and nothing references them. Eighteen more were identical empty stubs — fifteen lines each, a class, a status string, no functions — and those were deleted rather than counted.

10 problems, and the wall each one hit

The counts are the findings registry, the same data behind Challenges. The last column is the registry’s own statement of what is still missing, not a summary written to look tidy here.

What came out: 132 findings, and 18 of them are refutations

18 of the mathematical findings are refutations, published with the same weight as the rest: a refutation costs the same compute as a confirmation and closes a road, so it is kept so that nobody — including us — walks down it again. The strongest level is a minority: 26 results carry Lean 4’s kernel, 20% of the mathematical findings, and the rest is weaker and says so. Separately, 27 entries are software faults and process self-audits found along the way; they are published in the registry as an engineering and process log and are not counted here.

The one that is still wrong, and has not been fixed

The Tian–Yuan–Zhang corollary module ran a mass cross-check over n = 1…500 and issued 163 verdicts, of which two contradicted OEIS A003273. The first, at n = 41, was a real bug in the discriminant routine and is fixed. The second, at n = 210, is not. There the corollary predicts “not congruent” while OEIS lists 210 as congruent, and the precondition is sound and unambiguous in that case — four prime factors, 2-rank 3, class number 8 — so the bug is not where the first one was. The most likely explanation is that the corollary’s conditions were transcribed from an image of a PDF and misread. It has not been re-read line by line against the source, for lack of time. The module carries “do not use yet” in its own docstring, written by us, on purpose, and it is loaded and shipped in that state rather than quietly disabled.

Language, and the number we do not have

The mathematics is Python; the proofs that carry the strongest claim are Lean 4; the site you are reading is JavaScript on a Cloudflare Worker. Rust is 0.7% and is one component, not a rewrite.

What that line count is not. Three things, because a line count is the easiest number on this page to read as something it is not:

• It is not a measure of verified code. It counts everything in this repository at every level of verification — from results closed by Lean 4’s kernel down to exploratory work that is still a lead. The proportion that carries the strongest claim is in the registry above, not here: 26 of 132 findings.
• It is not all of the model. TRINITY is larger than what is counted here, and the parts of it that are not in this repository are not published and are not in this figure. A number that leaves things out is only honest if it says so.
• It includes dead weight. Earlier versions left a good deal of it — the plugin audit alone found 22 orphans with real logic that nothing references, and 18 identical empty stubs that were deleted outright. Lines that nothing calls still count as lines, which is exactly why line counts flatter whoever quotes them.

Compute time per problem: not recorded. This is the row a flight report is supposed to have and ours does not. The runs happened across months on developer machines without a per-problem accounting of processor time, so there is no honest figure to give and an estimate here would be worth less than the admission. What can be stated is the extent instead of the cost: every V result carries the exact range it was checked over — every one of the 399,112 KRK positions, 147 primes, n = 1…500, and so on — and those ranges are published per finding on Challenges. Recording processor time per run is a change to the harness, not to this page, and until that is done this row stays empty on purpose.

This page cannot tell you the site is up. You are reading it, which settles that better than any badge would, and a green light drawn by the same server that would be down is worth nothing. So instead of a dashboard, here is what is actually true of the deployment you are looking at, and what we deliberately do not measure.

One thing this page can show you, because your browser does the work: every script and stylesheet here carries a Subresource Integrity attribute, a SHA-384 of the exact bytes the build produced, and the browser refuses to run a file whose hash does not match. The bars above re-hash those files from your browser’s cache with crypto.subtle and compare with the attributes in this page’s HTML. It proves nothing about uptime and nothing about the server’s honesty (the server wrote the attributes); it shows that the bytes that reached this browser are the bytes that were signed. The same hashes are recomputed from the deployed bundle before every release.

Things that will look like faults and are not, plus the limits worth knowing before you run into them.

• The findings registry is recorded in Spanish, which is the language the work is done in, and translated here by hand. The Spanish original sits one click away in every cell and is the version that governs. See the note on Challenges.
• The public compute API is closed as of 7 August 2026 and returns 403 to everyone. It is not broken and it is not rate-limiting you: it is closed. Access is limited to auditors and experts engaged and paid by us, with a client code issued directly, and there is no application form. Everything that computes in your own browser is unaffected. See /api.
• Nothing on this site has been peer-reviewed, and one earlier preprint was withdrawn by its author. Both are on Publications.
• Nine items on our compliance board are things we do not have. They are listed at /privacy#s7 rather than left out.

The rate limiter switched itself off every afternoon for four days

resolved

KSI-2026-004 · 29 August – 2 September 2026, each day from early afternoon UTC until midnight UTC

What it did to you

Nothing visible broke, which is the problem. Our edge store has a free-tier ceiling of 1,000 writes per day, and the site went through it on four consecutive days (measured afterwards: 1,182, 2,804, 1,147 and 1,166 writes). Every write after the ceiling failed, and everything that writes is built to fail open: the site-wide and API rate limits stopped counting and so stopped limiting; the block counters the hourly detection sweep reads under-counted; the live Kaggle standing on Challenges went stale for up to ten hours at a time. No visitor was blocked, and nothing was lost or exposed.

What caused it

The rate limiter kept its counters in KV, one read and one write for every dynamic request. A quiet site fits inside a thousand writes; a handful of scanning bots does not, and their traffic is exactly the traffic the limiter exists for. The failure was silent because failing open on a storage error is the right call for a public page, and nothing distinguished “the store had a bad moment” from “the store is closed until midnight”.

What changed

Rate limiting moved to the Workers Rate Limiting binding, an in-memory bucket held by the Cloudflare machine serving you, with the same thresholds (120 requests a minute site-wide, 20 for the API) and no storage operation per request. The block counters stay in KV, which now sees a few hundred writes a day instead of a few thousand. The storage table was updated the same day, since two rows it declared no longer exist.

What the fix costs

The new limiter is looser than the old one on paper, and we would rather say so than let the fix read as a pure win. Its bucket is per machine, and we measured what that means: 130 requests each on a fresh connection did not trip a limit of 120 a minute, because they were spread across several machines in the same city; 140 on one connection tripped it at the 122nd, exactly where the old counter did. So a client that reconnects every request sees more headroom than the number suggests. We took that trade knowingly: the previous limiter was strictly worse, because for several hours a day it was not limiting anything at all.

What it taught us

A limit that fails open is only a limit while its store is healthy, so the store’s own limits are part of the design. Found by asking why a three-hourly job had stopped writing, not by any alarm; the alarm is the next thing to build.

The museum shipped inert: fifteen exhibits loaded and did nothing

resolved

KSI-2026-003 · 5 August 2026, roughly 01:40–02:10 UTC (about half an hour)

What it did to you

Every interactive exhibit in The Notebook — Game of Life, the Collatz stepper, RSA key generation, the orbit and integrator panels, the float race, the 3D endgame surface and the sonification — rendered correctly and then did nothing at all. No error appeared in any console. The pages looked finished.

What caused it

Splitting the museum from one page into nineteen dropped two wrapper elements, #kodama-observatory and #kodama-tools. Both are pure JavaScript hooks with no styling, and the scripts that need them open by checking they exist and returning if they do not. So every script loaded, checked, and quietly stopped.

What changed

The wrappers were restored in the shared page shell rather than in the manifest, so a new page cannot be added to the museum without them. Caught by asking the deployed page whether the RSA panel contained any digits; it did not.

What it taught us

The split was verified for structure and links and not for behaviour, and behaviour was what broke. Rendering is not running.

The API could be made to return 2.2 MB from a 1 KB request

resolved

KSI-2026-002 · Present since the endpoint launched; fixed 5 August 2026

What it did to you

No outage and no data exposure. A single request within the documented limits returned 2,238,231 bytes in 918 ms — about 2,200× amplification, and 44.8 MB reachable from one address inside the per-IP rate limit. Nobody appears to have used it; we found it auditing our own endpoint.

What caused it

The response cap counted trajectory steps rather than bytes. Each step carries two full decimal integers, so a thousand steps is a few kilobytes for a ten-digit start and two megabytes for a thousand-digit one. The limit was correct for what someone types into the demo and wrong for what someone sends deliberately.

What changed

The step budget now scales with the size of the numbers involved, capping the worst allowed case at about 63 KB. Published in full at /api with the measured numbers rather than patched quietly.

What it taught us

A limit that is generous for the typical input can be an amplification vector for the extreme one. Cap the output, not the iteration count.

A published paper described five theorems as kernel-checked when they are not

resolved

KSI-2026-001 · Deposited 4 August 2026; corrected on this site 5 August 2026

What it did to you

Our own claim was stronger than our own evidence. The KRK paper and the chess exhibit both described five Lean 4 theorems as “kernel-checked”. They are closed with native_decide, which runs the decision procedure through Lean’s compiled evaluator and asserts the result — the kernel never re-checks it. #print axioms reports a generated axiom per theorem.

What caused it

The wording was written from the intent rather than from the axiom list, and nobody ran #print axioms before publishing.

What changed

Corrected in the Lean sources, the exhibit and the paper, with an explicit trust-base note stating what is and is not verified. A corrected version of the deposit follows rather than a silent edit of the record.

What it taught us

Machine-checked, computationally verified and proved are three different claims. Read the axioms, not the intention.

This is the changelog of the website, and only of the website. The software that does the mathematics has its own history and its own versions, and it is not this one — putting them in the same list would give a single timeline that describes neither. What that software is and how far it got is the flight report above.

The most recent 25 of 576 changes, one line each: short hash, which parts of the site it touched, and how big it was. Everything older is summarised by month below, because this list grows without limit and a changelog that prints all of it becomes unreadable exactly when it starts being worth reading.

We do not publish how many files each change touched. It looks harmless and it is not: repeated across hundreds of entries, a file count draws the size and shape of every part of the codebase, and tells anyone looking for a way in how many pieces each kind of change moves. That is for whoever writes it to know. What replaces it is a magnitude in four wide bands — touch-up, small, moderate, substantial — which answers the question a reader actually has (was this a correction or a rebuild) and is too coarse to draw anything with.

The commit messages themselves are not reproduced. They are written in Spanish, which is the language the work is done in, and everything served on this site is in English; translating hundreds of them by hand is not realistic and translating them by machine would be publishing text nobody has read. So each entry says what can be derived without translating anything — which, for the question “did this page change and when”, is the part you needed.

The version marker in the footer of every page names the exact build you are looking at. When it carries a suffix like +content.4f2a9c1, that deploy shipped changes that were not committed — a hotfix — and the suffix says what kind it was and gives it an identifier of its own: the first seven hex digits of a SHA‑256 over the whole uncommitted diff. Two different hotfixes on the same commit cannot share it, and the same one always gives the same digits, so it can be reproduced from the machine that deployed. It used to read simply “+ uncommitted changes”, which told you the tree was dirty and nothing else.

The most recent 25, day by day

Before that, by month

Kept as counts rather than entries. The detail is in the repository; what belongs on a public page is the shape of the activity, not a line per commit going back forever.

Use the marker in the corner of any page, or write to us via @KodamaSecLabs. Either way you get a reference such as KSR-7Q2M4D, issued the moment the report is filed and before anyone has read it — so it is proof we received it, not proof we agreed. Reports are anonymous: no name, no email, no address stored against them. If you want an answer, say how to reach you inside the message; we do not ask.

Security issues do not go here. This queue is public, and a vulnerability with a reference number in a public queue is a vulnerability with an audience. Use security.txt — the coordinated-disclosure terms and the safe harbour are in section 4H.