Conflicting Certifications Policy

This section addresses the scenario in which two or more TrackForge certifications exist for the same ISRC (International Standard Recording Code) but contain different metadata — for example, different writer splits, different writer attributions, or different compositional data.

Policy

TrackForge's policy on conflicting certifications is defined by the following five principles:

1. Both certifications stand. Each certification is a valid, independently verifiable record of the metadata state at its respective certification date. Neither certification is invalidated, withdrawn, or superseded by the existence of the other.
2. The system flags the conflict. When a conflict is detected (i.e., two certifications for the same ISRC with materially different rights-determinative metadata), the system records the conflict and makes it visible to both parties.
3. TrackForge does not adjudicate. TrackForge does not determine which certification is "correct" or which party's metadata reflects the true legal position. Adjudication of rights disputes is a matter for the parties, their legal advisers, or the relevant judicial or arbitral forum.
4. Neither certification is invalidated. The existence of a conflicting certification does not affect the validity of either certification as a record of process fidelity. Each certification attests that the stated methodology was followed and that the data was in the stated condition at the stated time — and both statements remain true.
5. The conflict is visible to both parties. Transparency is fundamental. Both parties are made aware that a conflicting certification exists. Neither party is left with the impression that their certification is the sole record for that ISRC.

Why both certifications stand

This policy follows directly from the nature of TrackForge certification and the properties of the blockchain anchor.

Process fidelity, not legal truth

Each certification attests to process fidelity: the documented methodology was followed, the quality gates were passed, and the metadata was in the stated condition at the stated time. Both of these statements can be simultaneously true even when the underlying metadata differs. The certification does not assert that the metadata is the definitive legal truth — only that the process was followed correctly.

Two certifications with different writer splits do not represent a failure of the certification system. They represent two independently verified snapshots of the metadata as it existed in each party's catalogue at the time of certification. The difference between them is a matter for the parties to resolve through their own legal or commercial processes.

Blockchain immutability

Each certification is anchored to a public blockchain via OpenTimestamps. Once anchored, the certification hash cannot be removed, altered, or revoked. This immutability is a feature, not a limitation — it ensures that no party can retrospectively alter or suppress a certification.

Invalidating one certification in favour of another would require the ability to remove an anchor from the blockchain, which is not technically possible. The policy therefore reflects the technical reality as well as the principled position.

Conflict detection

TrackForge detects conflicts through the following mechanism:

• When a new certification is created, the system checks whether any existing certification covers the same ISRC.
• If an existing certification is found and the rights-determinative metadata differs materially (different writers, different splits, different ISWCs), a conflict is recorded.
• Both the existing and new certification holders are notified of the conflict through their respective TrackForge accounts.
• The conflict is recorded in the system metadata but does not appear on the certificates themselves. The certificates remain clean records of the metadata state at their respective certification dates.

Implications for relying parties

Parties who rely upon a TrackForge certification should be aware of the following:

1. A certification is not exclusive. The existence of a certification for a given ISRC does not preclude the existence of another certification for the same ISRC with different metadata.
2. Check for conflicts. Relying parties conducting due diligence should enquire whether any conflicting certifications exist for the ISRCs in question. This information is available through TrackForge's platform.
3. Certification does not resolve disputes. Where conflicting certifications exist, the certification system provides evidence of what each party's metadata stated at a given time. It does not resolve the underlying dispute. Resolution requires reference to the relevant agreements, collecting society records, and — where necessary — legal proceedings.
4. Evidentiary value is preserved. A certification retains its evidentiary value as a record of process fidelity even in the presence of a conflicting certification. The fact that another party holds a different certification does not diminish the attestation that the methodology was followed correctly in producing either certification.
5. Re-certification is available. Where a conflict is identified and the parties resolve the underlying dispute, either or both parties may request re-certification with corrected metadata. The new certification supersedes the previous one (though the previous certification remains on the blockchain as a historical record).

Not a dispute resolution mechanism

TrackForge certification is not a dispute resolution mechanism. Where conflicting certifications exist, the parties should seek independent legal advice to resolve the underlying rights question. TrackForge provides evidence of the metadata state at a point in time; it does not adjudicate between competing claims.