Skip to content

pages: the first twenty pages of Algebra I read on the fleet - #5

Open
tamnd wants to merge 5 commits into
mainfrom
ocr-pilot-algebra-i
Open

pages: the first twenty pages of Algebra I read on the fleet#5
tamnd wants to merge 5 commits into
mainfrom
ocr-pilot-algebra-i

Conversation

@tamnd

@tamnd tamnd commented Aug 10, 2026

Copy link
Copy Markdown
Owner

No description provided.

Twenty pages of Algebra I, pages 41 to 60, read on the fleet on 10 August 2026.
This is the first OCR output in the corpus. Everything before it came out of a
text layer.

Fifteen pages accepted, five dead after three attempts. The milestone asks for
95 percent and this is 75, so it does not pass, and reports/fleet-bench.md says
why rather than rounding it up.

The short version is that the driver abandoned batches without killing them, so
each one went on burning a box that the next batch had to share. server3 read a
page in 63 seconds on its first batch and 1381 on its fourth, and ten minutes
after the run ended an abandoned batch was still running on server2 with two
Chrome instances under it and the box at load 11.27. Killing it took the load to
6.08. That is fixed in the solver.

Also committed: reports/ocr-alg-i-iii.json, the per batch record, and
reports/ocr-usage.jsonl, which keeps the failed batches from the debugging
session as well as the good ones. The failures are the part worth keeping.

Pages 50 and 53 carry a formula that opens with a dollar and never closes it.
They were accepted because the balance rule counted over the whole page and two
unclosed dollars add to an even count. The rule counts paragraphs now and flags
both, so they are in the corpus with a known defect and a repair pass ahead of
them, which is the same footing as the 45 flagged pages of Algebra VIII.

No PDFs and no page images, as ever. Markdown only.
BODY
pages: the first twenty pages of Algebra I read on the fleet

Fifteen pages read by the model, five blank pages found by the renderer.

This is the first OCR output in this repository. Every page committed before now
came out of a PDF text layer, which is cheap and exact and only works for the
volumes that have one. Algebra I to III is a scan.

reports/fleet-bench.md is the measurement that goes with it: what each host did,
how fast, how it decayed over an hour, and why. reports/ocr-alg-i-iii.json is
the per batch record and reports/ocr-usage.jsonl is the running log, failed
batches included.

Fifteen of twenty pages accepted is 75 percent and the milestone wants 95, so
this does not pass. Pages 44, 45, 51, 55 and 59 are dead after three attempts
and want re-reading on a rested fleet. Pages 50 and 53 are in with a known
unclosed formula each.
tamnd added 2 commits August 11, 2026 04:44
Pages 60, 61 and 102 to 105 of Algebra I, read on the fleet and accepted
against the seven rules. 102 needed a second attempt at 600 dpi, which the
front matter records.

The check over everything written so far: 20 pages, 5 blank, 2 rejected,
90 per cent accepted. The two are 50 and 53, both on the math rule, both
read before the run started recording conversation URLs, so neither can be
mended in its own thread and both need reading again from the image.

The blank pages in the diff are timestamp only. A page with no ink on it
is rewritten by every fill with a fresh generated stamp, which is diff
noise in a repo meant to be read as pull requests, and is worth fixing.
Both needed a third attempt at 600 dpi after two readings came back with
no answer at all, which is the failure the tool has since learned to name.
The batch took 34m55s for six pages, ten pages an hour on one lane.

The check over everything written: 22 pages, 5 blank, 2 rejected, 90.9 per
cent accepted. The two are still 50 and 53.
@tamnd

tamnd commented Aug 10, 2026

Copy link
Copy Markdown
Owner Author

Eight more pages since the first push: 60, 61, 100 to 105. Pages 100 and 101 each needed a third attempt at 600 dpi after two readings came back with no answer at all, which is the failure the tool has since learned to name rather than report as a timeout.

The check over everything written so far: 22 pages, 5 blank, 2 rejected, 90.9 per cent accepted. The two are 50 and 53, both on the math rule, both read before runs started recording conversation URLs, so neither can be mended in its own thread and both need reading from the image again. That run is queued and waiting for a box: all three are pinned by other tenants right now, server2 compiling somebody else's rust at a load of 8 on six cores, server3 at 8 on eight running a crawler and postgres.

The blank pages in the earlier diff were timestamp only, on nothing but a fresh generated stamp. That is fixed upstream in tamnd/bourbaki-solver, so a page with no ink on it is left where it is.

Pages 51, 62, 65, 66 and 70. Page 51 came back on the second attempt, at 600
dpi, after the first read produced no answer at all.

The usage log carries eight lines from the run before this one, every one of
them a batch refused for having the same image in it twice. That is the whole
evidence for the duplicate jobs bug, so it stays in rather than being tidied
away: 21 pages went from pending to dead in 41 seconds that morning without a
single image leaving the laptop.

The run report is not in this commit. The one on disk belongs to the failed run
and the live run rewrites it when it finishes.

Audit of page 51 against the scan: the body is faithful, but Definition 5 reads
i in [1, n] on the page and the transcription has i in {1, n}, which is a two
element set and not the interval. One character, no rule can see it, and the
repair pass only knows how to move dollar signs. That is the next thing to fix.
Six batches, 63 pages attempted, none written. Every page failed the
same way, "no attach control on the page", and every failure banned an
account that had nothing wrong with it.

The cause is fixed in tamnd/chatgpt-tool d273c5a6. Cloudflare was
holding the host on an interstitial, which is its own document with an
empty body under the title "Just a moment...", and the OCR path was the
one path in the tool that had never learned to recognise one. So it
looked for the attach button on a page that had no buttons at all,
reported the button as missing, blamed the account, rotated to the next
one and met the same wall from the same IP.

This report is kept as it came out rather than cleaned up. A run that
fails is data about the fleet, and the shape of this one, every page
failing identically and the batch carrying on regardless, is what the
give-up-as-a-whole change is for.
@tamnd tamnd added pages Extracted page markdown ocr Vision OCR through the fleet labels Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ocr Vision OCR through the fleet pages Extracted page markdown

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant