Match every output to its receiving role.
ENG-024_0007.tifA delivery package has distinct parts
An import-ready package usually contains three independently understandable components: document or image files, an agreed metadata map, and a manifest or sidecar that relates the two. A file naming rule, hierarchy or folder map, format declaration, exception convention, and reconciliation information can make the package easier to validate and transfer.
The neutral package is not a claim that every destination directly accepts CSV, XML, or JSON. Those forms can be transformed into the customer-approved import-index file, migration task, API payload, repository template, or cloud-object metadata model after the target rules are understood.
| Component | Purpose |
|---|---|
| Image or document files | The digitized visual record and any requested access derivative |
| Metadata map | Agreed fields, types, values, and source-to-target rules |
| Manifest or sidecar | File paths, identifiers, relationships, and delivery status |
| Reconciliation | Counts, exceptions, and agreed release checks |
Start with a customer-approved data dictionary
A data dictionary identifies source field, normalized field, target field, data type, allowed values, date format, repeatability, required status, and transformation rule. It also identifies the stable record identifier that connects the content file, metadata, OCR, and source-media reference. This protects meaning when a local source label does not match a repository field name.
Fictional example — no PII: a record ID such as `ENG-000142` can connect `drawings/ENG-000142.tif` with drawing number, revision, source card ID, and OCR status. The target system may require those values in named properties, a CSV import index, or a configured batch rather than in the filename itself.
Repository and cloud examples need discovery
SharePoint, Laserfiche, OnBase, OpenText, DocuWare, M-Files, IBM FileNet, Amazon S3, and Azure Blob Storage each have their own data model, permissions, file restrictions, and import options. For example, SharePoint migration tasks require defined source and destination information, while OnBase import configurations use Document Types and Keyword Types. A platform name is not sufficient technical scope.
Discovery identifies the destination library, vault, folder, object store, or file cabinet; the owner of access; required fields and controlled values; source and derivative formats; target workflow; test data; and acceptance criteria. Customer administrators retain the role appropriate to their configured environment.
Test the agreed path before production release
A representative test batch gives the project team a way to compare files and metadata with the selected workflow. The review can confirm record identifiers, required fields, date and value formatting, file association, hierarchy, and treatment of exceptions. It does not substitute for the customer’s authority over the destination environment.
National Microfilm prepares delivery requirements around the approved workflow; we do not claim automatic universal import or a native connector for every platform. Discuss the repository, version, fields, access owner, and desired outputs so the final package can be scoped to the actual destination.
Common questions
Do all repositories import the same CSV or JSON file?
No. CSV, XML, and JSON are useful neutral representations, but every repository or migration tool has its own required schema and configuration.
What is a metadata sidecar?
It is a separate structured record that identifies a content file and its metadata, making the package easier to map to a destination workflow.
Why use a test batch?
It validates the approved field map and file relationships against the selected workflow before a broader delivery is released.
Sources & further reading
These references explain technical formats, standards or destination requirements. They do not imply endorsement of National Microfilm.