Skip to main content
Version: v1.1

Independent Verification

Methodology Version

Methodology v1.1 — M58 AAA-D rating and certification model

A TrackForge certification is designed to be verifiable by any party, at any time, without requiring access to TrackForge systems. This is the distinguishing property of the certification: the proof does not depend on the certifier's continued existence, cooperation, or honesty.

Three-step verification process​

Verification follows three steps. Each step uses standard cryptographic tools available in every major programming language and operating system.

Step 1: Re-compute the hash​

Take the canonical JSON artefact included in the certification proof bundle, such as proof/rating_event.json or proof/leakage_vector.json, and compute its SHA-256 hash using the canonicalisation rules for the methodology version:

SHA-256( canonical_json_bytes ) → 64-character hex digest

Compare the computed digest with the matching hash stated in the proof wrapper or certificate. If they match, the canonical JSON artefact has not been altered since certification. If they do not match, the artefact has been modified.

This step requires only the canonical JSON string and any SHA-256 implementation. No TrackForge software or network access is needed.

Step 2: Verify the Merkle inclusion proof​

The certificate includes a Merkle inclusion proof: a compact set of sibling hashes and directions (left or right) from the track's leaf hash to the Merkle root.

To verify:

  1. Start with the track's hash (confirmed in Step 1)
  2. For each sibling hash in the proof, concatenate it with the current hash in the specified direction and compute SHA-256
  3. After processing all proof elements, compare the result with the stated Merkle root

If the computed root matches the stated root, the track is confirmed as part of the certified batch. If it does not match, either the proof is invalid or the track was not part of the original batch.

Step 3: Verify the blockchain anchor​

Confirm that the Merkle root hash is recorded in the referenced blockchain transaction. This can be done using:

  • Any public blockchain explorer (e.g., blockstream.info, mempool.space)
  • A local blockchain node (for maximum independence)
  • The OpenTimestamps verifier (ots verify command-line tool)

The OpenTimestamps proof file (.ots format, included in the proof bundle) contains the complete cryptographic path from the Merkle root to the block header. Verification confirms that the hash was committed to the blockchain1 at the stated time.

No data transmission required​

The verification process is designed to be performed entirely locally. At no point is it necessary to send the canonical JSON, the track metadata, or any commercially sensitive information to TrackForge or any other third party.

The public verification page at trackforge.studio/verify provides a browser-based verification tool that performs Step 1 entirely client-side using the Web Crypto API. The canonical JSON is hashed in the browser; no data is transmitted to TrackForge servers. Steps 2 and 3 are performed server-side using only the hash (not the underlying data).

Proof bundle contents​

Each certification produces a proof bundle that contains everything needed for independent verification:

ComponentPurpose
README.mdHuman-readable verification instructions
manifest.jsonBundle inventory and file hashes
proof/rating_event_proof.jsonProof wrapper for the rating event, root/current-root state, and hash references
proof/rating_event.jsonAAA-D rating event with methodology, workflow, taxonomy, scope, PRS/WACD agreement-binding summary, ISWC coverage summary, root, and proof state
proof/leakage_vector.jsonDeterministic leakage-vector projection used by the rating methodology
proof/snapshot_links.jsonReferences from the rating event back to the frozen evidence snapshot

Enhanced or legacy chain-of-title bundles may also include per-track canonical JSON, Merkle inclusion proofs, OpenTimestamps files, and operator audit trails. Those files remain useful when present, but they are not the compact M58 proof ZIP shape.

The proof bundle is self-contained. If TrackForge ceased to exist, a verifier with only the proof bundle and access to the blockchain could independently confirm every certification.

What verification proves​

A successful three-step verification confirms:

  1. Data integrity — The metadata has not been altered since certification (Step 1)
  2. Batch inclusion — The track was part of the specific certified batch (Step 2)
  3. Temporal proof — The certification existed at the stated time, as recorded on the blockchain (Step 3)
  4. Methodology integrity — The rating was governed by a specific, published set of criteria, as confirmed by the methodology hash (Step 4 of rating verification)

Verification does not prove that the metadata is legally correct or that no competing claims exist. It proves that the metadata was in the certified state at the certified time, and that it has not been altered since. See the overview of certification scope for the precise boundaries of what certification asserts.

Verifying a rating (not just a certification hash)​

The three steps above verify that the certified data has not been altered and was anchored at the stated time. TrackForge's Rating Methodology and Rating Input & Scoring Schedule add a further layer of verifiability: because the rating is produced by a deterministic pure function applied to published criteria, an independent party can also verify the rating itself.

To verify a rating:

  1. Obtain the catalogue data snapshot — The same data the deterministic rating engine evaluated. This is included in the proof bundle's canonical JSON records.
  2. Apply the published scoring schedule — The rating criteria are published as the Rating Methodology and the detailed Rating Input & Scoring Schedule, with versioned leakage-vector, agreement-binding, ISWC coverage, materiality, aggregation, cap, and threshold rules. Identical rating inputs always produce identical outputs.
  3. Compare evidence hashes — Each track rating includes a SHA-256 evidence hash computed from the canonical JSON. Recompute the hash from the canonical data and confirm it matches.
  4. Verify the methodology hash — Each rating includes a methodology_hash field: a SHA-256 digest of the complete rating ruleset. Recompute the hash from the published criteria (available in methodology.json in the proof bundle) and confirm it matches. This proves the exact thresholds and criteria that governed the rating.
  5. Verify the methodology/workflow/taxonomy versions — Every rating output records the methodology version, workflow version, taxonomy version, and declared jurisdictional scope. Confirm that the published methodology for those versions matches the criteria applied.

5. Verify the methodology anchor​

The proof bundle includes a methodology_standard.ots file — an OpenTimestamps proof that anchors the methodology hash to the Bitcoin blockchain independently of the certification anchor. To verify:

  1. Extract the methodology_hash from the certification record.
  2. Use the OpenTimestamps verifier (ots verify methodology_standard.ots) to confirm that this hash was committed to a Bitcoin block.
  3. Confirm that the Bitcoin block timestamp for the methodology anchor predates the certification timestamp.

This proves that the rating rules were locked in before the certification was issued. TrackForge cannot have adjusted methodology thresholds after the fact to produce a more favourable result, because the methodology hash was committed to an immutable public ledger before the certification process began.

The methodology anchor can also be verified programmatically via the /verify/methodology endpoint, which returns the methodology hash, the anchoring transaction, and the block timestamp.

If the independently computed rating matches the published rating, this confirms that the rating was produced by faithful application of the stated methodology to the stated data — not influenced by the enrichment engagement.

For the technical architecture ensuring rating independence (Chinese Wall), see Rating Independence.

Footnotes​

  1. TrackForge currently uses the Bitcoin blockchain via the OpenTimestamps protocol. ↩

Last updated on