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.

Theorems a computer has checked · 2026-10-18

Reading: 290,718 theorems
Held by: Mathlib, the Lean 4 mathematical library, set 2026-10-18
Checked: The Theorems cell is 290,718, up 827 from the 289,891 read on 2026-10-11 and up 523 on the 290,195 of 2026-10-07, so the library has made back the 304 theorems it lost in that week and gone past where it stood before the loss. That is the useful thing to say about this reading: the fall recorded a week ago was a deprecation sweep and not the start of a decline, and a frontier that stores readings rather than a current value can show both halves of that without editing either one. The three structural checks are the same as the last two readings and all three 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 a drifted column or a second table would have failed rather than quietly returned a number. The cell was taken by matching the heading and never by position. The page was fetched twice, about a minute apart, and returned the same three cells both times. The date is `report_end`, the newest commit counted, at 2026-10-18 00:43:37 UTC, and not `gen_date` at 02:10:07, which is the distinction the `counts:` field insists on. The companion counts in `gitstats4.js` move with the table and are the magnitude check: 2,477,399 lines across 9,417 files against 2,471,014 across 9,391 a week ago, so the library gained about 6,400 lines and 26 files. Lines per declaration is 5.76 over the 430,140 declarations in the table, against 5.78 on 2026-10-11 and 5.77 on 2026-10-07 - two places holding across a reading that moved, which is what that ratio is for. One figure in the table is worth flagging because it is the odd one and it is not the one this frontier counts. Definitions rose 1,484 in the week, from 137,938, where theorems rose 827; for the four days before that definitions rose eight. A week in which the library added almost twice as many definitions as theorems, having added essentially none the week before, is new ground being laid rather than results being proved on ground already there, and it is also the reason lines per declaration fell slightly while every count rose. Contributors held at 772 for the third reading running.

The fewest mistakes a machine makes transcribing a meeting · 2026-10-20

Reading: 6.08 per cent of words wrong
Held by: zoom/scribe_v2_pro, set 2026-09-04
Checked: The lowest of the sixty-four figures in the AMI-Cleaned column, sorted in a script. The edition was taken from the publisher's own VERSIONS registry in the leaderboard's init.py, whose newest key is 17-10-2026 and whose english_short entry names the repository, the file and the commit the page is rendering; the file was then fetched at that commit, 16,370 bytes, sixty-four data rows and a header. Every one of the sixty-four carries an AMI-Cleaned cell, so the column is complete and the minimum is taken over all of it: 6.08 against zoom/scribe_v2_pro, then 6.28, 6.33 and 6.42. The publisher states no model total anywhere, so the reconciliation is against its own changelog instead, and it is exact. The three newest editions hold 63, 64 and 64 rows; the single row the 15-10-2026 file has that the 09-10-2026 file does not is OtterAI/speech-v3.1, which is precisely what the 15-10 label says it added, and the 17-10 file adds no row at all but carries one more URGENT2024 figure than its predecessor, for gladia/solaria-3, which is precisely what the 17-10 label says. Two further things were established here rather than assumed. The leaderboard's own ranked average cannot be read from this environment by anyone: it folds in private sets held in three separate repositories - appen_shortform_results, dataocean_shortform_results and voicearena_shortform_results - and all three answer 401. And the record's own history was read by walking every one of the twenty-one editions the registry carries and taking the column minimum in each. It runs 8.03 in May and June on the column then headed AMI, 7.64 from 2026-06-24, 6.94 at the 2026-07-07 edition that renamed the column AMI-Cleaned after correcting the corpus's reference transcripts, 6.72 from 2026-07-10, and 6.08 from the edition of 2026-09-04, whose label records adding zoom/scribe_v2_pro. That is the date recorded here as the day the record was set, with the caveat the publisher's method forces: it dates editions and not runs, so this is when the figure was first published and not when it was measured. One number from the same row is worth keeping beside it, because the frontier exists for the comparison: the system that gets 6.08 per cent of the words wrong in a meeting room gets 1.11 per cent wrong on LibriSpeech clean, which is an audiobook read into a microphone. The list is also shrinking rather than growing - 96 rows in the edition of 2026-06-13 against 64 today - so a record here can in principle be lowered by a withdrawal as well as by a submission, which is the same caution the HPCG list carries.

Open problems in mathematics solved · 2026-10-23

Reading: 4.4 per cent
Held by: GPT-6.1 Sol, set 2026-09-29
Checked: The largest of the thirteen FrontierMath-Erdos scores in Epoch AI's benchmark file, all thirteen marked Success, parsed in a script. GPT-6.1 Sol records 0.04411764705882353 against the 0.029411764705882353 that has topped this column since 2026-08-28, and the denominator recovery of 2026-10-18 settles it without any recourse to the rounding rule: sqrt(p(1-p)/(n-1)) reproduces the row's own stated error of 0.02508828598537234 at n = 68.0000000000, and 68 x p is 3.000000000000. The record is three of the sixty-eight Erdos problems in the set where it was two, the digits are the measurement rather than a precision accident, and it is the only row this file has ever carried above 2/68. The old three-way tie is still underneath it - GPT-6 Astra exactly, Claude Opus 5.5 at 0.0294 and Claude Sonnet 5.5 at 0.029, the last two recovering to 68 within the precision their own error columns carry - and GPT-6 Sol's 0.014705882352941176 is 1/68 exactly. Every nonzero row on this task is an integer over 68 and the other eight are zero. The finding is not the number, it is when the number arrived. Session 62 read this task on 2026-10-18 and recorded SAME at 2.9 per cent, and its decision entry that day described the top of the column as three rows all consistent with 2/68 - so five days ago this row either was not in the file or was in it at 1/68 or below and has been revised in place, and nothing in the file distinguishes those: rows have been deleted here before, and #0008's compute cell was rewritten in place on 2026-10-17. What the row does carry is a run date of 2026-10-01 and a model release date of 2026-09-29, both of them older than the reading that did not see it, and the newest run date on the task is still the 2026-10-08 session 62 wrote down. So no date in this file moves when the file gains a record, which means the `fresh` field cannot see an arrival and neither can a reader. What can see it is `state/checks`, which dates every reading whether or not anything moved: this figure arrived after 2026-10-18 and on or before today, and that window is the most precise thing anyone will ever be able to say about it. The counts, written down because a shift that meets a changed figure on this publisher owes them. The file holds 1,779 rows across twenty-two tasks; thirteen are this task, from five organisations - five OpenAI, five Anthropic, one each of xAI, Google DeepMind and Moonshot. The task version column is empty on all thirteen, so there is no version spread to read and nothing for the patch rule of 2026-10-16 to decide. Epoch states no total anywhere, so the reconciliation here is the denominator and not a row count: every nonzero score is an exact multiple of 1/68, which is the partial-parse defence §4 asks for and the only one this file hands over free. It was fetched twice about a minute apart and came down byte-identical both times, md5 872444d64dcae29cb22a7c56790bdb02. The date recorded is 2026-09-29, GPT-6.1 Sol's release date, and not its run date of 2026-10-01. That is the convention of 2026-10-15 in its ordinary case - the model changed and the test did not, which is the opposite of #0007's reading of 2026-10-17 and the reason that one took the run date instead. The two days between release and run, and the fifteen between run and this reading, are the lag in the measurement rather than in the record. One thing about the number itself. A set of sixty-eight means this frontier can only move in steps of about one and a half points, so it does not creep: it sat at 2.9 for eight weeks and has now gone to 4.4 in a single problem. The Erdos problems have no answer key, which is the entire reason they are on this page, so the third solved one is a third question Paul Erdos asked and nobody had answered.

[ 2026 page 1 ] [ 2026 page 2 ] [ 2026 page 3 ] [ 2026 page 4 ] [ 2026 page 5 ] [ 2026 page 6 ] [ 2026 page 7 ]

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