Liability & Risk Framework

This section sets out the liability framework for TrackForge's Golden Record Certification service, identifies foreseeable risk scenarios, and addresses the inherent limitations of any metadata certification system (the "Oracle Problem").

Liability limitations

TrackForge's certification service operates within the following liability boundaries:

1. Liability cap — Total liability for the certification service is capped at the fees paid by the client during the relevant contract period.
2. Upstream errors excluded — TrackForge does not accept liability for errors or omissions in the source databases consulted (Spotify, MusicBrainz, PRS for Music, MLC, Discogs, Last.fm, and others). The certification methodology documents which sources were consulted and how conflicts were resolved, but does not warrant the accuracy of those sources.
3. Reliance without legal advice — TrackForge does not accept liability where a party relies upon a certification without obtaining independent legal advice appropriate to their circumstances.
4. Consequential and indirect losses excluded — Liability for indirect, consequential, or special losses is excluded to the fullest extent permitted by law.
5. Professional indemnity insurance — TrackForge maintains professional indemnity insurance appropriate to the certification service. PI cover is in place before the first B2B client engagement.

Contractual terms prevail

The specific liability terms applicable to any engagement are set out in the relevant client contract and Data Processing Agreement. This documentation provides a general overview of TrackForge's approach to liability and risk. It does not constitute a contractual commitment and is subject to the terms agreed with each client.

Risk scenarios

The following table identifies foreseeable risk scenarios and the corresponding mitigations built into the certification framework.

Scenario	Description	Mitigations
Certification relied upon in dispute	A party presents a TrackForge certification as evidence in a rights dispute and subsequently loses. The party seeks to recover against TrackForge.	Liability cap (fees paid). Certificate disclaimer states process fidelity, not legal truth. Methodology defence: documented, repeatable process was followed correctly.
Conflicting certifications	Two parties hold TrackForge certifications for the same ISRC with different metadata (e.g., different writer splits).	Both certifications stand as valid records of the metadata state at their respective certification dates. The system flags the conflict. TrackForge does not adjudicate between competing claims. See Conflicting Certifications Policy.
Upstream source error	A source database (e.g., MusicBrainz, PRS) contained an error at the time of certification, which was propagated into the certified metadata.	Methodology defence: the published methodology was followed. Certification attests to process fidelity, not upstream accuracy. The certificate disclaimer addresses this expressly.
Bad faith reliance	A party uses a certification as "proof" of ownership in circumstances where it was not intended to serve that purpose.	Acceptable use terms in the client contract. Certificate disclaimer is explicit that certification does not constitute proof of ownership. Published scope documentation (this page and the Scope & Legal Positioning page).
Post-anchor error discovered	An error in the certified metadata is discovered after blockchain anchoring.	Re-certification is available. The original certification remains on the blockchain as a historical record. The new certification supersedes it, with the re-certification event documented in the audit trail.
GDPR deletion request	A data subject requests deletion of their personal data, which appears in certified records.	The blockchain anchor contains only the Merkle root hash — no personal data. Underlying records are handled per the Data Processing Agreement. The hash persists (it is not personal data), but the underlying metadata can be deleted or anonymised as required. See Data Handling & GDPR.

The Oracle Problem

Any system that certifies real-world data faces a fundamental epistemological limitation known as the "Oracle Problem": the certification system can verify that its own process was followed correctly, but cannot independently verify the absolute truth of the underlying data obtained from external sources.

TrackForge operates as a Trusted Gateway between external metadata sources and the certified output. The integrity of the certification depends on both the rigour of the internal process and the quality of the external sources consulted. TrackForge mitigates the Oracle Problem through the following measures:

1. Published methodology — The certification methodology is published, versioned, and available for independent review. Any party can assess the rigour of the process that produced a given certification.
2. Operator review — In B2B engagements, a trained human operator reviews the enrichment results, conflict resolutions, and quality gate outcomes before certification. The operator audit trail provides a complete record of every action taken, every review performed, and every decision made during the certification process.
3. Re-certification — Where errors are discovered post-certification, the system supports re-certification. The original certification remains as a historical record; the new certification supersedes it.
4. Explicit disclaimer — Every certificate carries a disclaimer that expressly addresses the limitation. The certification attests to process fidelity, not the absolute accuracy of the underlying metadata.
5. Professional indemnity insurance — PI cover provides a financial backstop where the certification service falls below the standard required.

Operator audit trail

The operator audit trail is a material component of the risk mitigation framework. For every B2B certification, the system records:

• The identity of the operator who performed each action
• The precise action taken (certification, review, export, enrichment, or administrative)
• The catalogue, ISRC, and batch affected
• A detailed record of the decision context (stored as structured data)
• The timestamp, IP address, and client information for each action

This audit trail is included in the certification proof bundle delivered to the client. It provides contemporaneous evidence that human review was conducted and documents the basis on which certification decisions were made. In the event of a dispute, the audit trail serves as evidence of the standard of care applied during the certification process.