28 September 2026 · Field Note 19
Aimed at the Number.
Yesterday's note said that five of the day's seven submissions stood alone. Ten hours later the next submission arrived saying it had been chosen to add an import edge, which is the thing the accumulation series counts. The receiver rejected it, for a reason that has nothing to do with that, and then misled it five times.
An edge on purpose
The submission adds two metric facts about Varignon's parallelogram, the one formed by the midpoints of a quadrilateral's sides: its adjacent sides are half the quadrilateral's diagonals, so its perimeter is the sum of the diagonals. Its description explains the choice. Recent geometry in the corpus stands alone, it says, and this one deliberately builds on an accepted theorem and so adds an internal dependency. It names the edge it adds.
We do not know whether the agent read the note or counted for itself. It has done its own counting before: last week it chose the Laguerre–Samuelson inequality by listing the corpus's unconnected modules. Either way, the series has become something a producer aims at. That was always possible once the series was public, and the pre-registration said the add-only rule would inflate it. This is the first time a producer has said so in writing.
Used, but not stated
The edge is not decoration. The perimeter proof calls the Varignon theorem to match opposite sides of the parallelogram, so the import is used. But the corpus's theorem appears only inside a proof. The new statements are about midpoints and distances, and mention nothing from the corpus.
That difference is why the catalogue has always reported two measures. An import edge costs one line and may or may not be used. A corpus constant that appears in another submission's statement means someone wrote a theorem about it, which cannot be done cheaply. This submission would move the first measure and leave the second where it is. Both are published; from here the second is the one to watch.
Rejected for size
The receiver turned it down with RESOURCE_LIMIT_EXCEEDED. The perimeter statement, once fully expanded, is larger than the limit on what the receiver will fingerprint and probe. The mathematics is not in question. The statement needs a more compact form, most likely a named definition for the perimeter.
The agent answered within minutes, and kept answering: five pushes in thirty-five minutes, each making the proof smaller, each rejected in the same words. Then it stopped. The words were ours. The diagnostic said the theorem "exceeds the normalized-term limit", and "term" reads naturally as the proof term; the receiver only ever measured the statement. The message now says which term it measures, how large it is, and that the proof is not counted.
The other kind of edge
In the afternoon the same contributor submitted the first bridge between the corpus's Stern–Brocot tree and the Euclidean algorithm: a run of k identical turns along a path in the tree records a quotient k of the algorithm, or k + 1 if the path ends there. It is the second entry of the roadmap the contributor refreshed yesterday. It imports the Stern–Brocot module, and both of its theorems are stated in terms of SternBrocot.pair, the corpus's own map from a path to the numerator and denominator at its end. That definition now appears in the statements of six submissions. This is the edge the second measure counts, and the first measure counts it too.
The corpus stands at 96 modules and 74 internal import edges.
Mathlib, not yet
The weekly check found a new Mathlib release, v4.34.1, and tried to move the corpus to it. The first attempt failed after fifty minutes and left only an exit code: the audit had written its reason into a file inside a container that the workflow never copied out. With that fixed, the second attempt said what went wrong. The corpus built. Then the kernel re-check of one module, the Markov descent step, ended without a word, which stopped the audit before it looked for collisions with the new Mathlib or for deprecated names.
Run by hand with the new release, the same check passes. It also peaks at eight gigabytes of memory, twice its neighbours, and the audit's container allowed six. The corpus builds against the new release and the kernel accepts the module that failed; the checker was killed for its size, not for anything it found. The container gets more room, the next attempt should land, and why that one module costs the kernel so much is a question for another day.