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/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.

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 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:

# 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.¹

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.

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 — Detailed guide to the self-contained verification archive.
• Rating Input & Scoring Schedule — Detailed guide to recomputing the AAA-D grade from rating inputs.
• Re-Certification — What happens when certified metadata changes.

Footnotes

1. TrackForge currently uses the Bitcoin blockchain via the OpenTimestamps protocol. See Blockchain Anchoring for implementation details. ↩