---
sidebar_position: 4
title: The Proof Bundle
description: A guide to the self-contained certification archive — what it contains, how to use it, and why it matters.
keywords:
  - proof bundle
  - certification archive
  - self-contained verification
  - cryptographic proof package
---

# 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](/docs/certification/methodology/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.

:::tip[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](/docs/certification/methodology/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.

:::tip[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](./verification)** — More detail on each verification method.
- **[Re-Certification](./recertification)** — What happens when metadata changes after certification.

[^1]: TrackForge currently uses the Bitcoin blockchain via the [OpenTimestamps](https://opentimestamps.org/) protocol. See [Blockchain Anchoring](/docs/certification/methodology/blockchain-anchoring) for implementation details.