Building an Archival Digitization Workflow: A Stage-by-Stage Guide

This is a working guide to the archival digitization workflow — the full sequence from selection through access, and where each stage constrains the next. It is written for cultural heritage professionals who need to plan a program against real materials, real standards, and real costs, not a rate sheet. The aim is to help you design a chain of dependencies that holds, 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.

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.

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.

• 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: Transkribus guidance places usable searchable text in the 5–10% CER band and publication-ready below roughly 5%, but reaching those numbers 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 dangerous one. Reaching for a general chatbot to read a manuscript feels efficient, and a 2025 benchmark did find generalist models competitive with specialist systems on some corpora in zero-shot — but the same study, evaluated on a single set of corpora and still requiring human verification, found no generalist model reliably surpassed a well-trained specialist on the hardest scripts, with documented fabrication on degraded input. The mechanism is worth naming: a large language model is trained to produce fluent text, so given an unfamiliar or noisy image it will generate plausible, well-formed prose that is not what the page says. OCR errs on characters, which you can catch. An LLM errs with fluent fabrication, 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 transcribes what is on the page rather than smoothing it into modern, plausible prose. 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. On a randomized 97-image sample of early-modern English manuscripts from the Folger Shakespeare Library, at ATR-1's release it recorded roughly a 5% character error rate — 61% fewer errors than the next-best model tested (Transkribus/Text Titan I at about 13%, and general LLMs considerably higher), per the published benchmark. That is a manuscript figure; it is not a claim about printed material, where the argument is mechanical rather than numerical — 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. A separate AI layer 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?

Using a general chatbot to read a manuscript is the dangerous trap in text recognition because of how these models fail. A large language model is trained to produce fluent text, so given an unfamiliar or noisy image it generates plausible, well-formed prose that is not what the page says. OCR errs on characters, which you can catch; an LLM errs with fluent fabrication, which reads perfectly and is wrong. A 2025 benchmark found generalist models competitive on some corpora in zero-shot, but no generalist model reliably surpassed a well-trained specialist on the hardest scripts, with documented fabrication on degraded input. 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.