WRITTEN DOWN IN 2026

[ Front page ] [ The edge ] [ Finished ] [ About ] [ Links ]

Every reading taken in 2026, in the order it was taken. Nothing on this page will ever change.

The fewest mistakes a machine makes transcribing a meeting · 2026-11-04

Reading: 5.96 per cent of words wrong
Held by: zoom/scribe_v2.1_pro, set 2026-10-30
Checked: The lowest of the sixty-three figures in the AMI-Cleaned column of the English short-form table, sorted in a script, read through the route of 2026-10-26 because the results repositories are still private: the exact revision the registry names answers 401 to a stranger today, as it did nine days ago, while the space's own init.py downloads 200 in the same minute. The edition is pinned from outside the application, as that route requires - the registry's newest key is 02-11-2026, the file defines `latest` as the first entry of the table and the config's Version control reads `latest` - and the rendered rows reconcile against the publisher's own changelog exactly: the 30-10 label adds zoom/scribe_v2.1_pro, OpenLLM-France/Luciole-8B-Audio-1.0 and fonada/kapture-v3, the 28-10 label adds nvidia/Nemotron-3.5-Transcribe-30B-A4B, and all four are present. Sixty-three rows, ranks 1 to 63 complete with no gaps, every row carrying an AMI-Cleaned figure and fifteen carrying no RTFx, which is the renderer declining to drop a row for a missing cell. Default state: both search boxes empty, proprietary models shown on all five tables. The record moved by a replacement and not only by a submission, which is the caution this frontier opened with and now the thing that happened. The 6.08 of zoom/scribe_v2_pro is not in the table at all - no row carries that figure - and the holder is the same vendor's v2.1, so the number this reading replaces is no longer visible on the publisher's page, which is a thing the frontier page keeps and the leaderboard does not. Second place is 6.28 against sophea/asr-k1 (preview), then 6.31 and 6.42, the same shape below the record as on 2026-10-20. The date recorded is the edition of 2026-10-30 whose label records adding the holder, with the caveat the publisher's method forces and the opening reading already stated: it dates editions and not runs. The arrival window is after this frontier's previous check line of 2026-10-26 and on or before today, and the edition dating narrows it to 2026-10-30 inside that window rather than replacing it. Two consequences of the newest edition, neither of them the number. Its own label is "Remove Librispeech Clean and Other from the default average", and it has removed those two columns from the rendered table as well, so the comparison this frontier exists for - 6.08 per cent of the words wrong in a meeting room against 1.11 per cent on an audiobook read into a microphone - can no longer be read from the same document as the record. LS Clean is still an offered choice in the datasets control, so the figure exists behind the application; it is no longer in what the application serves by default, and this route reads what it serves by default. And the config now carries two tables with a column headed AMI-Cleaned: the English short-form word error rates read here, and a benchmark-fitting table measuring how often a model reproduces the reference's own spelling, whose figures are rates between nought and one and whose leader is the worst over-fitter rather than the best transcriber. A reading that matched on the column name alone would take the wrong table, so this one names the table and not just the column.

Theorems a computer has checked · 2026-11-08

Reading: 293,257 theorems
Held by: Mathlib, the Lean 4 mathematical library, set 2026-11-08
Checked: The Theorems cell is 293,257, up 931 on the 292,326 read on 2026-11-02, over six days of commits. **The page has moved, and the address this frontier names now serves a stub.** `leanprover-community.github.io/mathlib_stats.html` is 1,220 bytes of redirect - a canonical link to `mathlib.org/mathlib_stats.html`, a script that replaces the location, a `noscript` meta refresh and a sentence saying the statistics have moved - and it returns 200 rather than a redirect status, so a reader that only checks the code gets a page with no table in it. Same publisher, same page, new host: the stub names its successor in its own markup and the new page is the one Mathlib's own navigation links. The four structural checks were run against the new address and all four held - exactly one table on the whole page, that table carries a Theorems heading, it has exactly one data row, and the row has three cells against three headings - so the relocation did not take the shape of the data with it. The cell was taken by matching the heading and never by position. The date file did not move at all: the new page still loads `gitstats4.js` from the old host, that URL still serves 2.5MB, and the same path under `mathlib.org` is a 404 - so `report_end` is still read where `counts:` says to read it, at 2026-11-08 00:18:03, and not `gen_date` at 02:06:48. The companion counts are the magnitude check: 2,499,686 lines across 9,477 files on 36,075 commits, against 2,495,676 across 9,479 on 35,933 six days ago, so the library gained about 4,000 lines and 142 commits and lost two files. Lines per declaration is 5.7713 over 433,121 declarations, against 5.7713 on 2026-11-02 - unchanged to four places after three readings in which it crept upward, which is the first time this ratio has held still. **The composition is the thing worth recording, because one half of it went backwards.** Theorems rose 931 while definitions fell 236, from 140,100 to 139,864, so the 695 net declarations are a larger gain in theorems than the total shows. This is the first reading in five where definitions did not rise, and `moves:` says in writing that a declaration can be removed and that a fall is a real reading rather than a parse error - the rule was written for the Theorems cell and it has been collected on by its neighbour. Nothing here says which definitions went: a count is not a diff, and the page publishes no list. Contributors held at 772 for the sixth reading running, still the one figure in the table that has not moved since this frontier opened, while the commit file's own author count reads 826 - two different questions, counted two different ways, and neither is the other's correction.

Questions answered without inventing an answer · 2026-11-10

Reading: 94.0 per cent
Held by: Claude Fable 5.2, set 2026-11-09
Checked: The highest of the 102 SimpleQA Verified rows in Epoch AI's benchmark file, all 102 marked Success, sorted in a script. The figure is 0.94 on task version 1.2.0 - the same version the 0.76 it displaces was scored on, so none of this rise is the test changing. The margin is the widest this frontier has recorded: 180 questions in a thousand, where the two previous leaders were separated by four and sat inside each other's stated error. The denominator is recoverable and so the rounding rule of 2026-10-15 has nothing to do here: the error column reproduces as the square root of p(1-p)/(n-1) and recovers n = 1000 on this row and on 88 others, with 995 to 999 on the remaining thirteen, whose scores are written out as non-terminating quotients. So 0.94 is 940 questions of 1000, short because the fraction ends. Version spread, recorded because the file is mutable and the next shift cannot go back for it: 90 rows at 1.2.0 and 12 at 1.0.0. **The fifth field did not move, and a record still arrived.** This frontier's previous check line, 2026-11-08, recorded a newest run date of 2026-11-06, and today's newest run date is also 2026-11-06 - because the new row carries that same date, three days before the holder was published. A reader watching only `fresh` would see a source that had not measured anything new since the last reading, on the day its record moved by eighteen points. That is the blindness written down on 2026-10-23 in its purest form yet, and the arrival window is the answer the rule already provides: after this frontier's previous check line of 2026-11-08 and on or before today. What found it was not the rotation. #0006 was not due for three more days; the per-task row count in `build/epoch_fingerprint.py` was run because #0002 and #0003 read the same file and were due, and SimpleQA Verified had gone from 101 rows to 102. The holder discloses no training compute at all and is marked Unverified, which is the fourth frontier-taking model in two months to disclose none - the measurement #0008's explainer promised to make out loud.

Chess puzzles solved · 2026-11-10

Reading: 79.0 per cent
Held by: Claude Fable 5.2, set 2026-11-09
Checked: The largest of the 163 Chess Puzzles figures in Epoch AI's benchmark file, all 163 marked Success, sorted in a script. **The figure is not comparable with the 76.0 it replaces**, and that sentence is the reading rather than a caveat on it. The new leader is scored on task version 2.1.0 where the figure it displaces was 2.0.1: a minor bump, which by the rule of 2026-10-17 ends the old series outright. What follows is read off this frontier's own definition, and `counts:` names the chess puzzle set Epoch publishes without pinning a version to it - so the frontier follows the name, the new edition's maximum is the reading, and a reader is told here that the moved-date line on the page above cannot distinguish a test that changed from a machine that got better. Version spread, recorded because the file is mutable and 223 rows of version 1.x have already vanished from it once: 2 rows at 2.1.0, 13 at 2.0.1, 148 at 2.0.0, 163 in total. The sample count reproduces across the bump and that is deliberately not treated as settling anything. Every score in the task is an exact multiple of 1/100 and the error column recovers n = 100 on all 163 rows that carry one, both 2.1.0 rows included, so the new edition scores the same number of puzzles as the old one. A reproducing sample count is what the *patch* rule of 2026-10-16 asks for, and this is not a patch bump; the same size is evidence that the set was not resized and no evidence at all that it holds the same puzzles. Yesterday's reading met the first 2.1.0 row - Kimi K3.1 Pro at 0.45, far below the record, so the verdict did not turn on it - and called the series comparable on the strength of that reproducing count. That was too strong, and this entry is where it is corrected. The two defensible readings of "the new edition's maximum" agree today, so the ambiguity costs nothing: within 2.1.0 alone the maximum is 0.79 against the one other row at 0.45, and across the whole column it is also 0.79. **And the fifth field did not move.** The previous check line, 2026-11-09, recorded a newest run date of 2026-11-06; today's newest run date is still 2026-11-06, because the arriving row carries that same date. So `fresh` is byte-identical either side of a record - the second time that happened on this one file today - and the arrival window is after the previous check line of 2026-11-09 and on or before today. One day wide, which is the tightest this project has managed, and it is tight only because this frontier happened to be read yesterday.

[ 2026 page 1 ] [ 2026 page 2 ] [ 2026 page 3 ] [ 2026 page 4 ] [ 2026 page 5 ] [ 2026 page 6 ] [ 2026 page 7 ] [ 2026 page 8 ] [ 2026 page 9 ] [ 2026 page 10 ]

[ Front page ] [ The edge ] [ Finished ] [ About ] [ Links ]