The Proof Bundle

The M58 Proof Bundle is a ZIP archive designed to be a compact, self-contained evidence package for the current AAA-D rating event. It includes the files needed to verify the rating event, leakage-vector state, snapshot links, and proof manifest.

What the bundle contains

File / Directory	Description
README.md	Human-readable verification notes for the bundle.
manifest.json	File inventory with hashes and bundle metadata.
proof/rating_event_proof.json	Proof wrapper for the rating event, including methodology, scope, root/proof state, and hash references.
proof/rating_event.json	Canonical rating event payload: AAA-D rating, methodology version/hash, workflow/taxonomy versions, scope, snapshot reference, agreement-binding summary, ISWC coverage summary, leakage-vector hash, Merkle root, and proof state.
proof/leakage_vector.json	Deterministic leakage-vector projection used by the current M58 rating model.
proof/snapshot_links.json	References from the rating event back to the frozen evidence snapshot and source records.
methodology/methodology.json	Machine-readable methodology artefact and hash pointer for the rating event. Use it with the public Rating Input & Scoring Schedule when recomputing the grade.

Older or enhanced certification bundles may also include chain_of_title.json, tracks/, merkle_tree.json, OpenTimestamps .ots files, or operator audit trails. Treat those as legacy/enhanced chain-of-title certification artefacts unless the bundle manifest names them as part of the current M58 proof contract.

Why self-containment matters

The Proof Bundle is deliberately designed so that the current rating event can be checked without relying on an informal TrackForge explanation. This matters in several scenarios:

• Catalogue acquisitions — A buyer's due diligence team can verify the rating certificate 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 proof/rating_event.json to review the AAA-D rating, methodology version, workflow version, taxonomy version, and declared scope.
2. Open methodology/methodology.json to verify the methodology hash tied to that event.
3. Check the agreement-binding and ISWC coverage summaries for PRS/MCPS-scoped works.
4. Open proof/leakage_vector.json to see which leakage conditions were active, inactive, or not applicable, and to review the row materiality inputs used by the scoring schedule.
5. Use manifest.json to verify the hashes of the proof files.
6. Use proof/snapshot_links.json to trace the rating back to the frozen evidence snapshot.
7. Review any enhanced chain-of-title files separately if the bundle includes them.

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 M58 bundle provides the rating event, leakage vector, PRS/WACD agreement-binding summary where in scope, ISWC coverage summary, and snapshot links. If a richer chain_of_title.json is present, use it as the enhanced Business Affairs artefact for writer, IPI, share, and work-registration review.

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 rating event JSON shows exactly what AAA-D rating was issued, under which methodology, scope, workflow, taxonomy, and snapshot.
• The leakage vector shows which risk conditions drove the rating.
• The snapshot links show which frozen evidence records supported the event.
• The manifest shows whether bundle files match their expected hashes.

For PRO registration

The M58 proof bundle is not a PRO registration package. It can show whether PRS/WACD agreement binding and ISWC coverage affected the rating. If the ZIP also includes an enhanced chain-of-title bundle, use that richer artefact as the reference for writer information, IPIs, roles, shares, and registration updates.

Verification procedure

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

Step 1. Open manifest.json and confirm the expected files are present.

Step 2. Hash each bundled file listed in the manifest and compare the result with the manifest hash.

Step 3. Open methodology/methodology.json and confirm the methodology hash/version match the rating event.

Step 4. Open proof/rating_event.json and confirm the rating scale is TRACKFORGE_AAA_D, with the expected methodology version, workflow version, taxonomy version, and jurisdictional scope.

Step 5. Check agreement_binding_summary and iswc_coverage_summary. For the current M58 model, PRS/SearchWorks WACD agreement binding and ISWC coverage are rating inputs where they are in scope.

Step 6. Open proof/leakage_vector.json and verify that its hash matches the leakage_vector_hash referenced by the rating event.

Step 7. Recompute row scores, catalogue caps, and the final AAA-D rating using the Rating Input & Scoring Schedule, then compare the result with proof/rating_event.json.

Step 8. Open proof/rating_event_proof.json and confirm that the proof wrapper references the same rating event, Merkle root/current root, proof state, and snapshot links.

Step 9. If OpenTimestamps files or transaction references are present, verify them using 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-5 confirm the delivered M58 proof files are internally consistent. OpenTimestamps and enhanced chain-of-title verification add stronger evidence for legal or adversarial contexts when those artefacts are present.

What's next

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