The Proof Bundle

The Proof Bundle is a ZIP archive designed to be a complete, self-contained evidence package. It includes everything needed to independently verify the certification of your catalogue — even if TrackForge no longer exists.

What the bundle contains

File / Directory	Description
catalog_report.json	Full catalogue certification report: summary statistics, Merkle root, anchor details, and a listing of all certified tracks.
chain_of_title.json	Complete chain of title for every certified track. Includes writer details (name, IPI, role, share percentage), ISWCs, Merkle proofs, blockchain anchor data, and the canonical JSON for each track. This is the primary document for Business Affairs.
tracks/	Individual track certificates, one JSON file per ISRC (e.g. tracks/GBAYE0100538.json). Each contains the canonical JSON, Merkle inclusion proof, and blockchain anchor data.
merkle_tree.json	Full Merkle tree serialisation — all leaf hashes and the root hash. Used to independently verify any track's inclusion proof.
proofs/	OpenTimestamps (.ots) proof files for blockchain verification. These allow direct verification against a public blockchain without any third-party service.
operator_audit_trail.json	Timestamped record of all operator review and certification actions. Provides evidence that a trained human reviewed the data (B2B engagements).
methodology.txt	The certification methodology document that was in effect at the time of certification.
methodology.json	Machine-readable serialisation of the complete rating criteria (thresholds, assurance levels, disclosure text) and the methodology hash. This file can be used to independently verify that the published criteria match the methodology hash bound to the certification.
README.txt	Plain-text verification instructions — the same 7-step procedure described below.

Why self-containment matters

The Proof Bundle is deliberately designed so that no external service is required to verify it. This matters in several scenarios:

• Catalogue acquisitions — A buyer's due diligence team can verify the metadata certification without contacting TrackForge or relying on any third-party API.
• Legal disputes — In litigation, evidence that depends on a third party remaining operational is weaker than evidence that is self-verifying.
• Long-term archival — Music catalogues are long-lived assets. A proof bundle created today should be verifiable in 20 years, regardless of whether TrackForge is still in business.
• Regulatory compliance — Some jurisdictions and insurance policies require evidence packages that are independently auditable.

How to use the bundle

For catalogue acquisitions

When a potential buyer is conducting due diligence on your catalogue, provide the Proof Bundle alongside your standard data room materials. The buyer's team can:

1. Open chain_of_title.json to review writers, shares, and ISWCs for every track.
2. Cross-reference writer IPIs against their own PRO databases.
3. Verify the cryptographic proofs to confirm the data has not been altered since certification.
4. Review operator_audit_trail.json to confirm human oversight was applied.
5. Check the blockchain anchors to confirm the certification timestamp.

Positioning the bundle in a data room

The Proof Bundle is most effective when presented as a supplement to your existing catalogue documentation, not a replacement. Frame it as: "Independent, third-party verification of the metadata, with cryptographic proof of the state at the time of certification."

For sync licensing clearance

When licensing a track for synchronisation (film, TV, advertising), the licensee's clearance team needs confidence in the rights chain. The chain_of_title.json provides:

• All writers with their IPI numbers and share percentages
• The ISWC linking the recording to the registered work
• Cryptographic proof that this information was verified by a documented, multi-source process

This can significantly speed up clearance by providing an evidence base that the clearance team can independently verify.

For dispute resolution

In a metadata or rights dispute, the Proof Bundle serves as evidence of the metadata state at a specific point in time:

• The blockchain anchor proves the certification existed at or before the anchored time — it cannot be backdated.
• The canonical JSON shows exactly what data was certified.
• The Merkle proof shows this track was part of the certified batch (not added after the fact).
• The operator audit trail shows that a human operator reviewed and approved the data.

For PRO registration

The chain_of_title.json contains the writer information (names, IPIs, roles, shares) needed for registering or updating works with PROs. While it does not replace the formal registration process, it provides a verified reference point.

The 7-step verification procedure

This is the same procedure included in the bundle's README.txt. It allows complete, independent verification using standard tools.

Step 1. Open the track's JSON file (from tracks/) or chain_of_title.json.

Step 2. Locate the canonical_json field. This is the exact data that was certified.

Step 3. Compute the SHA-256 hash of that exact string. Any SHA-256 tool will work:

echo -n '<canonical_json value>' | shasum -a 256

Step 4. Verify that the computed hash matches the record_hash field in the same file.

Step 5. Use the Merkle proof (proof_hashes and proof_directions) to walk from the leaf hash (the track's record_hash) up to the Merkle root. At each level, combine the current hash with the proof hash (left or right as indicated) and compute SHA-256 of the pair.

Step 6. Verify that the final hash matches the merkle_root in catalog_report.json.

Step 7. Use the .ots proof file from the proofs/ directory to verify the Merkle root is anchored on a public blockchain. You can use the ots command-line tool, the OpenTimestamps website, or any blockchain node.

You do not need to verify everything

For most practical purposes, Steps 1-4 (verifying a single track's hash) are sufficient to confirm that the data has not been altered. Steps 5-7 add progressively stronger guarantees — batch integrity and blockchain anchoring — which matter most in legal or adversarial contexts.

What's next

• How to Verify Independently — More detail on each verification method.
• Re-Certification — What happens when metadata changes after certification.