How to Write HTR Into a Data Rescue Grant Proposal: Deliverables, Validation, and Cost Lines That Survive Review

How to draft HTR into data rescue grant proposals through observation-counted deliverables, fail-able validation plans, and costed pipeline lines that survive review.

Leo Team

August 6, 2026

How to Write HTR Into a Data Rescue Grant Proposal: Deliverables, Validation, and Cost Lines That Survive Review
Contents

This is a drafting guide for the sections of a data rescue grant proposal where machine transcription is load-bearing: the deliverables list, the validation plan, the budget, and the methods paragraph that names a tool. It matters because reviewers do not fund transcription capability — they fund countable validated observations, a stated accuracy target, and a costed pipeline that still holds together after the grant closes.

A data rescue grant proposal does not win because it says "AI transcription." It wins when the deliverable is counted in validated observations rather than pages, when the accuracy claim is stated precisely enough that it could be shown to be wrong, and when the budget carries every line the pipeline actually consumes — ground truth, human review, adjudication, value QC, provenance, and stewardship after the grant ends. Handwritten text recognition (HTR) belongs in the methods section as a costed, evaluated instrument with a named model version and a pilot behind it. Written that way, it strengthens a proposal. Written as a capability claim, it invites a reviewer to ask what happens to a misread digit.

The sections below work through the parts of a proposal where machine transcription is either load-bearing or fatal.

What reviewers are actually reading for

Start from the published requirements rather than from a sense of what funders like.

NOAA's Climate Program Office asks for methodology, success metrics and evaluation, and a data management plan and sharing plan naming data types, sharing date, standards, access method and volume, alongside short- and long-term outcomes. NOAA also notes it may make funded DMPs publicly visible, so write yours to be read. NSF's Directorate for Geosciences requires a Data Management and Sharing Plan committing public data and metadata to appropriate long-lived, FAIR-aligned repositories, and NSF policy is explicit that the DMSP is reviewed as an integral part of the proposal, considered under Intellectual Merit or Broader Impacts. Horizon Europe requires a maintained DMP and FAIR, "as open as possible, as closed as necessary" data, with research data management in line with FAIR part of the expert evaluation briefing. NERC wants an outline DMP identifying datasets of long-term value for its data centres, with a full plan three to six months after award.

Note what is not there: no funder scorecard specifies a character error rate you must hit. The C3S Data Rescue Service defines data rescue as discovery, preservation, quality control, digitisation and consolidation, and supplies a registry and an exchange format — but it is not a grant-review rubric. There is no universal accuracy target to cite. That absence is your responsibility, not your excuse: you set the target, justify it, and say how you will measure it. The broader shape of the pipeline this sits inside is covered in Leo's work on historical climate and scientific data rescue, and the seven-stage view in climate data rescue is a useful map when you are deciding which stages this grant actually buys.

Define the deliverable in observations, not pages

Pages imaged is an input. Observations ingested into a climate database is an outcome. Reviewers who have funded transcription before know the difference, because they have seen projects deliver images and call it data.

State four numbers, stage-gated:

  • Pages imaged (or already imaged, if capture is out of scope).
  • Images machine-transcribed, with model and version named.
  • Observations released in a named format, in a named repository, under a named licence.
  • Validated observations that pass your QC and are accepted by the destination database.

Then name the format precisely. For fixed land stations, the Station Exchange Format (SEF, version 1.0.0) is a UTF-8 tab-separated file holding one variable from one station: headers ID, Name, Lat, Lon, Alt, Source, Link, Vbl, Stat, Units and Meta; observation columns Year, Month, Day, Hour, Minute, Period, Value and Meta. Two things follow that proposals routinely miss. SEF's Source, Link and Meta fields are provenance hooks, not an audit log — if your only provenance is a Source string, say where the rest lives. And SEF is a land-station format: marine logbook observations need their own stated destination and structure, which you should name rather than leave implied.

A deliverable sentence that survives review reads something like: "12,400 register pages transcribed with [model, version]; ~410,000 observations released as SEF 1.0.0 files with per-observation links to page images, deposited in [repository] under [licence] with a DataCite DOI; of these, ~390,000 pass value QC and are submitted to [database]." Every number is checkable at the end of the grant.

Write a validation plan that can fail

This is where most proposals thin out into the word "verified." Separate the two layers explicitly, because they answer different questions.

Layer one: transcription validation

Does the output match the image? This compares machine text against an image-linked human reference held out from any training or tuning, sampled deliberately across writer, station, period, language, layout, image quality, and extreme values. Double-keying — two independent transcriptions, compared, with a stated adjudication rule — is the standard process control. The clinical literature on double data entry reports single-entry error rates from 4 to 650 errors per 10,000 fields against double-entry rates of 4 to 33, which is a useful process analogue and not a prediction about handwriting. Volunteer consensus is related but is not the same measurement: it tells you how much transcribers agreed, not how far the accepted value sits from the page.

Layer two: climate-value QC

Range and format checks, temporal and internal consistency, cross-variable relationships, neighbouring-station buddy checks, comparison against independent products or reanalysis. Say plainly what this layer can and cannot do: it flags implausible values, it cannot prove a digit is faithful to the page, and it will sometimes flag a genuine extreme. Extremes are exactly where a transcription error and a real observation are hardest to separate, so budget expert review of flagged extremes as its own activity.

Metrics

CER is edit distance — substitutions plus deletions plus insertions over reference characters — and WER applies the same calculation to tokenised words. Both are well documented, from Transkribus's CER explainer to the HTR survey literature. They measure string disagreement, not whether an observation is scientifically right. For dense tables, add digit error rate, numeric-token exact match, field exact match, and complete-record exact match, stratified by variable and by risk. No universal funder-mandated digit-error definition exists, so define yours in the proposal: how you treat punctuation, leading zeroes, decimal points, blanks, missing values and units. Why CER alone misleads is worked through in what AI transcription accuracy actually measures.

Sample size

Choose n from a stated confidence level and margin of error, or from a precision target, using binomial, Wilson or exact methods, since normal approximations weaken when errors are rare. NIST's guidance on sample sizes for proportions is a defensible citation. If the observed error count is zero or near-zero, report a confidence interval or an upper bound. Never write "100% accurate."

The anatomy of a claim

A defensible accuracy statement names the material and date range, the language and layout, sample size and sampling design, tool and model version, evaluation date, how the reference was created, the metric denominator, and the disagreement-reconciliation rule. Anything shorter is a marketing sentence, whether it comes from a vendor or from you. The practical method for producing one is set out in how to verify transcription accuracy.

Cite the machine evidence honestly, including its limits

Reviewers who know this literature know it is small. Use that.

The strongest task-specific published results are cautionary. Zhang's workflow for automating historical weather data rescue combined preprocessing, EAST box detection, Tesseract v5, digit retraining and reconstruction, and still reported 47.3–63.0% CER and 83.6–88.1% WER on dense registers, with 53% overall OCR accuracy — on 350 annotated observations, without a digit-level metric. MeteoSaver v1.0 integrates preprocessing, cell detection, OCR/HTR, QA/QC and upload formatting, and reports median 74% manual-match accuracy after QA/QC across a ten-sheet test in the DRC, without claiming generalisation. There is no like-for-like benchmark comparing specialist HTR, general OCR and table APIs, and human transcription on the same climate pages, and no defensible general accuracy figure for dense multilingual Latin-script tabular handwriting.

Cite these as the baseline your methods section improves on, and let them justify a funded pilot on your material as a line item rather than a favour someone does in spare time. A day of structured testing on your own registers — random sample, keyed reference, scored per variable — is worth more to a reviewer than any vendor figure. The procedure is in how to test an AI transcription tool on your own manuscripts.

Do the same for the crowdsourcing side, which remains genuinely strong where layouts are unusual and human interpretation matters. Rainfall Rescue covered 1677–1960 across more than 66,000 scanned sheets and 5.28 million unique handwritten monthly observations, with over 16,000 citizen scientists transcribing in March–April 2020; release v1.1.0 holds 3.34 million observations in 8,549 series for 6,093 locations, and the five-year project report notes the records were transcribed within sixteen days. The peer-reviewed paper reports no image-level accuracy percentage or formal error rate. Weather Rescue at Sea shows the more mature pattern: multiple volunteers per page, consensus checks before acceptance, confidence flags and explicit handling of unresolved values. If you are proposing machine transcription in place of volunteers, say what you gain — throughput independent of volunteer availability — and what you give up — parallel human judgement on hard cells — and design the hybrid accordingly.

Cost lines that survive review

Budget the pipeline, not the inference. Give each of these its own line, even where the number is small:

imaging and capture · image preparation · ground-truth creation and adjudication · machine transcription (credits or compute) · human review of low-confidence and high-impact numeric fields · double-keying and disagreement resolution · climate-value QC and extreme review · provenance capture · storage, repository deposit and DOI · project management · contingency · post-grant stewardship.

Two cautions. First, no climate-specific machine-HTR cost per page or per 1,000 observations exists in the literature. Published digitisation costs vary by year, currency, imaging standard, wage model, volunteer incentives, QC depth and whether curation and storage are included — one journal digitisation cost analysis reports an average $4.12 per item at the high end of comparable studies, and an early Mechanical Turk transcription experiment put a 72-page diary at under $25. Cite such figures as scoped precedents, never as your unit rate. Build your own from the pilot. The full line-item logic, including the recurring costs that outlast the grant, is laid out in what a records digitization project actually costs.

Second, review labour scales with error rate, which makes tool choice a budget variable rather than a preference. Model two scenarios at different error rates and show the reviewer how the review line moves. And if the tool you name requires you to train or fine-tune a recognition model first, that is a labelled-data line item and a schedule risk on the critical path — a real consideration weighed in the no-training alternative to eScriptorium. If you are procuring transcription rather than doing it in-house, the same discipline applies to your requirements language; testable accuracy clauses are the contract version of this section.

Naming a transcription engine in the methods section

Whatever you name, specify: model and version, script scope, published evaluation and its scope, where output lands, how a reviewer sees image and text together, and what exports the audit trail.

Leo is worth naming at this stage for reasons that map onto the lines above. Its engine, ATR-1, is zero-shot — there is no per-corpus model training, which removes a labelled-data cost line and a schedule dependency from the Gantt chart. It reads Latin-script material, handwritten and printed, whatever the language on the page: English station registers, French, Dutch, German and Spanish observatory ledgers alike. For numeric work the relevant point is source integrity — Leo is built to transcribe what is on the page rather than normalise it, and a value the model does not "improve" toward plausibility is a value your QC layer can still catch. Output sits beside the page image for review, with tables and layout preserved, and exports to TEI XML, Word, PDF or HTML for the provenance chain. A failure-detection mechanism hides suspect output, retries it, and refunds the credit if it cannot succeed, which is a checkable safeguard rather than an accuracy promise. Transcription is not translation: Translate is a separate Transformation writing to a new tab, leaving the base text intact. Credits are counted per image, and there is a transcription grant of up to 100,000 credits for academics and archives, conditioned on publishing images and transcriptions openly within 24 months — so apply with material you hold or can clear the rights to publish.

State its limits in the proposal too, because a reviewer will find them otherwise. Leo's published benchmark is early-modern English manuscript prose from the Folger Shakespeare Library, not tabular climate registers. Complex tabular layouts vary in quality, and the known weak spot is pages where dominant pre-printed structure competes with dense handwritten entries — which describes a great many station registers. Converting transcribed tables into SEF is your step, not the tool's. Pilot on your own sheets, report what you find, and let the numbers do the arguing.

Provenance and sustainability, in the words funders use

Close the data sections on the audit trail. FAIR asks for persistent identifiers, rich metadata, retrieval protocols, standard vocabularies, licences and detailed provenance; W3C PROV gives you the vocabulary of entities, activities and agents to express it. An acceptable trail links image or cell region → raw machine output → normalization → reviewer or second key → disagreement and adjudication → QC → released version, with versions and a DOI at the end. Name the repository and its steward, the access and licence policy, the data and model versions, the correction process, the maintenance resources, and how the next batch reuses the same workflow. Where your transcriptions travel onward into catalogues or discovery systems, the layered view in archival metadata standards for transcribed documents keeps you from overloading one schema.

A proposal like this is finally a promise about a single digit: that when a 29.8 reaches a reanalysis, someone can trace it back to the millimetre of ink it came from, and show the reasoning that accepted it. Reviewers fund people who can describe how they would know they were wrong. Write the validation plan you would want to be held to, cost the review labour honestly, and the transcription method — machine, volunteer, or both — becomes the least contentious part of the document.

Frequently Asked Questions

How do you write HTR into a data rescue grant proposal?

Write handwritten text recognition into a data rescue grant proposal as a costed, evaluated instrument rather than a capability claim. That means four things: deliverables counted in validated observations released to a named repository, format and licence; a validation plan separating transcription accuracy from climate-value QC, with a stated accuracy target you justify and measure; a budget with its own line for ground truth, human review, adjudication, extreme review, provenance and post-grant stewardship; and a methods paragraph naming the tool, model and version, plus a funded pilot on your own material. Reviewers fund countable outcomes and stated methods, not "AI transcription."

What deliverables should a data rescue grant proposal promise?

Promise observations, not pages. Pages imaged is an input; observations ingested into a climate database is an outcome. State four stage-gated numbers: pages imaged, images machine-transcribed with model and version named, observations released in a named format, repository and licence, and validated observations that pass your QC and are accepted by the destination database. Name the format precisely — the Station Exchange Format (SEF) 1.0.0 is a tab-separated file holding one variable from one station, and it is a land-station format, so marine logbook observations need their own stated destination and structure.

What accuracy target should I use for transcribing handwritten climate registers?

There is no universal target to cite. No funder scorecard specifies a character error rate, and the C3S Data Rescue Service defines the stages of data rescue without acting as a grant-review rubric. So you set the target, justify it against the material, and say how you will measure it. A defensible claim names the material and date range, language and layout, sample size and sampling design, tool and model version, evaluation date, how the reference was created, the metric denominator, and the rule for reconciling disagreement. Choose sample size from a stated confidence level and margin of error, and never write "100% accurate."

What cost lines belong in a transcription budget for a data rescue project?

Budget the pipeline, not the inference. Give separate lines to imaging and capture, image preparation, ground-truth creation and adjudication, machine transcription, human review of low-confidence and high-impact numeric fields, double-keying and disagreement resolution, climate-value QC and expert review of flagged extremes, provenance capture, storage and repository deposit with a DOI, project management, contingency, and post-grant stewardship. No climate-specific machine-HTR cost per page exists in the literature, and published digitisation costs vary by year, currency, imaging standard, wage model and QC depth — treat them as scoped precedents and build your unit rate from a pilot.

Should a data rescue project use machine transcription or volunteer crowdsourcing?

Both work, and the choice should be stated as a trade-off rather than a preference. Crowdsourcing remains strong where layouts are unusual and human interpretation matters — Rainfall Rescue produced millions of unique handwritten monthly observations from more than 66,000 sheets with over 16,000 volunteers, and Weather Rescue at Sea shows the mature pattern of multiple transcribers per page, consensus checks and confidence flags. Machine transcription gives you throughput independent of volunteer availability but gives up parallel human judgement on hard cells. If you propose machines in place of volunteers, say what you gain and lose, and design the hybrid accordingly.

Share this article

© 2026 Leo Technologies Limited. All rights reserved