Assets and uploads

Asset delivery is a two-part process: declare immutable bytes in the manifest, then upload those exact bytes through a short-lived URL scoped to one accepted batch and asset.

Declared bytes

Every asset has a ref, filename, media type, byte count and SHA-256. Recording and release references determine master and cover roles. The manifest never contains a storage object key or signed URL.

Scoped intent

Call createMusicDeliveryUploadIntent with the accepted batch and exact asset declaration. The response is bound to that account, batch, asset, media type and size.

Direct PUT

Upload directly to the returned URL with the exact required headers. Client progress measures bytes sent to object storage. It does not report server verification, catalog coordination or transcoding progress.

Completion

Call completeMusicDeliveryUpload after the object PUT succeeds. Completion is idempotent for the same intent and creates or resolves the next durable work; it is not a page reload boundary.

Verification

Kasty checks object scope, byte count, media type, checksum and storage metadata. A mismatch requires correcting or re-uploading the declared bytes. Do not retry a checksum mismatch blindly.

Renewal

When the URL expires, renew the same logical (batch, assetRef) intent. The public intent identity remains scoped to the accepted asset while the short-lived write URL changes. This avoids duplicate asset identities and unique-key conflicts.

Lossy input

Kasty preserves what was delivered. A compatible lossy source may be passed through or remuxed according to the active artifact policy; it is not decoded and presented as genuine lossless. Avoid an additional lossy encode when a compatible listening source can be retained safely.