Archival Digitization Workflow: A Stage-by-Stage Guide

An archival digitization workflow runs in nine gated stages, from selection through access, and each stage constrains the next. This guide walks them in order for cultural heritage professionals planning against real materials, real standards, and real costs, so a decision made early does not surface as a permanent defect later.

An archival digitization workflow is a gated sequence: selection and planning, preparation and handling, image capture, quality control, image processing, metadata and description, text recognition, storage and preservation, and finally access and publication. Each stage constrains the next. Capture cannot recover what preparation damaged, and text recognition cannot read what capture failed to resolve. The most common mistake is treating scanning as the whole job. Scanning produces image files; digitization produces described, preserved, discoverable records. This guide walks the full pipeline and points out where the gates actually bind.

Most of the failures I see in the field trace back to a decision made two stages earlier and never revisited. So it is worth understanding the workflow as a chain of dependencies rather than a checklist. This piece sits within our broader work on archives, digitization, and metadata workflows, and it aims to give a working professional something to plan against.

Stage 1: Selection and planning

Before an object reaches a scanner, someone has decided it is worth digitizing and to what standard. This is where you commit to a target. The target governs cost, equipment, and schedule for everything that follows.

Two imaging standards dominate cultural-heritage practice. In North America, the FADGI Technical Guidelines define a four-star system, where 4-star is the strictest tier — roughly 600 ppi for reflective text, 16 bits per channel, an ICC-managed color workflow, verified against physical targets. In Europe, the Metamorfoze Preservation Imaging Guidelines define three levels — Full, Light, and Extra Light — around a single governing principle: all visible information in the original must be visible in the master.

Institution size tends to sort against these tiers. National libraries and large archives run FADGI 4-star or Metamorfoze Full programs with formal QA and dedicated infrastructure. Mid-size repositories often target 3-star or Light and rely on vendor processing. Small historical societies frequently default to 2-star or vendor-conformant capture, managing metadata in AtoM or Omeka S and delegating preservation to a regional consortium.

Be honest about cost at this stage, because the published figures will not settle it for you. University capture rates run around $1.00 per image for 300 ppi grayscale and $2.00 for 600 ppi color at one public digitization center; vendor page scanning sits in the $0.05–$0.25 range. There is no peer-reviewed, cross-institutional cost benchmark with comparable methodology — the numbers you find are project-specific or vendor-quoted. Plan against your own pilot, not someone else's rate sheet. The line items a budget has to carry are broken out in what a records digitization project actually costs.

Stage 2: Preparation and handling

Preparation is conservation work, not clerical work. Fragile bindings, tight gutters, brittle paper, and light-sensitive media each dictate how — and whether — an item can be captured. This stage sets the physical constraints capture must respect, and getting it wrong is the one failure the entire workflow cannot undo.

Stage 3: Image capture

Capture hardware follows the material. Book and planetary scanners (ATIZ, Bookeye, Indus) handle bound volumes where opening angle is constrained. Copy-stand DSLR or mirrorless rigs with macro lenses handle oversize and special-collections material. Flatbeds remain standard for loose paper at small scale, and sheet-fed production scanners drive high-volume backfile conversion.

Whatever the rig, the discipline is the same: capture software writes to raw TIFF in checksum-stamped ingest directories, and you image your targets at the start and end of each session. A color target such as an X-Rite ColorChecker or a Golden Thread target verifies color accuracy; a resolution target verifies MTF and sampling efficiency. Those target images are your evidence that the session met its tier. Without them, QC has nothing to measure against. For the resolution decision itself, what DPI to scan old documents works through the trade-offs by material.

If you are running batch scanning — hundreds or thousands of items through the same station — the workflow is the same at every scale. Batch material by format and condition before it reaches the scanner, so one capture setting suits the whole batch. Keep a batch manifest: item identifiers, image counts, operator, and the target images for that session. Write each batch's masters to its own checksum-stamped ingest folder, and pass the batch through QC before the next one starts, while the originals are still out. A batch that fails is reshot as a batch rather than discovered piecemeal months later.

Stage 4: Quality control

FADGI and Metamorfoze both require inspection of a defined sample against pass/fail gates, typically expressed as a percentage or an AQL formula. The quantitative checks are specific: modulation transfer function from slanted-edge targets, color accuracy against chart-based ΔE, tonal response, noise, geometric distortion, and visual completeness. FADGI provides OpenDice and AutoSFR for MTF measurement.

The tolerances are concrete. Metamorfoze v2.0 sets white-balance ΔE at or below 3 for Full and Light, and color accuracy at a mean ΔE of 3 or less (max 7) for Full. QC is the gate before publication for a reason: a color cast or a soft focus caught here is a reshoot; caught after the master is archived and the original reshelved, it is a permanent defect in the record.

Stage 5: Image processing

Processing derives from the master, never the reverse. This is the deliberate split at the center of a sound workflow: the master file is uncompressed or lossless — TIFF 6.0 or lossless JP2, 16 bits per channel, color-managed — and every access derivative (JPEG, lossy JP2, PDF/A) is produced from it. Deskew, cropping, and color correction happen on copies. The master stays untouched.

The format trade-offs are qualitative, not settled by a single benchmark. Uncompressed TIFF is lossless, universally supported, and large — a 600 ppi 24-bit scan of a letter-size page can exceed 100 MB. Lossless JPEG2000 offers comparable fidelity at roughly 20–40% smaller files, with more implementation complexity. PDF/A bundles text and image and is ISO-standardized for long-term preservation. FADGI and Metamorfoze both accept TIFF and lossless JP2 as masters; the choice is yours to defend.

Stage 6: Metadata and description

No single metadata standard covers everything, and the belief that one does is a reliable source of stalled projects. Metadata is layered because it answers different questions, and the layers are usually bundled in a wrapper such as METS. How the layers apply once a document has been transcribed is mapped in archival metadata standards for transcriptions.

Descriptive — what is it? Dublin Core (a 15-element core), MODS (richer bibliographic), EAD3 (hierarchical finding aids), and DACS or ISAD(G) as content rules.
Structural — how do the parts fit? METS as the wrapper, ALTO XML for OCR layout and text per region, PAGE XML for richer page-level zones.
Technical — what is the file? MIX, EXIF, capture-device logs.
Preservation — what happened to it, and under what rights? The PREMIS Data Dictionary v3, organized around Objects, Events, Rights, Agents, and now Intellectual Entities.

Larger institutions typically combine ArchivesSpace for finding aids with a DAM such as Preservica or Rosetta for digital objects. Smaller ones lean on AtoM as a single system or Omeka S for cultural-object collections. A researcher's tool like Tropy organizes photographs taken on an archival visit — useful, but not an institutional repository, and it does not describe to these standards.

Stage 7: Text recognition

Here the workflow turns an image into something you can search, and here the assumptions that carried you through capture quietly stop holding. Two distinct technologies live under this stage, and conflating them causes real damage.

OCR (optical character recognition) classifies glyph patches against learned representations, assuming consistent, clean glyph shapes. On clean modern print, top engines — Tesseract LSTM, ABBYY FineReader, Google Cloud Vision — reach character error rates around 1–2%. That is genuinely strong, and if your collection is modern typescript, conventional OCR is the right and cheap answer.

HTR (handwritten text recognition) uses sequence models trained on ground truth, and the unit of training is the hand, not the corpus. That distinction matters more than any marketing figure. Our fuller treatment of the difference between HTR and OCR is worth reading if your collection mixes the two, as most do.

Two things break the naive plan. First, historical print is not modern print: the long s read as f, ligatures split or dropped, blackletter and Antiqua on the same page, ink bleed-through and scanning noise read as character evidence. On 19th-century newspapers, general OCR degrades into the 8–20% CER range depending on engine and condition — a far cry from the 1–2% on clean modern text. Second, handwriting is largely unusable to conventional OCR without model training, and specialist HTR platforms are not plug-and-play: text you can read and quote from needs a CER of about 2% or below (at 10%, roughly every second word contains an error), and reaching numbers like that on a given hand typically means transcribing 15–30 accurate pages per hand as a training minimum, with diminishing returns past 50–100 pages and weak cross-hand generalization. For a collection with many scribal hands, that training cost is not marginal. It is the project.

There is a further trap, and it is the quiet one. Reaching for a general chatbot to read a manuscript feels efficient, and the large general models have improved quickly: on a clean, legible page they can read well, and a 2025 benchmark found generalist models competitive with specialist systems on some corpora in zero-shot, though none reliably surpassed a well-trained specialist on the hardest scripts. The mechanism is worth naming: a general model is trained to produce fluent text, so its errors are fluent too. It tends to quietly modernise spelling — a more probable form in place of the one on the page — and given an unfamiliar or noisy image it can produce plausible, well-formed prose that is not what the page says. OCR errs on characters, which you can catch. A general model errs plausibly, which reads perfectly and is wrong. For an archive whose entire value is fidelity to the source, that is the failure mode to design against.

Where a specialist model fits without a training project

This is the stage where an archive's plan most often stalls, and it is the stage Leo is built for. Leo's transcription model, ATR-1, reads Latin-script material — handwritten or printed — from roughly the past five centuries, in whatever language the Latin alphabet was used to write it: English wills, French notarial records, Dutch registers, German parish books, and Latin among them, not only Latin. It runs zero-shot, out of the box, with no per-hand training set to build first. For a collection of mixed hands, that removes the 15-to-30-pages-per-hand tax that makes specialist HTR a project in its own right.

The design commitment that matters at this stage is source integrity. ATR-1 is tuned for historical documents and trained to transcribe what is on the page rather than smooth it into modern, plausible prose: it does not over-correct or silently modernise. It preserves strikethroughs, marginal additions, editorial expansions, and archaic orthography — the long s stays a long s, u/v and i/j interchange survives, an abbreviation mark is not silently resolved. Why that matters for everything downstream is argued in historical language normalization. It reads the image at high resolution, where general models downsample, and it checks its own output: a result that looks like a failure is hidden, retried, and refunded if the image cannot be read. The errors that do get through are the recoverable kind — a wrong letter you check against the image beside the text, not a fluent sentence the page never contained. The same approach applies to print: a model trained on images of historical documents weighs visual evidence against context instead of matching glyphs to a modern type model.

Around the model sits a workflow: upload (including straight from a phone camera in the reading room), transcribe, edit in a rich-text editor that keeps the original image beside the transcription, organize into folders, search with adjustable fuzzy matching, record structured metadata, and export to Word, PDF, HTML, or TEI XML. Transcription runs from one model menu: ATR-1 is the default, and the major OpenAI, Google Gemini and Anthropic Claude models sit alongside it, so you can run a second reading of a hard page into its own tab and compare, or send clean, legible print — a typescript, a nineteenth-century book — to a small model that reads it for a fraction of a credit. Transformations can translate, summarize, or extract named entities — each writing to a new tab so the base transcription stays untouched. Where Leo does not go is equally worth stating plainly: it begins at upload, not capture, and it does not produce IIIF, OAIS packages, or EAD/METS/PREMIS — TEI XML is its scholarly export. It sits after capture and before your preservation and access infrastructure, and the corrections users make in the app feed back into training, so accuracy improves across releases.

For material eligible under an open license, academics and archives can apply for a Leo Transcription Grant of free credits; for printed-matter projects, which the grant does not cover, the free tier or a paid plan is the route in.

Stage 8: Storage and preservation

Digitization is not a one-time project, and this is the stage that proves it. The OAIS reference model (ISO 14721:2025) frames the archive's obligation as six mandatory responsibilities and three information packages — the SIP you ingest, the AIP you preserve, the DIP you disseminate. Underneath that sit continuous operational commitments: fixity checking with checksums, redundancy on a 3-2-1 or geographic pattern, format watch and migration, and storage refresh. The NDSA Levels of Digital Preservation give a graduated maturity framework to measure yourself against. Production systems that implement the OAIS model include Preservica, Rosetta, Archivematica, RODA, and the Internet Archive's stack.

Stage 9: Access and publication

The final stage makes the work usable, and here IIIF — the International Image Interoperability Framework — has become the de facto interoperability layer. Its open APIs let institutions serve high-resolution image tiles and structured digital objects, with viewers such as Mirador and the Universal Viewer rendering them for deep zoom, annotation, and cross-institution comparison. The IIIF Consortium, formed in 2015, counts around 71 member institutions as of 2025 — though membership counts what institutions have joined, not what share of the world's holdings is actually exposed through IIIF endpoints, which remains uncounted.

Working the chain, not the checklist

The discipline in all of this is remembering that the stages are gated, not parallel. A metadata schema chosen after capture forces rework; a QC standard set too loosely surfaces as a defect no derivative can repair; a text-recognition plan that assumes clean type meets a collection of secretary hands and stops dead. The strongest workflows are the ones where each stage is designed knowing what the next one needs — and where the person planning capture has already read a sample of the actual hands, seen the actual foxing, and priced the actual transcription. Digitization rewards that kind of looking ahead more than almost any craft I know.

Frequently Asked Questions

What are the stages of an archival digitization workflow?

An archival digitization workflow is a gated sequence of nine stages: selection and planning, preparation and handling, image capture, quality control, image processing, metadata and description, text recognition, storage and preservation, and access and publication. Each stage constrains the next — capture cannot recover what preparation damaged, and text recognition cannot read what capture failed to resolve. The common mistake is treating scanning as the whole job. Scanning produces image files; digitization produces described, preserved, discoverable records. Design each stage knowing what the next one needs, because a decision made early can surface as a permanent defect later.

What is the difference between FADGI and Metamorfoze imaging standards?

FADGI and Metamorfoze are the two imaging standards that dominate cultural-heritage practice. FADGI, used in North America, defines a four-star system where 4-star is the strictest tier — roughly 600 ppi for reflective text, 16 bits per channel, an ICC-managed color workflow, verified against physical targets. Metamorfoze, used in Europe, defines three levels — Full, Light, and Extra Light — around a single governing principle: all visible information in the original must be visible in the master. Both require inspection of a defined sample against pass/fail gates and both accept TIFF and lossless JP2 as master formats.

What is the difference between OCR and HTR?

OCR (optical character recognition) classifies glyph patches against learned representations, assuming consistent, clean glyph shapes; on clean modern print, top engines reach character error rates around 1–2%. HTR (handwritten text recognition) uses sequence models trained on ground truth, and the unit of training is the hand, not the corpus. Handwriting is largely unusable to conventional OCR without model training. Specialist HTR platforms are not plug-and-play either: reaching usable accuracy on a given hand typically means transcribing 15–30 accurate pages per hand as a training minimum, with weak cross-hand generalization. For collections with many scribal hands, that training cost is the project.

Why is using a general AI chatbot to transcribe manuscripts risky?

General chatbots are a trap in text recognition because of how they fail, not because they cannot read. The large general models have improved quickly and can do well on a clean, legible page, but they are trained to produce fluent text: they tend to quietly modernise spelling, and given an unfamiliar or noisy image they can produce well-formed prose that is not what the page says. OCR errs on characters, which you can catch; a general model errs plausibly, which reads perfectly and is wrong. A 2025 benchmark found generalist models competitive on some corpora in zero-shot, but none reliably surpassed a well-trained specialist on the hardest scripts. For an archive whose value is fidelity to the source, that is the failure mode to design against.

Why should the master file never be edited during image processing?

The master file should never be edited because processing must derive from the master, never the reverse — this is the deliberate split at the center of a sound workflow. The master is uncompressed or lossless (TIFF 6.0 or lossless JP2, 16 bits per channel, color-managed), and every access derivative such as JPEG, lossy JP2, or PDF/A is produced from it. Deskew, cropping, and color correction happen on copies while the master stays untouched. This protects the archival record: a defect introduced by editing a master cannot be undone once the original is reshelved, so keeping it pristine preserves the option to regenerate derivatives later.