Materialize expiring outputs before handoff

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Generated audio is needed next month, but the service supplies a temporary signed URL. Teaching authorization permits local reports/audio/briefing.wav, not another upload. Expiring access differs from retained bytes.

Mechanism

Inspect expiry/retention, save to the permitted target and retain job identity. Check response, file type/content and copied bytes, then read from the destination. Deliver the verified location/scope without exposing signed credentials. Without retention authorization, explain temporary delivery rather than silently archiving.

Bad example

Call the temporary URL a permanent archive, upload to an unauthorized public location and skip audio-versus-error-page checks.

Good example

Save the teaching audio to authorized reports/audio/briefing.wav. Check response/type, read the destination and compare copied content with the retrieved bytes, linked to its job. Provide the verified local path without signed parameters or another upload. Failures remain incomplete. Unapproved extended retention needs a stated decision rather than automatic storage.

Why the change matters

A temporary URL supplies bounded access rather than preserved content. A named target and readback expose error-page downloads, wrong directories and nonexistent saved artifacts.

Observable expectation

The fixture reads identifiable local audio with matching copied bytes; expired URLs/error pages do not pass merely by using a wav extension.

Current storage/read evidence does not promise permanent disks/backups/access. No real audio is generated/downloaded.

Limits

Retention/sharing follow authorization/privacy. Frozen one-hour/24-hour examples are not universal current expiry. Verify the actual output contract; existence alone does not establish archival suitability.