Re-Certification

Methodology Version

Methodology Version 1.0 — Effective February 2026

Music metadata is not static. Writer splits are corrected by PROs, contractual updates reassign shares, disputes are resolved, and enrichment sources provide improved data over time. TrackForge's re-certification process handles these changes while maintaining the integrity and verifiability of the full certification history.

When re-certification occurs

Re-certification is triggered by any material change to a track's rights-critical metadata. The defined trigger categories are:

Trigger	Description	Example
PRO correction	A collection society updates its records for the work	PRS corrects a writer's share allocation from 50% to 33.33%
Contractual update	A rights transfer, reversion, or new agreement changes ownership	Publisher acquires a catalogue and writer shares are reassigned
Dispute resolution	A dispute over credits or shares is formally resolved	A co-writer's claim is accepted and added to the record
Administrative correction	A data error is identified and corrected	A misspelt writer name or incorrect IPI number is fixed
Re-enrichment	New or updated data becomes available from enrichment sources	MusicBrainz adds an ISWC that was previously missing

Re-certification is never automatic. Every re-certification requires human operator review, regardless of the trigger. This ensures that metadata changes are intentionally approved, not silently propagated.

The version chain

Each re-certification creates a new version of the track's certification, linked to its predecessor by hash. This forms a cryptographic linked list — a chain in which each version references the hash of the version before it.

In this example:

• Version 1 is the initial certification. Its previous_version_hash is null.
• Version 2 was triggered by a PRO correction. Its previous_version_hash is the hash of Version 1.
• Version 3 (current) was triggered by a contractual update. Its previous_version_hash is the hash of Version 2.

Chain integrity

The version chain has a critical property: no version can be inserted, removed, or altered without detection. Modifying any version's metadata would change its hash, which would break the chain linkage in the subsequent version. This can be verified by walking the chain from the latest version back to Version 1 and confirming that each previous_version_hash matches the preceding version's record_hash.

TrackForge provides automated chain integrity verification that checks:

• Version 1 has no predecessor (previous_version_hash is null)
• Each subsequent version's previous_version_hash matches the preceding version's record_hash
• Version numbers are sequential with no gaps
• Exactly one version is marked as current

Full pipeline re-run

Re-certification is not a patch or a delta. Each re-certification runs the entire certification pipeline from the beginning:

1. Enrichment — The track is re-enriched against all sources in the waterfall, incorporating any new or updated data
2. Operator review — A human operator reviews the changes, confirms their correctness, and approves the re-certification
3. Canonicalisation — The updated metadata is canonicalised using the same deterministic process
4. Hashing — A new SHA-256 hash is computed from the updated canonical form
5. Merkle tree — The new hash is included in a Merkle tree with other tracks in the re-certification batch
6. Blockchain anchoring — The new Merkle root is anchored to the blockchain via OpenTimestamps

This full re-run ensures that re-certified data receives the same level of verification as initial certifications. There are no shortcuts.

Previous versions remain valid

When a track is re-certified, the previous version is not invalidated or deleted. It remains a valid, independently verifiable record of the metadata state at its certified date. The previous version is marked as superseded (with a superseded_at timestamp) but its hash, Merkle proof, and blockchain anchor continue to be verifiable.

This is intentional. The previous version is a historical record: it attests that the metadata was in a specific state at a specific time. That attestation remains true even after the metadata has changed. A verifier examining the full version chain can see exactly how the metadata evolved over time, when each change occurred, and what triggered it.

Chain of title at the data level

The version chain constitutes a chain of title at the data level: a cryptographically-linked, independently verifiable history of how a track's rights-critical metadata evolved over time. Each link in the chain records:

• The exact metadata state (via the canonical JSON and hash)
• When the certification was issued
• What triggered the change
• Whether the change was material or administrative
• Who approved it (via the operator audit trail)
• A blockchain-anchored timestamp proving when the certification existed

For parties conducting due diligence on a catalogue — business affairs teams, sync licensing departments, dispute lawyers, insurers — this chain provides a structured, verifiable record of the catalogue's metadata history that would otherwise require extensive manual research.

Change categories

Each re-certification is classified into one of two categories:

Category	Definition	Examples
Material	Changes to rights-determinative data that affect royalty routing or ownership	Writer share changes, new writer added, publisher assignment, ISWC correction
Administrative	Corrections that do not affect the substance of the rights claim	Name spelling correction, IPI format normalisation

Both categories result in a new certification version with a new hash and blockchain anchor. The distinction is recorded for audit purposes and to help downstream consumers assess the significance of changes.

Methodology version tracking

Each re-certification records both the data version chain (the linked list of record hashes) and the methodology version used to produce the rating. This means changes to either dimension are independently traceable:

• If the underlying data changes but the methodology remains the same, the record_hash changes while the methodology_hash stays constant.
• If the methodology is updated (e.g., a new standard version with revised thresholds), the methodology_hash changes even if the data has not.
• A verifier examining the version chain can determine, for each certification version, both what the data was and which rules governed the rating — and confirm both cryptographically.

This dual-chain approach ensures that no change to either the data or the evaluation criteria can go undetected.

Related methodology pages

• Golden Record Selection — The completeness criteria re-evaluated during re-certification
• Enrichment & Cross-Source Validation — The enrichment pipeline that runs again during re-certification
• Canonicalisation — The deterministic serialisation applied to updated metadata
• Independent Verification — How any version in the chain can be independently verified