Badger Scribe: Transcribing 19th-Century Handwritten Archives on a Single GPU

Projects
ML Marathon
MLM26
OCR
Computer vision
NLP
Multilingual
Text analysis
LLM
GenAI
Deep learning
Authors

Chris Endemann

Scott Prater

Kevin Chovanec

Published

September 16, 2026

Badger Scribe is a challenge in the 2026 Machine Learning Marathon (MLM26), organized with the UW Digital Collections Center at UW–Madison Libraries. Institutional archives hold vast collections of handwritten documents that remain difficult to access at scale: without text, these materials can’t be searched, can’t be read by screen readers, and can’t be studied. Teams build pipelines that faithfully transcribe archival document images into machine-readable text, using only open-weight models on a single GPU, so that libraries and archives can actually deploy what comes out of the challenge. The evaluation data is built entirely from UW Digital Collections materials: nineteenth-century surveyors’ field notes, German immigrant correspondence in Kurrent script, and craftsmen’s account books.

This is an educational, collaborative challenge with no cash prizes. The point is to surface and share transcription pipelines: share repos early, post findings to the Discussion tab, and build on each other’s approaches.

Challenge design

  • Task: Given a document image (a single page or scan), produce a faithful, verbatim transcription in natural reading order, with original spelling and punctuation preserved and no summarizing or cleanup.
  • Data: A small, curated, rights-cleared sample from three UW Digital Collections: Max Kade Institute German letters (1932–1942, Kurrent script), Dominy craftsmen account books (1810s–1840s), and Wisconsin Land Survey field notes (1830s–1860s). Split into a released train set and a hidden test set, both of which may grow through the fall as human review of the English collections completes. Each labeled row records whether its label is human-verified or an unreviewed machine draft (silver_claude), which matters when fine-tuning.
  • Constraints: The submitted pipeline must run end-to-end on a single GPU with at most 96 GB of VRAM using open-weight models only. No closed-weight APIs (GPT, Claude, Gemini) anywhere in the submitted run. Training, fine-tuning, and other preparation compute are unconstrained.
  • Evaluation: Character Error Rate (CER), macro-averaged across document categories, so a pipeline must perform across handwriting styles, layouts, and languages rather than acing one clean category. Characters the human transcriber could not resolve are marked # and never count against you.
  • Verification and writeup: A complete submission pairs leaderboard predictions with a writeup (WRITEUP.md) in a public repo pinned to the exact commit that produced the score. Organizers re-run the pipeline to confirm it reproduces the predictions, fits the VRAM budget, and uses only open-weight models.

Approaches

There is no consensus on what the pipeline should look like. A traditional OCR pipeline (layout detection → line segmentation → recognition), an assembly of open-source tools such as Kraken and PyLaia, a small vision-language model prompted page-by-page, or any of these fine-tuned on a curated sample are all viable, and they behave very differently across handwriting styles, languages, and layouts. Fine-tuning on the released train set is encouraged; the challenge’s RESOURCES.md maps public labeled datasets (Bentham, IAM, the Alfred Escher German correspondence, and more) to the UW collections. Starter notebooks covering each solution family are planned for release once vetted.

Comments