Match every output to its receiving role.
ENG-024_0007.tifDefine the cloud destination and control owner
The customer identifies the provider, account or subscription, destination bucket/container, region or environment where applicable, permitted identity, and administrator who controls access. We document the folder or object-key convention, source and derivative formats, content type, encryption and retention rules controlled by the customer, and the required checksum or file-count reconciliation method.
A cloud location is not assumed to be a document-management import. The project specifies whether files are simply staged for a downstream process, organized for user retrieval, or accompanied by a separate metadata package. This makes the handoff understandable to the storage owner and to any later repository workflow.
Use sidecars alongside provider-specific metadata
Amazon S3 distinguishes user-defined metadata, object tags, and annotations, while Azure Blob Storage distinguishes user-defined metadata from index tags and notes that tags are natively searchable. Those differences matter when deciding where a document type, date, record ID, or retention-related value should live. The customer’s provider configuration determines the permitted object properties and tags.
For portability and reconciliation, every delivery includes a neutral metadata sidecar or manifest that lists the stable record ID, relative key, MIME type, checksum, OCR status, and agreed descriptive fields. It remains useful even when selected values are also applied as cloud object metadata or tags.
- Bucket/container and path or key convention approved by the storage owner
- Object content type and allowed metadata/tag fields documented
- Manifest links files, OCR output, metadata, counts, and checksums
Test the handoff and reconcile the release
A controlled test confirms destination access, expected paths, object naming, file readability, content type, and the customer-approved metadata or tag behavior. National Microfilm compares the manifest with the delivered object list and reports exceptions. The customer administrator controls storage policies, lifecycle or retention settings, encryption, and permission changes in the cloud environment.
Illustrative cloud delivery map
Actual property and tag names depend on the selected provider and customer configuration. This example separates portable manifest fields from object-level mapping decisions.
| Prepared field | Example value | Cloud delivery use |
|---|---|---|
| object_key | records/1954/NM-000001.pdf | Approved bucket/container path |
| record_id | NM-000001 | Manifest key / permitted metadata |
| content_type | application/pdf | Object MIME declaration |
| document_type | Correspondence | Approved metadata or tag candidate |
| checksum_sha256 | 9f86d081… | Reconciliation manifest value |
Common questions
Can you deliver to Amazon S3 or Azure Blob Storage?
We can prepare a customer-approved cloud handoff to the designated storage location, with agreed paths, file types, metadata approach, manifest, and test process. Provider access and storage controls are administered by the customer.
Should metadata be stored on the object or in a sidecar?
That depends on the provider’s capabilities and the customer’s retrieval needs. A neutral sidecar remains useful for portability, transformation, and reconciliation even when selected values are also stored with the object.
Sources & further reading
These references explain technical formats, standards or destination requirements. They do not imply endorsement of National Microfilm.