Digital Asset Specifications

1. Purpose

This appendix defines baseline digital asset specifications for outsourced digitization of image-based collection materials. It is intended to support project-specific scopes of work (SOWs) and may be incorporated into any applicable vendor digitization agreements or contracts.

These specifications establish expected deliverables for several broad material categories:

• Reflective textual and graphic materials
• Reflective photographic materials
• Transmissive photographic materials, including film negatives, transparencies, slides, and glass plates
• Microform materials, including 16mm and 35mm roll microfilm, microfiche, and aperture cards
• Associated metadata, OCR, manifests, checksums, and quality control documentation.

Project-specific scopes may supplement or modify these requirements, but deviations must be approved in writing by the Library before production begins.

2. General Principles

2.1 Preservation and Access Deliverables

The Library may request multiple deliverable types for each project. These should be clearly distinguished by role.

Not every project will require every role. Each project-specific scope should identify required deliverables.

2.2 No Silent Substitution

The vendor shall not substitute file formats, compression methods, color profiles, bit depths, resolutions, OCR formats, naming conventions, metadata fields, or delivery structures without prior written approval from the Library.

2.3 Accurate Source-Sized Resolution

When resolution is specified in pixels per inch, the PPI shall be measured relative to the physical dimensions of the original source object, not the dimensions of a derivative file or resized output. Image files must include accurate resolution metadata in the appropriate TIFF or image header fields.

2.4 FADGI Conformance

Where applicable, digitization should be performed according to the FADGI Technical Guidelines for Digitizing Cultural Heritage Materials, using the appropriate object category, star level, targets, and conformance evaluation tools for the source material.

Unless otherwise specified:

• General textual and manuscript materials should meet FADGI 3-Star requirements at minimum.
• Rare, special, photographic, fine-detail, and high-value materials should meet FADGI 4-Star requirements where feasible.
• Transmissive materials should use appropriate transmissive targets and evaluation methods.
• Vendor documentation should identify the FADGI category and star level targeted for each project.

2.5 Targets and Calibration

The vendor shall utilize appropriate technical targets, calibration procedures, and process-control documentation for each material type to ensure FADGI compliance.

2.5.1 Reflective Materials (Object-Level Targets)

For reflective textual, graphic, and photographic print materials (Sections 3 and 4), the vendor shall utilize appropriate Image Science Associates (ISA) GoldenThread targets (such as the ISA Object Target or Device Target, as appropriate for the material size).

Preservation (U-Files): Targets must be captured inline with the source material as object-level target-bearing images. The target must be positioned within the frame so that it is fully visible, un-obscured, and flat, without overlapping any portion of the source collection item.

Production / Service (S-Files): The target must be digitally cropped out of the final delivered image. The crop must completely exclude the target while retaining a slight, uniform, and visible border of the capture background around the physical edges of the collection object. Overly tight cropping, flush cropping, or any crop that cuts into the physical boundary of the object is strictly prohibited.

2.5.2 Transmissive Materials (Batch/Session Calibration)

For transmissive materials (Section 5), technical calibration targets must be captured at the start of each production session or batch to establish, verify, and document equipment profiles.

Transmissive targets shall be included in the final delivery as separate, uncropped target images.

Targets must not be embedded within or captured inline with the source collection object images, unless an exception is explicitly requested and authorized in the project-specific SOW

3. Reflective Textual, Manuscript, Bound Volume, and Graphic Materials

3.1 Included Materials

This category includes:

• Bound volumes
• Rare books
• Manuscripts
• Loose paper
• Archival folders
• Correspondence
• Ledgers
• Scrapbooks
• Maps, posters, broadsides, and other graphic works, unless treated as oversized special projects
• Mixed paper-based collections.

Photographic prints may be handled under this category for routine access projects, but preservation-quality photographic print digitization should follow the photographic reflective specifications in Section 4.

3.2 Recommended Baseline Specifications

3.3 Handling of Bound Volumes

Unless explicitly authorized by the Library, bound volumes must be digitized non-destructively. The vendor shall use appropriate cradles, supports, lighting, and capture methods to avoid damage to bindings, pages, covers, inserts, and foldouts.

Project-specific instructions should define capture requirements for:

• Front cover
• Back cover
• Spine
• Endpapers
• Blank pages
• Foldouts
• Inserts
• Tipped-in items
• Page edges
• Bookplates
• Ownership marks
• Barcodes or labels.

4. Reflective Photographic Prints

4.1 Included Materials

This category includes:

• Black-and-white photographic prints
• Color photographic prints
• Mounted photographs
• Cabinet cards
• Cartes de visite
• Annotated prints
• Photographs with significant versos, mounts, stamps, captions, or enclosures.

4.2 Recommended Baseline Specifications

4.3 Versos, Mounts, and Enclosures

Project-specific instructions must state whether the vendor should capture:

• Versos
• Captions
• Stamps
• Annotations
• Mounts
• Sleeves
• Enclosures
• Folder labels
• Item labels
• Barcodes.

When versos or associated enclosures are captured, the file naming convention must clearly distinguish front, back, mount, sleeve, enclosure, or label images.

5. Transmissive Photographic Materials: Film, Slides, Transparencies, and Glass

5.1 Included Materials

This category covers transmissive media, divided into two operational tracks based on whether the original source image is a negative or a native positive:

Negative Materials Track: Black-and-white negatives, color negatives, sheet film negatives, roll film negatives, nitrate negatives, acetate negatives, and glass plate negatives.

Positive Materials Track: Color transparencies, mounted slides (Kodachrome, Ektachrome, etc.), lantern slides, and glass transparencies.

5.2 Preservation and Derivative Concept

To preserve both the physical reality of a transmissive artifact and its human-readable interpretation, different asset counts and processing approaches are required depending on whether the original source media is a negative or a native positive:

For Negative Materials (Film & Glass): The vendor must maintain parallel production tracks, delivering six (6) files total per physical item: two preservation, two service (one negative, one positive), and two access JPEGs (one negative, one positive). The two mandatory preservation files are defined as follows:

Negative Preservation Master (U-File): A faithful, raw, un-inverted capture of the source negative as a negative image. For color negatives, the integral film base and orange mask must remain fully intact. The primary purpose of this file is to retain the absolute, objective physical and informational content of the film base.

Positive Preservation Master: A high-fidelity, digitally inverted positive image derived directly from the raw capture. This master must be tonally adjusted and optimized for visual interpretation, preserving maximum tonal information across the histogram while strictly avoiding highlight or shadow clipping, excessive contrast compression, or data loss.

For Positive Materials (Slides & Transparencies): Because these items are natively positive, no inversion or dual-tracking is required. The vendor shall deliver three (3) files total per physical item: one preservation (U-File), one production/service (S-File), and one web display/access JPEG. The preservation master represents a faithful, raw capture of the positive transparency or slide without any undocumented tonal adjustments.

5.3 Black-and-White Film Negatives (6-File Dual Track)

5.4 Color Film Negatives (6-File Dual Track)

5.5 Color Transparencies and Mounted Slides (3-File Single Track)

This section applies to natively positive film transmissive materials (e.g., Kodachrome, Ektachrome, slides).

5.6 Glass Plate Negatives and Glass Transparencies

Glass materials require specialized handling and will be mapped to the file structures established above via individual project SOWs:

Glass Plate Negatives: Shall follow the six (6) file dual-track role structure, inversion logic, and bit-depth specifications outlined for film negatives in Section 5.3 (Grayscale) or Section 5.4 (Color).

Glass Transparencies and Lantern Slides: Shall follow the three (3) file single-track role structure outlined for positive transmissive materials in Section 5.5.

5.6.1 Technical Modifications for Glass Substrates

Regardless of the file track utilized, all glass-based materials must adhere to the following baseline modifications:

Resolution: Sampling frequency shall be defined in the project SOW relative to the physical dimensions of the glass plate (typically a minimum of 400 to 600 PPI natively), without digital interpolation.

Cropping: For Preservation file (U-Files), the entire physical glass plate must be fully visible. The vendor must retain all physical edges, corners, emulsion damage, glass cracks, silver mirroring, and historical labels or markings.

Color Mode: If a black-and-white glass negative exhibits severe chemical deterioration, silver mirroring, or hand-coloring, the Library may mandate an RGB color capture in the SOW to preserve these physical attributes.

5.7 Glass and Fragile Transmissive Handling Requirements

The vendor shall use handling and capture methods appropriate for fragile glass and transmissive photographic materials. Requirements may include:

• Low-heat or cold illumination
• Minimal exposure time
• Appropriate custom supports for cracked or structurally compromised glass
• No direct physical pressure placed on emulsion surfaces (e.g., placing glass plates emulsion-side up on a low-iron, anti-reflective lower glass shelf)
• Meticulous handling of flaking or lifting emulsions
• Procedures for broken or cracked plates
• Immediate reporting of unstable or unsafe items
• Project-specific approval before attempting capture of damaged items.

Specific equipment may be proposed by the vendor, but the Scope of Work should describe the required outcome rather than requiring a named lighting system unless the Library has a specific technical reason to mandate it.

5.8 Inversion and Tonal Adjustment Requirements

For negative-to-positive conversions, the vendor shall provide a fully documented, repeatable inversion workflow. Positive files must be visually optimized for immediate display while retaining full tonal representation across the histogram.

The vendor shall avoid:

• Clipping highlights or shadows
• Excessive contrast expansion
• Unnatural tonal compression
• Automated correction that obscures source characteristics
• Removal of historically or physically meaningful marks
• Inconsistent positive rendering across a batch.

The Library may require approval of a pilot batch before production begins, especially for negative inversion and glass plate projects.

6. Microform Materials

6.1 Included Materials

This category includes:

• 16mm roll microfilm
• 35mm roll microfilm
• Positive microfilm
• Negative microfilm
• Silver gelatin, diazo, and vesicular film
• Microfiche
• Aperture cards
• Microfilm containing newspapers, books, manuscripts, records, drawings, or other source documents.

6.2 General Approach

Microform materials are already surrogates of original documents. The primary goal is usually legibility, completeness, accurate sequencing, and support for OCR and access. However, preservation files should still be created in a stable, well-documented format with sufficient tonal information to support future derivative creation.

When a single physical microform item contains multiple distinct intellectual units, the vendor may separate those units into approved subdirectories for navigation and downstream processing. This intellectual segmentation must not interrupt or reset the physical frame sequence. Frame numbering shall remain continuous across the complete barcode-level object, from the first captured frame through the last.

6.3 Recommended Baseline Specifications

6.4 Reduction Ratio and Source-Sized PPI

When PPI is specified relative to original page size, the vendor shall document the method used to determine or estimate reduction ratio. If the reduction ratio is unknown, the vendor shall document assumptions and notify the Library if the source material cannot reasonably meet the required effective resolution.

6.5 Microfilm OCR

For OCR projects, the vendor shall provide project-specific OCR deliverables. Searchable PDF alone should not be the only OCR deliverable unless explicitly approved.

Possible OCR deliverables include:

• Searchable PDF
• Plain text
• ALTO XML
• hOCR
• METS/ALTO packages
• OCR confidence reports
• Exception reports for unreadable frames or pages.

The vendor shall identify source conditions likely to limit OCR quality, such as poor exposure, skew, density variation, bleed-through, blurred frames, damaged film, handwritten text, unusual typography, mixed languages, or complex layouts.

6.6 Aperture Cards and Technical Drawings

Aperture cards and microforms containing technical drawings, maps, or oversized originals may require higher effective resolution, special cropping, or delivery structures. Project-specific scopes should define these requirements separately.

7. File Naming and Directory Structure

7.1 General Naming Variations

All files delivered under this agreement shall follow a consistent, underscore-delimited naming convention based on the Library-issued 14-digit barcode identifier (pattern: 33433\d{9}). Filenames shall use one of the following two structures:

1. Standard Workflow (Reflective Materials, Slides, Transparencies, and Microform):
   [barcode]_[side-or-sequence]_[role].[extension]

2. Dual-Track Negative Workflow (Film and Glass Negatives Only):
   [barcode]_[component]_[side-or-sequence]_[role].[extension]

Multi-unit intellectual segmentation does not create a separate filename pattern. When a single physical item contains multiple distinct intellectual units, files shall retain the applicable standard filename and shall be organized into unit subdirectories within the barcode-level bag, as described in Section 7.5.

Zero-Padding: All page, frame, and asset sequences must be zero-padded to a strict five-digit (5) width (e.g., 00001). Unit directory identifiers must be zero-padded to a strict three-digit (3) width (e.g., u001).

7.1.1 Multi-Unit Organization and Absolute Physical Sequence

A unit represents a distinct intellectual work or content grouping identified within one physical barcode-level object. Unit divisions are organizational and descriptive; they do not create new physical objects, new barcode identifiers, or separate BagIt packages.

For multi-unit items:

• The barcode-level bag remains the sole delivery package for the physical item.
• Unit subdirectories shall be named u001, u002, and so forth, in the order in which the units first appear on the physical carrier.
• Unit identifiers shall appear in directory paths and metadata, but not in asset filenames.
• The physical frame sequence shall begin at 00001 and continue without resetting at unit boundaries.
• All preservation, service, access, OCR, and sidecar files derived from the same physical frame shall use the same absolute sequence number.
• Sequence numbers must not be duplicated across unit directories. Any intentional gap caused by an omitted, unreadable, or uncaptured frame must be documented in the applicable exception report.

For example, if u001 contains physical frames 1–980 and u002 contains physical frames 981–1650, the final frame in u001 shall use sequence 00980, and the first frame in u002 shall use sequence 00981. If the TIFF files are later gathered from all unit directories and sorted by filename, they will retain the original physical order of the complete item.

7.2 Naming Elements, Components, and Role Codes

7.3 Mandatory Sidecar Metadata Requirements

The vendor shall deliver file-level metadata utilizing individual, matching JSON sidecar files for every primary digital asset produced. Standing or bulk metadata files delivered in lieu of individual sidecars do not satisfy this requirement.

Strict 1:1 Asset Pairing: Every single image, document, or derivative file delivered—including all preservation masters, service masters, access files, and OCR files—must be accompanied by exactly one corresponding JSON file. Combining or nesting metadata for multiple files into a single master JSON array or bulk manifest is strictly prohibited under this requirement.

Exact Character Matching: The filename of the JSON sidecar must match the base filename of its paired asset character-for-character, shifting only the file extension to lowercase .json. For example, [filename]_pres.tif must be paired with [filename]_pres.json, and [filename]_access.jpg must be paired with [filename]_access.json. Any case mismatches, truncation, or spacing discrepancies between the asset file and its sidecar file will result in mandatory batch rework.

Directory Co-location: Each JSON sidecar file must reside in the exact same payload directory as its paired asset. For standard items, this will normally be the bag’s data/ directory. For multi-unit items, both the asset and its sidecar must reside together in the applicable unit subdirectory, such as data/u001/ or data/u002/.

Data Ingestion and Schema Compliance: The internal structural formatting, required fields, and data values populated within each individual JSON sidecar file must strictly adhere to the external metadata workflow and schema validation rules outlined in Section 8.

7.4 Delivery Examples

Scenario A: Standard Reflective Photo Print with Front and Back (No Component Code)

Barcode ID: 33433123456789

• Front (Recto) Preservation Master & Sidecar: 33433123456789_r_pres.tif and 33433123456789_r_pres.json
• Front (Recto) Access JPEG & Sidecar: 33433123456789_r_access.jpg and 33433123456789_r_access.json
• Back (Verso) Preservation Master & Sidecar: 33433123456789_v_pres.tif and 33433123456789_v_pres.json

Scenario B: Complex Dual-Track Transmissive Negative (Component Required)

Barcode ID: 33433987654321

• Raw Negative Preservation Master & Sidecar: 33433987654321_negative_00001_pres.tif and 33433987654321_negative_00001_pres.json
• Inverted Positive Preservation Master & Sidecar: 33433987654321_positive_00001_pres.tif and 33433987654321_positive_00001_pres.json

Scenario C: Microfilm Reel Containing Multiple Distinct Intellectual Units

Barcode ID: 33433555554444
Physical structure: Pamphlet 1 occupies frames 1–980; Pamphlet 2 occupies frames 981–1650.

• Pamphlet 1, first frame: data/u001/33433555554444_00001_serv.tif and data/u001/33433555554444_00001_serv.json
• Pamphlet 1, final frame: data/u001/33433555554444_00980_serv.tif and data/u001/33433555554444_00980_serv.json
• Pamphlet 2, first frame: data/u002/33433555554444_00981_serv.tif and data/u002/33433555554444_00981_serv.json
• Pamphlet 2, final frame: data/u002/33433555554444_01650_serv.tif and data/u002/33433555554444_01650_serv.json

The unit directory changes at the intellectual boundary, but the filename sequence remains continuous across the complete physical reel. Corresponding preservation, access, OCR, and JSON sidecar files shall use the same absolute frame number and reside in the same unit directory as the service file.

7.5 Directory Structure: BagIt Packaging Rules

One Bag per Barcode: Each unique physical barcode identifier shall be delivered as one independent, self-contained, BagIt-compliant directory named exactly by its barcode (for example, 33433987654321/). A barcode-level object must not be divided into multiple bags solely because it contains multiple intellectual units.

Multi-Unit Payload Organization: When a barcode-level object contains distinct intellectual units, the units shall be represented as subdirectories beneath the single bag’s data/ directory. Unit directories shall be named u001, u002, and so forth, in the order in which the units first appear on the physical carrier. Descriptive titles shall be recorded in metadata rather than embedded in directory names.

Single Manifest Coverage: The root bag’s manifest-md5.txt must include every payload file in every unit directory using its full relative payload path (for example, data/u002/33433555554444_00981_pres.tif). Unit directories must not contain separate bagit.txt, bag-info.txt, or manifest files.

Absolute Sequence Across Units: Sequential filenames shall represent the physical order of the complete barcode-level object. Sequence numbering must continue across unit boundaries and must never restart at 00001 for a later unit.

Example 1: Basic Reflective Directory Layout (Photo Print with Front and Back)

33433123456789/                                  <-- Root folder named by barcode
├── bagit.txt                                    <-- BagIt declaration
├── manifest-md5.txt                             <-- Checksums for all files beneath /data
├── bag-info.txt                                 <-- Bag administrative metadata
└── data/                                        <-- Payload directory
    ├── 33433123456789_r_pres.tif                <-- Front/recto preservation master
    ├── 33433123456789_r_pres.json               <-- Matching sidecar JSON
    ├── 33433123456789_r_serv.tif                <-- Front/recto service master
    ├── 33433123456789_r_serv.json               <-- Matching sidecar JSON
    ├── 33433123456789_r_access.jpg              <-- Front/recto access image
    ├── 33433123456789_r_access.json             <-- Matching sidecar JSON
    ├── 33433123456789_v_pres.tif                <-- Back/verso preservation master
    ├── 33433123456789_v_pres.json               <-- Matching sidecar JSON
    ├── 33433123456789_v_serv.tif                <-- Back/verso service master
    ├── 33433123456789_v_serv.json               <-- Matching sidecar JSON
    ├── 33433123456789_v_access.jpg              <-- Back/verso access image
    └── 33433123456789_v_access.json             <-- Matching sidecar JSON

Example 2: Complex Dual-Track Negative Directory Layout (Frame 1 of Roll)

33433987654321/                                  <-- Root folder named by barcode
├── bagit.txt                                    <-- BagIt declaration
├── manifest-md5.txt                             <-- Checksums for all files beneath /data
├── bag-info.txt                                 <-- Bag administrative metadata
└── data/                                        <-- Payload directory
    ├── 33433987654321_negative_00001_pres.tif   <-- Raw negative preservation master
    ├── 33433987654321_negative_00001_pres.json  <-- Matching sidecar JSON
    ├── 33433987654321_positive_00001_pres.tif   <-- Inverted positive preservation master
    ├── 33433987654321_positive_00001_pres.json  <-- Matching sidecar JSON
    ├── 33433987654321_negative_00001_serv.tif   <-- Raw negative service master
    ├── 33433987654321_negative_00001_serv.json  <-- Matching sidecar JSON
    ├── 33433987654321_positive_00001_serv.tif   <-- Inverted positive service master
    ├── 33433987654321_positive_00001_serv.json  <-- Matching sidecar JSON
    ├── 33433987654321_negative_00001_access.jpg <-- Raw negative access image
    ├── 33433987654321_negative_00001_access.json <-- Matching sidecar JSON
    ├── 33433987654321_positive_00001_access.jpg <-- Inverted positive access image
    └── 33433987654321_positive_00001_access.json <-- Matching sidecar JSON

Example 3: Multi-Unit Microfilm Directory Layout (Two Pamphlets on One Reel)

In this example, u001 contains frames 00001–00980, and u002 contains frames 00981–01650. The ellipses indicate additional files following the same naming and sidecar-pairing rules.

33433555554444/                                  <-- One root bag for the complete physical reel
├── bagit.txt                                    <-- BagIt declaration
├── manifest-md5.txt                             <-- Checksums for files in both unit directories
├── bag-info.txt                                 <-- Bag administrative metadata
└── data/                                        <-- Payload directory
    ├── u001/                                    <-- First intellectual unit: Pamphlet 1
    │   ├── 33433555554444_00001_pres.tif        <-- Physical frame 1 preservation master
    │   ├── 33433555554444_00001_pres.json       <-- Matching sidecar JSON
    │   ├── 33433555554444_00001_serv.tif        <-- Physical frame 1 service master
    │   ├── 33433555554444_00001_serv.json       <-- Matching sidecar JSON
    │   ├── 33433555554444_00001_access.pdf      <-- Physical frame 1 access file
    │   ├── 33433555554444_00001_access.json     <-- Matching sidecar JSON
    │   ├── 33433555554444_00001_ocr.xml         <-- Physical frame 1 coordinate OCR
    │   ├── 33433555554444_00001_ocr.json        <-- Matching OCR sidecar JSON
    │   ├── ...
    │   ├── 33433555554444_00980_pres.tif        <-- Final physical frame in u001
    │   └── 33433555554444_00980_pres.json       <-- Matching sidecar JSON
    └── u002/                                    <-- Second intellectual unit: Pamphlet 2
        ├── 33433555554444_00981_pres.tif        <-- Sequence continues; it does not reset
        ├── 33433555554444_00981_pres.json       <-- Matching sidecar JSON
        ├── 33433555554444_00981_serv.tif        <-- Physical frame 981 service master
        ├── 33433555554444_00981_serv.json       <-- Matching sidecar JSON
        ├── 33433555554444_00981_access.pdf      <-- Physical frame 981 access file
        ├── 33433555554444_00981_access.json     <-- Matching sidecar JSON
        ├── 33433555554444_00981_ocr.xml         <-- Physical frame 981 coordinate OCR
        ├── 33433555554444_00981_ocr.json        <-- Matching OCR sidecar JSON
        ├── ...
        ├── 33433555554444_01650_pres.tif        <-- Final physical frame on the reel
        └── 33433555554444_01650_pres.json       <-- Matching sidecar JSON

8. Embedded Metadata and External Metadata

8.1 General Approach

The Library utilizes a multi-tiered metadata strategy to maintain digital object lineage. Technical and administrative metadata are captured at two distinct levels: minimal metadata embedded directly within file headers, and robust, file-level external metadata delivered via the JSON sidecar files specified in Section 7.3. External metadata files serve as the primary descriptive and validation mechanism for repository ingestion.

8.2 Embedded Metadata Requirements

The vendor shall embed baseline technical and administrative metadata directly into the headers of all TIFF and derivative files where supported by the file format. Embedded metadata fields must be populated programmatically during capture and processing, and may include:

• Unique identifier / Barcode
• File title or document name
• Library/institution name and credit line
• Copyright or rights statement (if supplied by the Library)
• Source collection name (if supplied by the Library)
• Capture date and timestamp
• Digitization vendor name
• Capture hardware metrics (Camera/scanner make, model, and lens information)
• Capture software name and version number
• Resolution (Sampling frequency) and bit depth
• Assigned color space profile (ICC Profile)
• Image pixel dimensions and orientation
• Standard technical EXIF, XMP, IPTC, and TIFF header fields

8.3 Checksums and Fixity

Cryptographic checksums used for file fixity validation must be delivered via the external BagIt manifests (manifest-md5.txt) as outlined in Section 7.5, rather than embedded as the primary fixity mechanism inside image headers or duplicated inside item sidecars. The mandatory algorithm for all project delivery manifests is MD5.

8.4 External Metadata Workflow and JSON Schema Validation

To generate the mandatory 1:1 file-level JSON sidecars required by Section 7.4, the vendor shall execute a three-phase metadata aggregation and synthesis workflow:

Phase 1: Library-Supplied Source Baseline

Prior to production or upon shipment delivery, the Library will provide the vendor with a standardized project inventory spreadsheet in XLSX format (as specified in the Inventory Spreadsheet Specification). This file acts as the authoritative intake data source for the project and provides item-level baseline data, including:

• Administrative Tracking: schema_version and project_code
• Primary Identifiers: Library barcode (barcode matching ^33433\d{9}$), division_code, bnumber, classmark, aspace_component_id, collection_id, and item_title
• Physical Object Classification: Controlled vocabulary pairings for object_type and object_format, alongside any physical_condition_notes observed at selection
• Known Multi-Unit Structure: When identified before capture, unit_index and unit_title for distinct intellectual units contained within a single physical barcode-level object (for example, multiple pamphlets on one microfilm reel). Unit boundaries discovered or refined during capture must be recorded by the vendor as part of the production metadata.

Phase 2: Vendor-Generated JSON Synthesis

The vendor must programmatically extract the item-level fields from the Library’s intake spreadsheet and map them into their corresponding schema objects (administrative, identifiers, source). The vendor’s processing scripts must then synthesize this baseline data with file-level operational metadata captured dynamically during production to generate individual 1:1 JSON sidecar files.

Per the JSON Sidecar Schema Specification, the capture-specific properties the vendor must inject into each sidecar include:

• Asset Metadata (asset): The exact referenceFilename (strictly validated against the project naming regex pattern) and the designated fileRole (pres, serv, access, or ocr).
• Sequential Capture and Unit Tracking (source.sequence): The integer sequenceNumber (for example, 24, rendered as 00024 in the filename), the applicable unitIndex, the two-sided object side indicator (r for recto, v for verso), and a human-readable sequenceLabel depicting physical reality (for example, "Recto", "Page 42", or "Front Cover"). For sequential multi-unit items, sequenceNumber must represent the absolute physical sequence across the complete barcode-level object and must not reset when unitIndex changes.
• Digitization Process Audit (digitizationProcess): Granular hardware and software audit trails, including captureDevice (manufacturer, model, lens, serialNumber), captureSoftware (manufacturer, productName, version), and the specific optical calibrationTarget utilized during the capture session.
• Operator & Organization Tracking (digitizer): Vendor administrative data, including operator (firstName, lastName) and organization (name).

(Note: To maintain separation of concerns, file sizes, pixel dimensions, and ICC profiles remain embedded within image headers per Section 8.2, while MD5 cryptographic checksums remain strictly within external BagIt manifests per Section 8.3. Unit membership is represented by the data/u###/ payload path and the corresponding unit metadata; it is not encoded in the asset filename.)

Phase 3: Schema Validation

The final structural composition, key-value pairings, nesting logic, and required fields of the delivered JSON sidecars must strictly validate against the formal JSON Schema specification provided by the Library.

Schema Provision: The authoritative, live JSON Schema file (digitized_image_schema.json) is maintained and published by the Library at the following canonical endpoint:

• Canonical Schema URI ($id): https://nypl-research.github.io/digital-imaging-resources/schemas/digitized_image_schema.json

Mandatory 100% Pre-Delivery Validation: The vendor shall implement automated command-line schema validation (using industry-standard tools such as ajv-cli or Python’s jsonschema) as part of their 100% Quality Control pipeline (Section 9.1). Every single delivered JSON sidecar file must pass validation against the Library-supplied schema without error. Any files containing malformed JSON syntax, invalid data types, unmapped properties (additionalProperties: false), regex filename mismatches, or structural non-compliance will result in the immediate rejection of the entire delivery batch.

9. Quality Control Requirements

9.1 Vendor 100% QC

The vendor shall perform quality control before delivery. Unless otherwise specified, vendor QC shall include 100% review or automated validation for:

• File presence
• File naming
• One barcode-level bag per physical item
• Directory structure and approved u### unit assignments, where applicable
• Sidecar co-location with each paired asset
• Sequence completeness
• Continuous absolute sequence numbering across all unit directories, with no resets or duplicates
• Checksum creation
• File format validation
• ICC profile presence and correctness
• Bit depth
• Color mode
• Resolution metadata
• Pixel dimensions
• Corrupt or unreadable files
• Manifest completeness
• OCR deliverable presence, if applicable.

9.2 Vendor Visual QC

The vendor shall visually review files for issues including:

• Blurred focus
• Motion blur
• Incorrect exposure
• Clipped highlights or shadows
• Color imbalance
• Newton’s rings
• Dust or debris
• Reflections or glare
• Cropped text or image content
• Incorrect orientation
• Excessive skew
• Moiré or scanner artifacts
• Missing pages, frames, or sides
• Incorrect negative inversion
• Inconsistent tonal rendering
• Visible handling damage or newly discovered condition issues.

Unless a 100% manual visual review is explicitly funded in an SOW, the vendor shall conduct a manual visual inspection on a statistically valid random sample (minimum 10%) of each batch.

9.3 Technical Validation Tools

The vendor shall use appropriate validation and analysis tools, which may include:

• JHOVE for file format validation and characterization
• ExifTool for embedded metadata review
• OpenDICE, AutoSFR, GoldenThread, or equivalent tools for image quality conformance testing
• Checksum tools capable of generating MD5 manifests
• OCR validation or confidence reporting tools, where applicable.

9.4 Library Pilot Review

Before mass production, the Library may review a pilot batch. The pilot batch should be representative of the full project and may include:

• 25–50 images, or another agreed sample size
• Multiple formats and conditions
• Fronts/backs or rectos/versos
• Negative and positive versions for transmissive materials
• OCR output, if applicable
• Metadata records
• File manifests
• Checksum manifests
• QC reports
• Target images.

The Library may use the pilot to approve:

• Image quality
• Cropping
• Orientation
• Naming
• Directory structure
• Multi-unit boundaries, unit directory assignments, and absolute sequence continuity, where applicable
• Metadata structure
• Negative inversion look and tonal handling
• OCR package structure
• QC reporting format.

Full production shall not begin until the Library approves the pilot batch, unless the Library waives this requirement in writing.

9.5 Acceptance and Rework

Deliverables are not accepted until the Library completes its review and confirms that files, metadata, OCR, and documentation meet project requirements.

The vendor shall correct vendor-responsible errors at no additional cost. Rework may be required for:

• Missing files
• Incorrect file names
• Incorrect sequence, including duplicate numbers, gaps without approved exception documentation, or sequence resets at unit boundaries
• Incorrect unit directory assignment or delivery of separate bags for units belonging to one physical barcode-level object
• Sidecar files placed outside the directory containing their paired assets
• Incorrect or missing checksums
• Corrupt files
• Incorrect bit depth, color profile, or file format
• Poor focus
• Cropped content
• Unauthorized image processing
• Clipped tonal values
• Incorrect negative inversion
• Incomplete metadata
• Incorrect OCR package structure
• Incomplete or inaccurate manifests
• Failure to follow approved specifications.