---
sidebar_position: 3
title: How to Verify Independently
description: Three methods for verifying a TrackForge certification — online, from the proof bundle, or from scratch.
keywords:
  - verify certification
  - independent verification methods
  - proof bundle verification
  - self-verification music metadata
---

# How to Verify Independently

A TrackForge certification is designed to be verifiable by anyone, at any time, without needing to contact or trust TrackForge. This page describes three methods, from simplest to most thorough.

## Method 1: Online verification

The quickest way to verify a certificate or rating proof.

1. Go to [trackforge.studio/docs/certification/for-catalogue-owners/verification](https://trackforge.studio/docs/certification/for-catalogue-owners/verification).
2. Paste the `canonical_json` field from your certificate into the input box.
3. The page computes the SHA-256 hash in your browser and checks it against the certification records.

For current M58 rating events, Forge also exposes a grade proof endpoint that returns the AAA-D rating proof for the current certification root. Use that when the artefact you need to verify is a catalogue or track grade rather than a legacy canonical track record.

:::tip[Your data stays private]
The hash is computed entirely in your browser using the Web Crypto API. The canonical JSON is **never transmitted** to TrackForge's servers — only the resulting hash is checked. You can verify this by inspecting the network traffic in your browser's developer tools.
:::

**Limitations:** This method relies on TrackForge's verification service being available. For verification that works regardless of TrackForge's operational status, use Method 2 or 3.

## Method 2: From the Proof Bundle

The Proof Bundle is a self-contained ZIP archive that includes everything needed for independent verification. This method requires no internet connection and no reliance on TrackForge.

### What you need

- The Proof Bundle ZIP file
- A SHA-256 tool (built into macOS, Linux, and Windows; also available online)
- An OpenTimestamps verifier (optional, for blockchain confirmation)

### Step-by-step

**Step 1 — Extract the bundle**

Unzip the M58 Proof Bundle. The current compact bundle contains `README.md`, `manifest.json`, `methodology/methodology.json`, `proof/rating_event_proof.json`, `proof/rating_event.json`, `proof/leakage_vector.json`, and `proof/snapshot_links.json`.

Older or enhanced certification bundles may also include `catalog_report.json`, `chain_of_title.json`, a `tracks/` directory, `merkle_tree.json`, and a `proofs/` directory. Treat those as legacy/enhanced chain-of-title artefacts unless the manifest says they are part of the current proof contract.

**Step 2 — Verify the manifest**

Hash each file listed in `manifest.json` and confirm the computed hashes match the manifest.

**Step 3 — Open the methodology artefact**

Open `methodology/methodology.json` and confirm the methodology version/hash match the rating event and published methodology label.

**Step 4 — Open the rating event**

Open `proof/rating_event.json`. Confirm the rating scale is `TRACKFORGE_AAA_D`, and check the methodology version/hash, workflow version, taxonomy version, jurisdictional scope, snapshot reference, agreement-binding summary, ISWC coverage summary, leakage-vector hash, Merkle root/current root, and proof state.

**Step 5 — Verify the leakage vector**

Hash `proof/leakage_vector.json` using the canonicalisation rules for the methodology version and compare the result with the rating event's `leakage_vector_hash`.

For current M58 events, the leakage vector also carries the public row materiality inputs used to calculate the grade. Use the [Rating Input & Scoring Schedule](/docs/certification/methodology/rating-input-scoring-schedule) to recompute row risk points, row scores, catalogue caps, and the final AAA-D rating.

**Step 6 — Verify the proof wrapper**

Open `proof/rating_event_proof.json` and confirm it references the same rating event, root, proof state, and snapshot links as `proof/rating_event.json`.

**Step 7 — Follow the snapshot links**

Open `proof/snapshot_links.json` to trace the proof back to the frozen evidence snapshot used by the rating workflow.

**Step 8 — Verify optional blockchain anchor**

If the bundle includes `.ots` files or transaction references, use an OpenTimestamps verifier to confirm that the root is anchored in the blockchain:

```bash
# Using the ots command-line tool
ots verify proofs/batch_<batch_id>.ots

# Or use the online verifier at opentimestamps.org
```

This confirms that the root existed at or before the time recorded in the blockchain block.[^1]

## Method 3: From scratch

This method uses no TrackForge tools or files at all. It is the most independent form of verification, suitable for adversarial contexts such as legal disputes.

### What you need

- The rating event JSON or legacy `canonical_json` for the subject
- The claimed evidence, leakage-vector, and rating-event hashes
- The claimed Merkle root/current root and any transaction ID
- Any SHA-256 implementation
- Access to a blockchain explorer (e.g. blockstream.info, mempool.space)

### Step-by-step

1. **Hash the supplied JSON artefacts** using the canonicalisation rules for the methodology version. Verify the results match the claimed hashes.

2. **If you have the Merkle proof**, walk the proof tree from leaf to root and verify the result matches the claimed `merkle_root`.

3. **Look up the blockchain transaction** using the transaction ID on any blockchain explorer. The transaction's `OP_RETURN` data (via the OpenTimestamps protocol) commits to the Merkle root.

4. **Verify the timestamp.** The blockchain block timestamp proves the data existed at or before that time. Blockchain blocks cannot be backdated.

:::tip[Why this matters]
This method demonstrates that the certification is not dependent on TrackForge in any way. The cryptographic proofs are based on open standards (SHA-256, Merkle trees, public blockchains, OpenTimestamps). Any competent technical expert can verify them using publicly available tools and a public blockchain — a public ledger that no single party controls.
:::

## Summary of verification methods

| Method | Requires TrackForge? | Requires internet? | Technical skill needed | Best for |
|--------|---------------------|--------------------|-----------------------|----------|
| **Online** | Yes (verification page) | Yes | None | Quick checks |
| **From Proof Bundle** | No | No (except blockchain step) | Basic command line | Due diligence, archival |
| **From scratch** | No | Yes (blockchain explorer) | Moderate | Legal disputes, adversarial verification |

All three methods verify the same underlying cryptographic proof. The difference is in convenience versus independence.

## What's next

- **[The Proof Bundle](./proof-bundle)** — Detailed guide to the self-contained verification archive.
- **[Rating Input & Scoring Schedule](/docs/certification/methodology/rating-input-scoring-schedule)** — Detailed guide to recomputing the AAA-D grade from rating inputs.
- **[Re-Certification](./recertification)** — What happens when certified metadata changes.

[^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.