Re-Certification: When and Why

Music metadata is not static. Writers are added to registrations, PROs issue corrections, contracts are renegotiated, and disputes are resolved. When certified metadata changes, TrackForge issues a re-certification — a new version of the certification that is cryptographically linked to the previous one.

What triggers re-certification

Re-certification is triggered when a change affects the rights-determinative fields of a previously certified track. There are five defined triggers:

Trigger	What happened	Example
Contract change	The underlying rights agreement was modified	A writer's share percentage changed following a renegotiation
PRO correction	A collecting society issued a correction	PRS updated a writer's IPI number or corrected a work registration
Dispute resolution	A dispute was settled and the metadata updated	A co-writing credit was confirmed following mediation
Administrative correction	A factual error was corrected	A misspelt writer name, a transposed ISRC digit
Re-enrichment	New enrichment data became available	A previously missing ISWC was found in a newly available source

Re-certification is not triggered by cosmetic changes (such as updated album art or genre tags) — only changes to fields that affect royalty calculations and rights determinations.

How re-certification works

When a track is re-certified, the following happens:

1. New canonical JSON is generated from the updated metadata.
2. New SHA-256 hash is computed from the new canonical JSON.
3. New version is created with the new hash, linked to the previous version's hash.
4. Previous version is marked as superseded (but not deleted).
5. Human operator reviews and approves the change (for B2B engagements).
6. New Merkle tree is built for the certification batch.
7. New blockchain anchor is created for the updated batch.

Each re-certification is categorised as either:

• Material — A substantive change affecting rights (contract change, dispute resolution)
• Administrative — A correction that does not change the underlying rights position (typo fix, PRO correction of an identifier)

The version chain

Every re-certification creates a new version that is cryptographically linked to its predecessor, forming a version chain — a tamper-proof sequence of metadata states.

v1 (initial)
 ├─ record_hash: a1b2c3...
 └─ previous_version_hash: (none)

        ↓ PRO correction

v2
 ├─ record_hash: d4e5f6...
 └─ previous_version_hash: a1b2c3...  ← matches v1's hash

        ↓ contract change

v3 (current)
 ├─ record_hash: g7h8i9...
 └─ previous_version_hash: d4e5f6...  ← matches v2's hash

The chain has three properties that can be independently verified:

1. Version 1 has no predecessor — its previous_version_hash is empty.
2. Each subsequent version's previous_version_hash matches the predecessor's record_hash — proving the chain is unbroken.
3. Exactly one version is marked as current — the latest, active certification.

This structure proves that no version has been inserted, removed, or reordered after the fact. The integrity of the chain can be verified by anyone with access to the version history.

Why previous certifications remain valid

A common question: "If my catalogue is re-certified, does the old certification become invalid?"

No. Previous certifications remain valid as historical records. They accurately attest to what the metadata looked like at the time they were issued.

Consider an analogy: a property survey conducted in 2020 does not become "invalid" because a new survey was conducted in 2025 after an extension was built. The 2020 survey accurately records the property's state at that time. Both surveys are truthful — they simply describe different moments.

Similarly:

• Version 1 certifies: "On 15 January 2026, the metadata for this track was in this state, and it met all quality thresholds."
• Version 2 certifies: "On 3 March 2026, after a PRO correction, the metadata was updated to this state, and it still meets all quality thresholds."

Both statements are true. Both are blockchain-anchored. Both are independently verifiable. The version chain shows exactly what changed and when.

For legal contexts

The version history can be valuable evidence in disputes. If a writer's share was changed, the version chain shows: what the original certified state was, when the change occurred, what triggered it, and who approved it (via the operator audit trail). This creates a clear, auditable timeline.

When to request re-certification

You should consider re-certification when:

• Writer shares change — Following a renegotiation, settlement, or newly discovered co-writer.
• A PRO issues a correction — Updated IPI numbers, corrected work registrations, or amended share allocations.
• A dispute is resolved — The outcome changes the rights position for one or more tracks.
• An error is discovered — A factual mistake in the certified metadata (misspelt name, incorrect ISRC).
• New data becomes available — A previously missing ISWC or writer credit is found through new enrichment sources.

You do not need re-certification for cosmetic changes that do not affect rights-determinative fields.

Proactive re-certification

If you are preparing a catalogue for sale, it is worth checking whether any PRO corrections or new registrations have been issued since the last certification. A current certification with a clean version chain is stronger evidence than an older certification supplemented by informal corrections.

What's next

• What You Get — Overview of all certification deliverables.
• Understanding Your Certificate — Field-by-field guide to the Track Certificate.