Independent Verification — Why You Don't Have to Trust Us
The trust problem
If the only way to believe a rating is to take the rater's word for it, you have not solved the information asymmetry problem. You have merely moved trust from the seller to a new intermediary.
A buyer's lawyer should be able to ask two questions and get answers that do not depend on TrackForge being honest:
- "How do I know the data hasn't been changed since certification?"
- "How do I know this track was actually part of the certified batch?"
TrackForge answers both with mathematical proof.
The simple version
Think of it like notarising a document — but one that nobody can forge, alter, or backdate, and that you can verify yourself without the notary's involvement.
When TrackForge certifies a catalogue under the current M58 model, four things happen:
1. The rating event gets a unique digital fingerprint
The rating event, leakage vector, and snapshot links are serialised deterministically and run through a mathematical function that produces fixed strings of characters. The same data always produces the same fingerprint. Change a single digit and the fingerprint changes completely. Anyone with the same proof files can compute the fingerprints and check they match.
2. Proof fingerprints are bound to a current root
The proof files are tied to a current Merkle/root commitment for the certified evidence set. Enhanced or historical bundles may also include per-track inclusion proofs, but the compact M58 bundle centres on manifest.json, methodology/methodology.json, proof/rating_event_proof.json, proof/rating_event.json, proof/leakage_vector.json, and proof/snapshot_links.json.
3. The catalogue fingerprint is permanently timestamped
The root fingerprint is recorded on a public blockchain — a distributed ledger maintained by a global network that no single party controls. This creates an immutable record that this exact fingerprint existed at this exact point in time. It cannot be altered, backdated, or deleted.
4. The rating methodology is independently timestamped
The rules that govern the rating — every threshold, criterion, and disclosure — are also fingerprinted and permanently timestamped on the blockchain, separately from any individual certification. This means the methodology itself cannot be changed retroactively. A verifier can confirm that the rating rules predated the certification they governed, closing the loop on the question: "Could the rules have been adjusted after the fact to produce a more favourable result?" The answer is mathematically provable: no.
The result: any third party can independently confirm that the rating event proof files have not changed, that the event is tied to the certified evidence root, that any anchored proof happened when it claims, and that the rating rules were locked in before the assessment — all without contacting TrackForge.
Why this matters commercially
This is not technology for technology's sake. Each step solves a specific commercial problem:
Fingerprinting solves the "was this proof altered?" problem. In a traditional advisory engagement, a buyer must trust that the data in the report is what was actually reviewed. With TrackForge, the buyer recomputes the fingerprint from the rating event and proof files. If it matches, the artefact is identical to what was certified. If it doesn't, something has changed. No trust required.
The current root solves the "is this the certified event?" problem. A buyer can verify that the rating event is tied to the certified evidence set and current certification root. Enhanced bundles can add per-track inclusion proofs for partial acquisitions, sub-licensing, and portfolio carve-outs.
The blockchain timestamp solves the "when was this actually done?" problem. A PDF report can be backdated. A blockchain record cannot. This provides independently verifiable proof of when the assessment happened — critical for re-certification, recourse claims, and regulatory compliance.
The technical detail (for those who want it)
The fingerprinting uses SHA-256, a cryptographic hash function that is an industry standard used in banking, government systems, and digital signatures worldwide. The serialisation rules are published so any engineer can reproduce the process.
The combined fingerprint uses a Merkle tree — a data structure that allows individual items to prove their inclusion in a set without revealing the other items. For a catalogue of 10,000 tracks, an inclusion proof requires only about 14 hashes. Compact, fast, and privacy-preserving.
The timestamp uses OpenTimestamps on the Bitcoin blockchain — chosen because it is the most widely distributed and longest-running public blockchain, providing the highest assurance of permanence. See Blockchain Anchoring for implementation details.
Comparison at a glance
| Consultant report | TrackForge certification | |
|---|---|---|
| Can the buyer verify data hasn't changed? | No — must trust the consultant | Yes — recompute the fingerprint |
| Can a third party reproduce the grade? | No — methodology is proprietary | Yes — the rating methodology and scoring schedule are published |
| Is there proof of when the assessment happened? | Dated report (can be backdated) | Blockchain timestamp (immutable) |
| Can individual tracks be verified privately? | No | Yes — inclusion proofs |
| Does verification need the assessor? | Yes | No — all proofs are self-contained |
| What if the assessor goes out of business? | Report becomes unverifiable | Proofs remain valid indefinitely |
| Can the methodology be changed retroactively? | No way to verify | No — methodology is OTS-timestamped on Bitcoin |
What this does not do
Cryptographic verification proves that the data has not changed since certification and that the certification happened when it claims. It does not prove that the underlying data was correct in the first place. If a writer's IPI number was wrong when certified, the fingerprint faithfully records the wrong number.
This is why the rating methodology and rating input scoring schedule are equally important. The cryptographic layer ensures the assessment is tamper-proof and verifiable. The methodology and scoring schedule explain how TrackForge projects evidence into leakage state, row risk points, catalogue caps, and an AAA-D rating.
Together, they provide something that has never existed in the music rights market: a standardised, verifiable, and comparable assessment of catalogue quality.
Return to: Why TrackForge Exists
Notes