ArXRev: Bringing Historical Mathematics Back to Life
Some of the most important mathematical papers ever written are still difficult to use.
They may exist only as scans of ageing journal pages. Their typography was designed for print rather than search. The language can be unfamiliar to modern readers, and even a good OCR system often struggles when dense prose is interrupted by equations, specialist symbols and nineteenth-century notation.
ArXRev is a project built to close that gap. It turns scanned historical mathematics papers into structured, editable LaTeX and English translations, then places the result in a review workflow where people can compare the reconstruction with the source, correct it and prepare it for publication.
The idea is deliberately collaborative. AI produces a useful first draft, but it does not make the final scholarly judgement. ArXRev gives that judgement to a community of reviewers.
Access to the working archive is currently invitation-only. Authentication keeps uploads, edits and review activity associated with a contributor while the collection and workflow are still being developed.
From a Scan to a Reviewable Paper
Every paper begins with its bibliographic identity. A contributor records the original title, authors, year, language, journal, volume and page range before uploading the scanned PDF. Keeping this information separate from the generated translation matters: the archive needs to preserve what was originally published, not quietly replace it with model-produced metadata.
Once the file is uploaded, the processing pipeline reconstructs the paper as LaTeX and translates its prose into English. It also produces a translated title and abstract, while preserving the mathematical structure of the document. Equations, references, page boundaries and figures all need different treatment, so this is more than extracting a stream of text from a PDF.
The result enters a clear lifecycle. A new paper moves from processing to Needs review, where an authenticated contributor can inspect it, edit the LaTeX, add notes and compile a new PDF. Only after the reconstruction has been checked should it become part of the published archive.
That separation between machine processing and human approval is central to the project. A plausible-looking mathematical transcription is not necessarily a faithful one.
Why Mathematical OCR Is a Different Problem
Ordinary OCR is usually evaluated by asking whether it recognised the words on a page. Historical mathematics adds several more layers of difficulty.
A single page can combine running text, display equations, numbered formulas, footnotes, diagrams and symbols whose meaning depends on their exact placement. Older typefaces introduce ambiguity between letters, digits and operators. A small transcription mistake inside an equation can change the mathematics even when the surrounding paragraph still reads naturally.
Translation creates another tension. The English should be readable, but mathematical notation, equation numbering and the logical structure of the argument must remain stable. Literal translation can preserve awkward constructions from the source language; aggressive rewriting can accidentally alter the author's claim.
ArXRev treats reconstruction as a staged engineering problem rather than a single prompt:
- The scanned PDF is rendered and sent through a vision-based LaTeX extraction stage.
- Longer papers are processed in page groups and stitched back into one document.
- A second stage improves the English, normalises the document structure, repairs the header and builds bibliography data.
- The system generates an abstract and translated title from the reconstructed paper.
- A containerised TeX environment compiles the result and attempts bounded repairs when compilation exposes structural problems.
The intermediate artefacts remain inspectable. This makes it possible to diagnose whether an error came from visual extraction, translation, post-processing or compilation instead of treating the whole pipeline as a black box.
Review Means Seeing the Evidence
The review workspace is built around comparison. On the left, a reviewer can switch between the original scanned PDF and the generated LaTeX source. On the right, ArXRev renders the compiled English paper.
This side-by-side arrangement keeps the evidence close to every correction. A reviewer can check whether a symbol was transcribed correctly, whether a sentence preserves the original meaning and whether the reconstructed layout still reflects the source paper. Switching to the LaTeX view makes the correction directly, without moving into a separate desktop editing workflow.
Compilation is available from the same screen. That short feedback loop is important because a source edit can be textually correct but still break the TeX document. Reviewers can see both the semantic result and the compiled result before moving a paper forward.
Notes provide a lightweight place to flag uncertainty or leave context for the next contributor. The workflow is intentionally closer to maintaining a shared knowledge resource than submitting an opaque correction request.
A Shared Review Queue
Inside the invitation-only workspace, ArXRev exposes papers awaiting attention through a shared review queue. Contributors can search the collection and narrow it by author, journal or publication year. Each result keeps the translated title beside the original bibliographic context and makes the current status visible.
This changes the shape of the work. Digitisation is not limited to the person who uploaded a scan, and review does not have to happen in one sitting. A contributor familiar with German mathematical terminology might improve the prose; another might recognise a notation error; someone else might concentrate on whether the LaTeX compiles cleanly.
The model is closer to Wikipedia than to a conventional document-conversion service: the platform accelerates the mechanical work, while the archive improves through many small, attributable human contributions.
The Architecture Behind the Workflow
ArXRev uses a serverless AWS architecture, but the more important design decision is separation of responsibilities. The interactive application stays responsive while extraction, language work and compilation run as independently observable jobs.
The product layer
The interface is a TypeScript application built with Next.js and React. It uses the App Router for the paper catalogue, metadata setup, review queue and editor screens, while AWS Amplify hosts the frontend and connects it to authentication.
The review workspace is not a generic text area. CodeMirror provides LaTeX syntax editing, search and line numbers. A custom preview component protects mathematical spans while converting document structure into HTML, then MathJax typesets the equations in the browser. Reviewers can switch the evidence panel between the source PDF and LaTeX without leaving the page.
Edits and reviewer notes are saved after a short debounce, while explicit save remains available. TanStack Query manages server state, invalidates related catalogue and activity queries after mutations, and polls papers while extraction or compilation is running. This keeps workflow state current without introducing a separate real-time service.
A typed API boundary
The application API is written in Python with FastAPI, adapted to AWS Lambda through Mangum and exposed through an API Gateway HTTP API. FastAPI's OpenAPI document is used to generate the frontend's TypeScript models and fetch client with Hey API. That makes a schema change visible at build time rather than discovering an incompatible response in the browser.
Amazon Cognito handles invitation-based identity and Google sign-in. The frontend attaches the current ID token to API requests; the backend verifies the signature against Cognito's published keys and checks issuer, audience, expiry and token use before accepting it.
Storage designed around the paper lifecycle
Amazon DynamoDB stores the operational model in one table. Partition and sort keys group a paper head record, editable LaTeX, processing jobs, authors and journals, while a secondary index supports status-driven views such as the review queue. Status changes update the index keys as part of the same write, so the UI can query the current workflow directly rather than reconstructing it from logs.
Amazon S3 holds the heavier and more durable artefacts: original PDFs, raw OCR output, extracted figures, benchmark inputs, generated PDFs and the search database. Uploads use narrowly scoped pre-signed URLs, allowing the browser to send a large scan or figure directly to object storage without routing the bytes through the API Lambda.
Search uses a deliberately compact approach. The compilation service maintains a SQLite FTS5 index containing titles, abstracts, authors, journals, dates and reconstructed text. The database file is versioned in S3; API Lambdas cache the latest copy in temporary storage and refresh it when the S3 ETag changes. This provides full-text search without operating a separate search cluster at the current archive size.
An event-driven document pipeline
The processing path is asynchronous:
- The browser requests a scoped upload URL and writes
input.pdfdirectly to the paper's S3 prefix. - The S3 notification publishes a message to Amazon SQS.
- The extraction Lambda renders the PDF with
pypdfium2, sends page images to a vision-capable model and writes raw LaTeX plus figure assets back to S3. - A second S3 notification and queue start language post-processing, header repair, bibliography generation, title extraction and abstract generation.
- The language stage stores the editable document in DynamoDB and submits a compilation job.
- A container-image Lambda runs
latexmk, BibTeX and the TeX toolchain, writes the compiled PDF to S3 and refreshes the full-text index.
Each processing queue has a dead-letter queue. Visibility timeouts exceed Lambda timeouts, concurrency is intentionally bounded, and status plus shortened error details are written back to the paper and job records. These choices are less glamorous than the model call, but they are what make retries understandable and prevent a temporary provider failure from becoming a lost upload.
The compile worker is shipped as a container image stored in Amazon ECR, because a complete TeX environment does not fit comfortably into a small function bundle. Infrastructure is defined with Terraform, including least-privilege IAM policies, queues, event mappings, buckets, API resources, authentication and separate development and production state.
Building for Replaceable AI
AI model quality changes quickly, especially for documents that combine vision, translation and structured output. ArXRev therefore resolves model selection from deployment configuration and keeps the calls behind an OpenAI-compatible client instead of spreading provider-specific code across the application.
The first processing stage renders every PDF page to RGB and works in configurable page groups. A short paper can be reconstructed in one request; a long paper is split into chunks with continuation prompts and then stitched into one document. This avoids pushing an entire journal article through one oversized context while preserving page order and document continuity.
Figures have an explicit strategy. A paper can preserve cropped bitmap regions from the source or ask the model to rebuild suitable diagrams in LaTeX or TikZ. When original figures are selected, the extractor detects dense visual regions, stores them as separate assets and gives the model only valid filenames to reference. That prevents invented asset paths and keeps scanned diagrams traceable to their source pages.
The second AI stage has several smaller responsibilities rather than one enormous rewrite prompt. It improves the translation, normalises LaTeX, repairs the title block, builds bibliography data, extracts the translated title and generates an abstract. Failures in optional enrichment steps are recorded without necessarily discarding a usable reconstruction.
Compilation is a separate engineering loop. Deterministic repairs run first for known structural issues: missing document boundaries, mismatched environments, required packages, bibliography files, image paths and common historical operator macros. If compilation still fails, a constrained repair agent receives the relevant error and a bounded section of source. It has strict limits on attempts, document size, context and time remaining. Successful repairs are persisted so that the reviewer sees the exact source that produced the PDF.
The project also contains a benchmark runner that can route extraction and language stages to different models. Every run records latency, prompt and completion tokens, estimated cost, chunk size and stage-level timing. Its scoring goes beyond plain text similarity: it measures section structure, exact and normalised mathematical-symbol precision and recall, equation coverage, theorem and table preservation, equation-number retention and suspiciously literal phrasing.
Those measurements are not a substitute for expert review. They make model changes testable. A faster or cheaper configuration is only an improvement if it does not silently remove equations, damage notation or make the English less faithful.
What We Learned
The hardest part of digitising old mathematics is not generating LaTeX once. It is building a system that makes uncertainty visible and correction practical.
Several design choices followed from that:
- Preserve the original scan and bibliographic record as immutable evidence.
- Keep extraction, language improvement and compilation as separate stages.
- Show the source, editable representation and rendered output together.
- Record failures and intermediate artefacts instead of hiding them behind a generic processing message.
- Evaluate mathematical structure as well as prose quality.
- Treat community review as part of the product, not as a clean-up step after the product has finished.
This also suggests a broader lesson for AI-assisted knowledge work. Human review becomes much more effective when the interface shows exactly what the model saw, what it produced and where a correction belongs.
What Comes Next
There is plenty still to explore: richer edit history, more explicit attribution, specialist review tools for equations and figures, retrieval across the published collection and broader coverage of journals, languages and mathematical periods.
The benchmark corpus can also grow with the archive. More representative papers will make it possible to compare models across different scan quality, notation styles and source languages rather than optimising for a small set of convenient examples.
Most importantly, the community around the papers can grow. The value of ArXRev will not be measured only by how many scans pass through an AI pipeline. It will be measured by how many historical arguments become readable, searchable, citable and trustworthy again.
Final Thoughts
ArXRev combines modern vision models, a resilient serverless pipeline and a focused editorial interface, but its purpose is rooted in preservation.
Historical mathematics should not remain locked inside scanned pages simply because reconstructing it is slow and specialised work. AI can remove much of that initial friction. Human reviewers can provide the judgement that accuracy demands. Together, they make it possible to build an open, living archive rather than a folder of PDFs.
ArXRev is currently available by invitation.