Keep a release metadata change log your team can trust

Use a small, explicit record

For each change, record the release reference, affected track or field, previous value, proposed value, reason, requester, approval owner and date. Add the relevant source file or agreement reference. Use a status such as proposed, approved, submitted or verified rather than treating every edit as already public.

Link changes to exact versions

Example: a guest’s spelling is corrected in draft v3, approved by the artist and submitted the next day. Keep the v2 value and v3 snapshot rather than overwriting the only copy. If artwork or audio also changes, record the specific export. A folder named latest is not enough to establish what stores received.

Separate authority and scope

A person who prepares a spreadsheet may not be authorised to change a credit or contractual allocation. Have the right owner approve the relevant field. Keep accepted splits, rights approvals and private account details in their own controlled records. Do not publish those documents inside a public release-page revision history.

Verify the delivery outcome

Spotify explains that metadata corrections are sent by the label or distributor. Record the request reference and compare the observed store result with the approved snapshot. A submitted update is not a verified public correction. This workflow is a team practice; it does not announce an automatic DistroBolt metadata-history feature.

Sources and review

Reviewed 4 November 2026. Platform requirements and plan terms can change. Examples are planning aids, not a promise of account access, release acceptance or earnings.

• Spotify metadata correction route
• DistroBolt release archive

Continue your release planning

• Resolve a cover-art rejection without resubmitting blindly
• SoundCloud upload versus distribution: choose the right route

Ask the DistroBolt team about your release. Send a concise question and release reference; never send account passwords or verification codes.