generated media archive policy: own retention after collecting generation outputs

A generated media archive policy begins by distinguishing a source URL from an archived object. A successful job can point to a file you can collect now, but that pointer does not establish a permanent retention promise for your application. Save the media you need in storage you control and record how long each class of asset should remain there.

Genace provides job outputs and metadata. It does not define your organization’s archive lifecycle, backup process, publication retention, or storage deletion policy. Those decisions belong to your application and operational owners.

Classify what you need to retain

Separate raw collected outputs, approved masters, working derivatives, published exports, and review evidence. They may have different operational value and different retention choices. Record those choices explicitly instead of keeping everything forever because no one knows what can be removed.

Name an owner for the policy and an owner for retrieval failures. This is an operational workflow, not legal advice or a claim that one retention duration suits every organization.

Create an archive manifest

Field	Why it matters	Verification
Source job and output index	Preserves generation provenance	Matches saved snapshot
Collected file digest	Identifies exact bytes	Recomputed after storage
Storage object reference	Locates the archive	Read succeeds
Asset class	Selects lifecycle rule	Approved classification
Retention decision	Explains planned handling	Owner and policy version
Publication references	Prevents accidental breakage	Active usages remain mapped

Do not store API keys or signed source URL query strings in public archive indexes. Keep sensitive collection details in appropriately protected records.

Verify collection before relying on it

Download the complete output, inspect the media, and compute a digest. Upload to your archive, then verify that the stored object can be retrieved and matches the expected bytes. Mark the collection complete only after those checks pass.

A backup plan needs its own verification. Periodically restore a small representative sample into an isolated staging location and inspect it. The existence of a backup setting is not evidence that a particular asset can be recovered.

Keep derivative recipes with the master. If a delivery file is lost but the approved master and recipe remain available, the application may be able to recreate the export without another generation request.

Make retirement reference-aware

Before expiring an object, check active publication and derivative relationships. Removing a raw candidate may be acceptable under your policy, but deleting a master still needed by published crops can break future recovery.

Record the retirement decision and outcome. If a stored object is removed, retain enough non-sensitive provenance to understand which files depended on it and why it was retired, according to your chosen policy.

Do not infer a provider URL’s expiration time unless your actual provider agreement documents it. Collect required media promptly and treat later source availability as something to verify, not an archive strategy.

Acceptance checklist

Retrieve a master, verify its digest, rebuild one derivative from its recipe, and inspect an active publication mapping. Test a retirement decision against a referenced object and confirm it is handled deliberately. Document who responds when retrieval or integrity checks fail.

Continue with output storage, asset lineage, and content-hash caching.

Continue with media delivery

• accessible AI image descriptions: describe the selected image according to its role
• image content hash cache: identify immutable media from collected bytes
• image file size budget: measure exports against the job each placement performs
• Browse all media delivery guides