Reprocessing Assets

Reprocessing can be triggered for a single asset or an entire S3 folder prefix. The reprocess request supports selective processor overrides so you can re-run only specific processors without a full pipeline restart.

Reprocess Request Format

{
  "completeReprocess": true,
  "recreateAssetManifest": true,
  "bucketName": "demo3-system-content-5gnaxglcv1us",
  "prefix": "content/shawn2/avengers",
  "forceReprocess": {
    "AudioExtraction": true,
    "ComprehendEntities": true,
    "ComprehendKeyPhrases": true,
    "RekognitionImageDetectText": true,
    "RekognitionImageCelebrityRecognition": true,
    "RekognitionImageIndexFaces": true,
    "RekognitionImageUnsafeContent": true,
    "RekognitionImageLabels": false,
    "MediaInfo": false,
    "ImageInfo": false,
    "Screenshot": true,
    "Textract": true,
    "Transcribe": true,
    "TranscribeMedical": true
  }
}

Behavior of forceReprocess

When any forceReprocess flag is set to true:

1. The screenshot, segment, and asset manifest files are deleted and will be recreated.
2. The triggered processors are added to processes.json in metadata-archive.
3. The jobs.json file in metadata-content has its date updated for those processors.

Smart Reprocess Behavior

By default, reprocessing is additive — the system detects which outputs already exist for each asset and only generates the missing ones. Processors that have already run successfully are skipped.

This makes it safe to trigger a reprocess on a folder at any time without worrying about duplicating work or overwriting existing outputs. Common use cases:

• Adding a new processor to an existing folder — enable a new AI processor in the config, then reprocess the folder; only the new outputs are generated
• Applying a new proxy type to existing content — add a new MediaConvert profile, reprocess; existing proxies are untouched
• Recovering from a partial failure — if processing stopped mid-way for some assets, reprocessing adds the missing outputs for those assets only

To force a processor to re-run even when output already exists, set its flag to true in the forceReprocess map (see above).

Asset Move Behavior and Proxy Inheritance

When an asset is moved between folders using Nomad Media's built-in move operation, all existing proxies, renditions, and AI-generated outputs travel with the asset — they are not deleted or regenerated.

Once the asset lands in its new folder, the rules engine evaluates the destination folder's rules and adds any additional outputs that are now required by the new location's configuration. Outputs that already exist are never duplicated.

This behavior enables powerful folder-based publishing workflows. For example:

• A work-in-progress/ folder may have no proxy or AI rules configured
• Moving a finished asset to published/ automatically triggers generation of the HLS streaming rendition, all AI enrichment, and the thumbnail variants defined for that folder — without re-running any processing that already happened

Important: The Nomad Media move operation must be used (via the UI or API) for this behavior to apply. Moving files directly in S3 (outside Nomad) does not trigger rule evaluation or maintain proxy associations.

Lambda Test Harness Format

When using the Lambda test harness directly, wrap the payload in an SQS Records envelope:

{
  "Records": [
    {
      "body": "{\"forceReprocess\": {\"Screenshot\": true}, \"recreateAssetManifest\": true, \"bucketName\": \"demo3-system-content\", \"prefix\": \"content/shawn/transcode.mp4\"}",
      "awsRegion": "us-east-2"
    }
  ]
}