# TrackForge Golden Record Certification — Complete Methodology Documentation
> This document contains the full certification methodology documentation for TrackForge's Golden Record Certification system. It is intended for LLM context and detailed reference.
> For a summary, see [llms.txt](https://trackforge.studio/llms.txt)
> For the interactive documentation, see [trackforge.studio/certification](https://trackforge.studio/certification/)
---
# Overview
# What is Golden Record Certification?
TrackForge is a music metadata management platform built for royalty collection and rights management. It ingests catalogue data, enriches it against multiple authoritative sources, resolves conflicts, and produces verified metadata records ready for commercial use.
**Golden Record Certification** is the process by which TrackForge cryptographically certifies that a metadata record has been through this full verification pipeline and met all quality thresholds. Each certified record is anchored to the Bitcoin blockchain, creating an independently verifiable, tamper-proof attestation of the metadata's state at a specific point in time.
## Certification tiers
TrackForge classifies every certified track into one of four tiers based on verification depth:
| Tier | What it means |
|:-----|:-------------|
| **Gold** | Fully verified: ISRC + ISWC + duration + writers with IPIs and shares + multi-source corroboration + human review |
| **Silver** | Structurally complete: ISRC + ISWC + duration + writer with IPI. Automated verification, no human review required |
| **Bronze** | Partially enriched: ISRC + duration + at least one of ISWC or writer name. Gaps are documented transparently |
| **Declared** | User-submitted metadata, cryptographically timestamped but **not independently verified** by TrackForge |
The tier assigned to a track reflects how thoroughly it has been independently verified. Tracks that do not meet even the minimum requirements (no valid ISRC) are routed to an investigation queue for manual resolution or additional enrichment.
For detailed tier definitions and the decision process, see **[Certification Tiers](/methodology/golden-record-selection)**.
## What does certification prove?
TrackForge certification is best understood through analogy. Consider **title insurance** in property transactions: a title insurer does not guarantee that no competing claim to the property exists anywhere in the world. Instead, they attest that a thorough, documented search was conducted and no issues were found.
TrackForge certification works the same way:
> "We searched thoroughly using a documented process and found no issues" — not "there are definitively no issues."
The certification attests to the **rigour of the verification process**, not to absolute legal truth. It confirms that the metadata was enriched against multiple authoritative sources, that conflicts were detected and resolved, that quality gates were passed, and that — for B2B engagements — a human operator reviewed and approved the result.
## The certification pipeline
The end-to-end process transforms raw catalogue data into a blockchain-anchored certification. Every step is documented, versioned, and reproducible.
```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e8edf5', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#3d405b', 'lineColor': '#64748b', 'fontFamily': 'Inter, system-ui, sans-serif', 'fontSize': '14px'}}}%%
flowchart TD
A["Catalogue Upload"] --> B["Multi-Source Enrichment"]
B --> C["Cross-Source Validation"]
C --> D["Tier Classification"]
D --> E["Canonicalisation"]
E --> F["SHA-256 Hashing"]
F --> G["Merkle Tree Construction"]
G --> H["Bitcoin Blockchain Anchor"]
H --> I["Certificate Issued"]
style A fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style B fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style C fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style D fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style E fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style F fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style G fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style H fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style I fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
```
1. **Catalogue Upload** — Raw metadata is ingested from the catalogue owner's files.
2. **Multi-Source Enrichment** — Each track passes through a waterfall of authoritative sources: Spotify, MusicBrainz, Discogs, Last.fm, PRS for Music, MLC, and additional PROs.
3. **Cross-Source Validation** — Where sources disagree, conflicts are detected, scored by confidence, and resolved algorithmically or flagged for human review.
4. **Tier Classification** — Each track is evaluated against the tier criteria (Gold, Silver, Bronze, Declared) and assigned the highest tier it qualifies for.
5. **Canonicalisation** — Rights-determinative fields are extracted and serialised into a deterministic canonical JSON form.
6. **SHA-256 Hashing** — The canonical JSON is hashed, producing a unique fingerprint of the metadata state.
7. **Merkle Tree Construction** — All track hashes in a certification batch are assembled into a binary Merkle tree, producing a single root hash.
8. **Bitcoin Blockchain Anchor** — The Merkle root is anchored to the Bitcoin blockchain via OpenTimestamps, creating a permanent, tamper-proof timestamp.
9. **Certificate Issued** — The catalogue owner receives a certificate bundle containing the certification details, Merkle proofs, and verification instructions.
## What's next
- **[What Certification Does and Does Not Mean](./scope)** — The precise boundaries of what a TrackForge certification asserts, and what it does not.
- **[Methodology](/methodology)** — The full technical methodology, from enrichment through blockchain anchoring.
---
# What Certification Does and Does Not Mean
This is the single most important page in this documentation for anyone evaluating, relying upon, or presenting a TrackForge certification in a legal or commercial context. It defines the precise boundaries of what certification asserts — and, equally importantly, what it does not.
## What TrackForge certifies
TrackForge certification attests to **process fidelity**. Specifically, each certification confirms:
1. **Pipeline execution** — The track was processed through TrackForge's documented multi-source enrichment pipeline.
2. **Cross-source validation** — Validation was performed across multiple authoritative sources, and conflicts were identified and resolved.
3. **Quality gates passed** — The metadata met all defined quality thresholds (the Golden Record criteria).
4. **Human review** — A trained operator reviewed and approved the certified data (in B2B engagements).
5. **Point-in-time attestation** — The certified metadata was in the stated condition at the stated time.
6. **Cryptographic verifiability** — The certification hash is independently verifiable against a Bitcoin blockchain anchor.
7. **Methodology compliance** — The published certification methodology was followed throughout.
## What TrackForge does NOT certify
TrackForge certification **does not** assert any of the following:
1. **Legal ownership** — Certification does not confirm or establish legal ownership of copyright or neighbouring rights.
2. **Definitive writer splits** — Certification does not assert that writer shares are legally settled or binding.
3. **Absence of future claims** — Certification does not guarantee that no future claim could contradict the certified data.
4. **Upstream accuracy** — Certification does not warrant that no errors exist in the source databases consulted (Spotify, MusicBrainz, PRS, MLC, etc.).
5. **Legal advice** — Certification does not constitute legal advice or a legal opinion.
6. **Substitute for due diligence** — Certification is not a substitute for a formal title search, legal due diligence, or independent legal counsel.
:::caution Disclaimer
TrackForge certification confirms the metadata state verified by TrackForge as of the certified date. It does not constitute legal proof of copyright ownership, authorship rights, or entitlement to royalties. This certification should not be relied upon as a substitute for independent legal advice, formal title searches, or legal due diligence. Liability for the certification service is limited to the fees paid for that service.
:::
## Analogies
Two analogies help clarify the nature and limits of TrackForge certification:
### Title insurance
In property conveyancing, a title insurer conducts a thorough search of land registry records, historical deeds, and encumbrances. The resulting policy attests: "We searched thoroughly using a documented process and found no issues." It does not assert: "There are definitively no issues anywhere in the world."
TrackForge certification works the same way. The certification attests to the rigour and completeness of the verification process — not to absolute legal truth. If a previously unknown claimant surfaces after certification, the certification remains a valid record of what was known and verified at that point in time.
### Credit rating agencies
Moody's or S&P rate a bond based on documented criteria applied consistently. The rating reflects their assessment methodology, not an absolute guarantee of creditworthiness. Similarly, TrackForge certifies metadata based on a published methodology applied consistently. The certification reflects process fidelity, not an absolute guarantee of metadata accuracy.
In both cases, the value lies in the **documented, repeatable, independently verifiable process** — not in a claim of infallibility.
## B2B vs Self-Service certification
TrackForge offers certification at different service tiers. The level of human involvement — and therefore the strength of the attestation — differs between them:
| Aspect | B2B Certification (Tier 2/3) | Self-Service (Tier 1) |
|--------|------------------------------|----------------------|
| **Analogy** | Independent auditor | Notary public |
| **Human review** | Trained operator reviews and approves each track | Automated pipeline only |
| **Conflict resolution** | Operator reviews ambiguous conflicts | Algorithmic resolution only |
| **Attestation strength** | Process fidelity + human verification | Process fidelity only |
| **Use case** | Catalogue acquisitions, dispute evidence, sync licensing | Ongoing catalogue monitoring, internal QA |
| **Suitable for** | Legal proceedings, insurance, due diligence | Internal confidence scoring, trend tracking |
For B2B engagements, TrackForge operates as an **auditor**: a qualified professional examines the evidence and signs off. For self-service, TrackForge operates as a **notary**: it attests that a defined process was followed and records the result, but does not independently evaluate the substance.
Both tiers produce cryptographically verifiable, blockchain-anchored certifications. The difference is in the depth of human scrutiny applied before certification.
## What's next
- **[Who This Documentation Is For](./audience)** — A reading guide for different audiences.
- **[Golden Record Selection](/methodology/golden-record-selection)** — The criteria a track must meet to qualify for certification.
---
# Who This Documentation Is For
This documentation serves multiple audiences with different needs. This page helps you find the sections most relevant to your role.
## Reading paths by role
### Lawyers and legal professionals
You need to understand the precise scope and limitations of certification, how liability is bounded, how personal data is handled, and what the certificate wording means in practice.
**Start here:**
1. [What Certification Does and Does Not Mean](./scope) — The boundaries of what certification asserts
2. [For Lawyers](/for-lawyers) — Certification scope in legal terms, liability and risk allocation, GDPR and data handling, certificate wording, and handling conflicting certifications
**Key concern:** TrackForge certifies process fidelity, not legal ownership. The [scope page](./scope) and [certification scope for lawyers](/for-lawyers/certification-scope) make this distinction explicit.
### Catalogue owners and rights holders
You need to understand what you will receive, how to read your certificate, and how to verify it independently.
**Start here:**
1. [What is Golden Record Certification?](./what-is-certification) — How the system works end-to-end
2. [For Catalogue Owners](/for-catalogue-owners) — Deliverables, reading your certificate, independent verification, the proof bundle, and re-certification
**Key concern:** The [deliverables page](/for-catalogue-owners/deliverables) details exactly what you receive. The [verification page](/for-catalogue-owners/verification) explains how to confirm your certification independently, without relying on TrackForge.
### Engineers and technical auditors
You need API documentation, data format specifications, and cryptographic details to integrate with or audit the certification system.
**Start here:**
1. [Methodology](/methodology) — The full technical methodology from enrichment through anchoring
2. [Technical Reference](/technical) — Verification API, canonical JSON schema, Merkle proof format, OpenTimestamps integration, and data security
**Key concern:** The [canonical JSON schema](/technical/canonical-json-schema) and [Merkle proof format](/technical/merkle-proof-format) define the exact data structures. The [verification API](/technical/verification-api) documents programmatic access.
### Everyone
Regardless of your role, we recommend reading the **Overview** section first (you are here), then the **[Methodology](/methodology)** for the full process description. The [Glossary](/glossary) defines all technical terms used throughout.
## Quick reference: "I want to..."
| I want to... | Read this |
|--------------|-----------|
| Understand what certification is | [What is Golden Record Certification?](./what-is-certification) |
| Know what certification does and does not prove | [What Certification Does and Does Not Mean](./scope) |
| Assess legal risk of relying on a certification | [Certification Scope](/for-lawyers/certification-scope) and [Liability & Risk](/for-lawyers/liability-risk) |
| Understand GDPR implications | [Data Handling & GDPR](/for-lawyers/data-handling-gdpr) |
| Know what I receive as a catalogue owner | [Deliverables](/for-catalogue-owners/deliverables) |
| Read and interpret my certificate | [Reading Your Certificate](/for-catalogue-owners/reading-your-certificate) |
| Verify a certification independently | [Verification](/for-catalogue-owners/verification) |
| Understand when re-certification is needed | [Re-certification](/for-catalogue-owners/recertification) |
| Integrate with the verification API | [Verification API](/technical/verification-api) |
| Audit the cryptographic process | [Hashing](/methodology/hashing), [Merkle Tree](/methodology/merkle-tree), [Blockchain Anchoring](/methodology/blockchain-anchoring) |
| Understand a specific term | [Glossary](/glossary) |
| Present a certification in legal proceedings | [Certificate Wording](/for-lawyers/certificate-wording) and [Proof Bundle](/for-catalogue-owners/proof-bundle) |
| Handle conflicting certifications | [Conflicting Certifications](/for-lawyers/conflicting-certifications) |
---
---
# Methodology
# Certification Tiers
:::info Methodology Version
Methodology Version 2.0 — Effective February 2026
:::
TrackForge classifies every certified track into one of four tiers based on the depth and quality of its verified metadata. The tier assigned to a track reflects how thoroughly it has been independently verified, ranging from **Gold** (the highest standard, with multi-source corroboration and human review) down to **Declared** (user-submitted data that has been cryptographically timestamped but not independently verified).
This tiered model replaces the earlier binary "Golden Record" qualification, which required all four core data points to be present. The original Golden Record criteria are now approximately equivalent to the **Silver** tier. The new model recognises that partial verification still has significant value — a track with a verified ISRC, duration, and identified writer is more useful than an uncertified track, even if an ISWC is not yet available.
## Tier definitions
| Tier | Badge | Requirements | Verification depth |
|:-----|:------|:-------------|:-------------------|
| **Gold** | Gold | ISRC + ISWC + Duration + Writer(s) with Name, IPI, and Role + Shares sum to ~100% (within 0.5%) + 2 or more source corroborations + Human operator review | Full independent verification with human oversight |
| **Silver** | Silver | ISRC + ISWC + Duration + Writer(s) with Name and IPI | Structurally complete automated verification |
| **Bronze** | Bronze | ISRC + Duration + at least one of: ISWC or Writer with name | Partial verification with documented gaps |
| **Declared** | Declared | ISRC present; metadata submitted by the catalogue owner | Cryptographically timestamped but NOT independently verified |
### Gold
The highest certification tier. A Gold track has been verified across multiple authoritative sources, has structurally complete writer ownership data (shares summing to approximately 100%), and has been reviewed and approved by a trained human operator. Gold certification represents the strongest evidentiary standard TrackForge offers.
**All of the following must be satisfied:**
- Valid ISRC (ISO 3901)
- At least one ISWC (ISO 15707)
- Duration recorded in milliseconds
- At least one writer with verified name, IPI number, and role
- Writer shares sum to approximately 100% (tolerance: +/- 0.5%)
- Metadata corroborated by two or more independent authoritative sources
- Human operator review and approval recorded in the audit trail
### Silver
A structurally complete metadata record that has been verified through TrackForge's automated enrichment pipeline. Silver tracks have all core identifiers and at least one verified writer with an IPI number, but may lack complete share data or multi-source corroboration. This tier is equivalent to the original Golden Record standard from Methodology Version 1.0.
**All of the following must be satisfied:**
- Valid ISRC (ISO 3901)
- At least one ISWC (ISO 15707)
- Duration recorded in milliseconds
- At least one writer with verified name and IPI number
### Bronze
A partially enriched metadata record that meets minimum certification requirements. Bronze tracks have core recording identifiers and at least some compositional data, but gaps remain. Those gaps are documented transparently in the certification.
**All of the following must be satisfied:**
- Valid ISRC (ISO 3901)
- Duration recorded in milliseconds
- At least one of the following:
- An ISWC (ISO 15707), **or**
- A writer with a verified name
### Declared
User-submitted metadata that has been cryptographically timestamped by TrackForge but has **not** been independently verified through the enrichment pipeline. Declared tracks have a valid ISRC and the metadata as supplied by the catalogue owner, but TrackForge makes no representation about the accuracy of the submitted data beyond the ISRC.
**Requirements:**
- Valid ISRC present
- Metadata supplied by the submitting party
- NOT independently verified by TrackForge
## Decision process
Each track is evaluated against the tier criteria in order from Gold (highest) to Declared (lowest). The track is assigned the highest tier whose requirements it fully satisfies. Tracks that do not meet even Declared requirements (i.e. no valid ISRC) are routed to the investigation queue.
```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e8edf5', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#3d405b', 'secondaryColor': '#f0ece2', 'secondaryTextColor': '#1e293b', 'tertiaryColor': '#eef2ff', 'lineColor': '#64748b', 'fontFamily': 'Inter, system-ui, sans-serif', 'fontSize': '14px'}}}%%
flowchart TD
A(["Track arrives from enrichment pipeline"]) --> B{"Valid ISRC\npresent?"}
B -- No --> IQ(["Investigation Queue\nRequires manual resolution"])
B -- Yes --> C{"Duration\nrecorded?"}
C -- No --> DEC
C -- Yes --> D{"ISWC or Writer\nwith name?"}
D -- No --> DEC(["Declared Tier\nTimestamped, not verified"])
D -- Yes --> E{"ISWC present AND\nWriter with IPI?"}
E -- No --> BRZ(["Bronze Tier\nPartial verification"])
E -- Yes --> F{"Shares sum ~100% AND\n2+ sources AND\nhuman review?"}
F -- No --> SLV(["Silver Tier\nStructurally complete"])
F -- Yes --> GLD(["Gold Tier\nFull verification"])
style A fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style B fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style C fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style D fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style E fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style F fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style GLD fill:#ffd700,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
style SLV fill:#c0c0c0,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
style BRZ fill:#cd7f32,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
style DEC fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style IQ fill:#f8d7da,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
```
## Why these fields?
Each required field addresses a specific failure mode in the royalty collection chain:
- **Without an ISRC**, the recording cannot be matched to usage reports from streaming platforms, broadcasters, or live performance logs. Royalties for the recording cannot be identified.
- **Without an ISWC**, the recording cannot be linked to the underlying composition. Mechanical royalties (owed to songwriters and publishers) cannot be routed, even if the recording itself is identified.
- **Without duration**, pro-rata calculations used by many collection societies to divide royalty pools cannot be performed accurately.
- **Without a writer IPI**, there is no internationally standardised way to identify the rights holder. Even if royalties are collected, they cannot be distributed to the correct party.
- **Without complete shares**, it is impossible to confirm that all rights holders have been identified. Missing share allocations suggest unidentified parties.
## Tier promotion
Tracks are not permanently fixed at their assigned tier. As additional data becomes available through enrichment, manual resolution, or client submissions, a track can be **promoted** to a higher tier.
Common promotion paths:
| From | To | What's needed |
|:-----|:---|:--------------|
| **Declared** | **Bronze** | Duration confirmed + ISWC or writer name identified through enrichment |
| **Bronze** | **Silver** | Missing ISWC or writer IPI obtained from a PRO database or manual research |
| **Silver** | **Gold** | Complete share data, second source corroboration, and human operator review |
When a track is promoted, it is re-certified at the new tier. The new certification is cryptographically linked to its predecessor via the [version chain](../technical/merkle-proof-format), preserving the full audit history. The original lower-tier certification remains valid as a record of the metadata at that earlier point in time.
## Tracks in the investigation queue
Tracks that do not meet even the minimum requirements for Declared certification (i.e. no valid ISRC) are routed to the **investigation queue**, where they may be resolved through:
- **Additional enrichment** — further source consultations may supply missing data
- **Manual resolution** — an operator identifies and fills gaps using PRO databases, catalogue owner records, or direct research
- **Client data requests** — the catalogue owner is asked to supply missing identifiers
Once sufficient criteria are satisfied, the track is re-evaluated and assigned the appropriate tier.
## Related methodology pages
- **[Enrichment & Cross-Source Validation](./enrichment-validation)** — How tracks are enriched against multiple authoritative sources before tier evaluation
- **[Canonicalisation](./canonicalization)** — The next step after tier assignment: extracting and serialising rights-critical fields
- **[Independent Verification](./independent-verification)** — How any party can verify a certified track without TrackForge access
---
# Enrichment & Cross-Source Validation
:::info Methodology Version
Methodology Version 1.0 — Effective February 2026
:::
Before a track can be evaluated against the [Golden Record criteria](./golden-record-selection), it must pass through TrackForge's multi-source enrichment pipeline. This pipeline consults authoritative music metadata databases in a defined priority order, detects conflicts between sources, and resolves them either algorithmically or through human review.
## Source waterfall
Each track passes through a waterfall of authoritative sources. Sources are consulted in priority order, with later sources filling data gaps left by earlier ones:
| Priority | Source | Data Provided |
|:--|:--|:--|
| 1 | **Spotify** | Track metadata, artist information, album context, ISRC validation |
| 2 | **MusicBrainz** | ISWC linkages, recording/release relationships, artist credits |
| 3 | **Discogs** | Release metadata, label information, production credits |
| 4 | **Last.fm** | Artist metadata, tag-based genre classification |
| 5 | **PRS for Music** | Writer and publisher data, IPI numbers, work registrations |
| 6 | **MLC** (Mechanical Licensing Collective) | US mechanical rights data, writer share allocations |
| 7 | **Additional PROs** | GEMA, SACEM, JASRAC, and other societies where available |
The waterfall is designed so that the most broadly available sources are consulted first (streaming platform metadata), followed by progressively more specialised and authoritative sources (collection society databases). Writer and publisher information from PROs at priorities 5-7 is treated as higher-authority than equivalent data from streaming services.
```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e8edf5', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#3d405b', 'secondaryColor': '#f0ece2', 'secondaryTextColor': '#1e293b', 'tertiaryColor': '#eef2ff', 'lineColor': '#64748b', 'fontFamily': 'Inter, system-ui, sans-serif', 'fontSize': '14px'}}}%%
flowchart LR
T(["Track"]) --> S1["Spotify"]
S1 --> S2["MusicBrainz"]
S2 --> S3["Discogs"]
S3 --> S4["Last.fm"]
S4 --> S5["PRS / MLC / PROs"]
S5 --> CD{"Conflicts\ndetected?"}
CD -- No --> GR(["Enriched track\nready for evaluation"])
CD -- Yes --> CR["Conflict\nResolution"]
CR --> GR
S1 -. "data found" .-> |"fill gaps"| S2
S2 -. "data found" .-> |"fill gaps"| S3
S3 -. "data found" .-> |"fill gaps"| S4
S4 -. "data found" .-> |"fill gaps"| S5
style T fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style S1 fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style S2 fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style S3 fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style S4 fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style S5 fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style CD fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style CR fill:#f8d7da,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style GR fill:#d4edda,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
```
## Conflict resolution
When sources provide contradictory information for the same field (for example, different writer splits from PRS and MLC), the conflict resolution process follows a defined sequence:
1. **Detection** — Conflicts are detected automatically by comparing field values across all sources that returned data for a track. Any divergence in rights-critical fields triggers a conflict record.
2. **Scoring** — Each source carries a reliability weight for each field type. PRO databases are weighted more heavily for writer and publisher information than streaming platform metadata. The confidence score reflects both the source's general reliability and the specificity of the match.
3. **Algorithmic resolution** — Where one source's confidence clearly exceeds another's (for example, a PRO's own registration data versus a streaming service's inferred credits), the higher-confidence value is selected automatically. The resolution is logged with the confidence differential and the rule applied.
4. **Human review** — Where confidence is ambiguous or the stakes are high (for example, conflicting writer share allocations with similar confidence from two PROs), the conflict is flagged for operator review. No automatic resolution is applied.
All conflicts and their resolutions are recorded in the enrichment conflict log. Each record captures:
- The conflicting values from each source
- The confidence scores assigned to each
- The resolution chosen (algorithmic or operator)
- The reasoning or rule applied
- The timestamp and, for operator resolutions, the operator identity
## Operator verification (B2B only)
For B2B certification engagements, enrichment is not fully automated. A trained operator performs the following verification steps before a track proceeds to [Golden Record evaluation](./golden-record-selection):
1. **Completeness review** — confirms that all fields expected from the enrichment waterfall have been populated or explicitly marked as unavailable
2. **Writer/publisher cross-check** — validates writer and publisher information against PRO databases, checking IPI numbers, name spellings, and role assignments
3. **ISRC-to-ISWC linkage validation** — confirms that recording-to-composition linkages are correct, catching cases where a recording has been linked to the wrong underlying work
4. **Conflict review** — reviews and approves all algorithmically-resolved conflicts, with the ability to override any automatic resolution
5. **Golden Record threshold confirmation** — confirms that the track meets all [qualification criteria](./golden-record-selection)
6. **Certification approval** — formally approves the track for certification
All operator actions are logged with timestamp, operator identity, and the action taken. This audit trail is included in the [certification proof bundle](./independent-verification) and is available for review.
## Related methodology pages
- **[Golden Record Selection](./golden-record-selection)** — The completeness criteria a track must meet after enrichment
- **[Canonicalisation](./canonicalization)** — How enriched metadata is transformed into a deterministic canonical form
- **[Re-Certification](./recertification)** — How metadata changes (including new enrichment data) trigger re-certification
---
# Canonicalisation
:::info Methodology Version
Methodology Version 1.0 — Effective February 2026
:::
Once a track has been enriched, validated, and confirmed as a [Golden Record](./golden-record-selection), its metadata must be transformed into a **canonical form** — a single, deterministic representation that always produces the same output for the same underlying data, regardless of when or how the data was collected.
Canonicalisation is the prerequisite for [hashing](./hashing). Without a deterministic representation, identical metadata could produce different hashes depending on field ordering, whitespace, or serialisation choices, undermining the entire certification chain.
## Field selection
Only **rights-determinative fields** are included in the canonical form. Fields that relate to processing history, engagement metrics, or internal workflow state are excluded.
| Included | Excluded |
|:--|:--|
| ISRC | Engagement metrics (play counts, listener statistics) |
| ISWC(s) | Source-specific identifiers (Spotify URI, MusicBrainz MBID) |
| Title | Confidence scores from enrichment |
| Artist | Internal workflow state |
| Writers (name, IPI, role, share %) | Enrichment log metadata |
| Performers (name, role) | Processing timestamps (except certification date) |
| Release date | Source provenance records |
| Duration (milliseconds) | |
| Territory registrations | |
| Publisher chains | |
This separation ensures that the [hash](./hashing) represents the **substance of the rights claim** — the data that determines who is owed what — rather than artefacts of how the data was assembled. Two tracks with identical rights-critical data will always produce the same hash, even if they were enriched at different times or through different source orderings.
## Deterministic serialisation
The canonical form is constructed through a strictly defined serialisation process:
```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e8edf5', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#3d405b', 'secondaryColor': '#f0ece2', 'secondaryTextColor': '#1e293b', 'tertiaryColor': '#eef2ff', 'lineColor': '#64748b', 'fontFamily': 'Inter, system-ui, sans-serif', 'fontSize': '14px'}}}%%
flowchart TD
A(["Golden Record\nmetadata"]) --> B["Extract rights-critical\nfields only"]
B --> C["Sort all keys\nalphabetically"]
C --> D["Normalise writers:\nsort by IPI, then name"]
D --> E["Normalise performers:\nsort by role, then name"]
E --> F["Serialise as\ncompact JSON"]
F --> G(["Canonical form\nready for hashing"])
style A fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style B fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style C fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style D fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style E fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style F fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style G fill:#d4edda,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
```
### Step-by-step process
1. **Extract rights-critical fields** — Only the fields listed in the "Included" column above are retained. All other fields are discarded. Null or empty values are removed.
2. **Sort all keys alphabetically** — The top-level keys of the data structure are sorted in lexicographic order. This eliminates variation caused by different insertion orderings in the source data.
3. **Normalise writer arrays** — Writers are sorted first by IPI number (lexicographic), then by name. Each writer entry is normalised to a consistent structure: `{name, ipi, role, share}`.
4. **Normalise performer arrays** — Performers are sorted by role, then by name.
5. **Sort nested structures** — Territory registrations, publisher chains, and ISWC collections are sorted by their respective keys.
6. **Serialise as compact JSON** — The data is serialised using the following parameters:
```python
json.dumps(data, sort_keys=True, separators=(',', ':'), ensure_ascii=True)
```
This produces compact JSON with no whitespace between elements, no trailing newlines, and all non-ASCII characters escaped to their Unicode code points. The `sort_keys=True` parameter provides a secondary guarantee of key ordering.
The resulting string is encoded as **UTF-8** before being passed to the [hashing step](./hashing).
### Why these choices matter
| Decision | Rationale |
|:--|:--|
| `sort_keys=True` | Eliminates ordering variation across different systems and languages |
| `separators=(',', ':')` | Removes all optional whitespace, ensuring byte-identical output |
| `ensure_ascii=True` | Normalises character encoding, preventing Unicode normalisation form differences |
| UTF-8 encoding | Universally supported encoding standard |
| Writer sort by IPI then name | IPI is the most stable identifier; name provides a tiebreaker |
| Null/empty removal | Prevents spurious hash differences from absent-vs-null distinctions |
## Verification
The canonical form is included in the [certification proof bundle](./independent-verification), allowing any party to:
1. Inspect the exact data that was certified
2. Re-run the serialisation process independently
3. Confirm that the canonical JSON produces the expected [SHA-256 hash](./hashing)
Because the serialisation parameters are fully specified and use standard library functions available in every major programming language, independent reproduction does not require any TrackForge software.
## Related methodology pages
- **[Golden Record Selection](./golden-record-selection)** — The completeness criteria that must be met before canonicalisation
- **[Hashing](./hashing)** — The next step: computing a SHA-256 digest of the canonical form
- **[Independent Verification](./independent-verification)** — How third parties can reproduce the canonical form and verify the hash
---
# Hashing
:::info Methodology Version
Methodology Version 1.0 — Effective February 2026
:::
Once a Golden Record has been transformed into its [canonical form](./canonicalization), the next step is to compute a cryptographic hash — a fixed-length digest that uniquely represents the metadata state. This hash is the foundation upon which [Merkle tree construction](./merkle-tree) and [blockchain anchoring](./blockchain-anchoring) are built.
## Algorithm: SHA-256
TrackForge uses **SHA-256** (Secure Hash Algorithm 256-bit), as specified in FIPS 180-4 (National Institute of Standards and Technology). SHA-256 was selected for the following properties:
| Property | Description |
|:--|:--|
| **Deterministic** | Identical input always produces identical output. The same canonical JSON will always produce the same hash, regardless of when or where the computation is performed. |
| **Collision-resistant** | It is computationally infeasible to find two different inputs that produce the same hash. No two distinct metadata states will share a hash. |
| **Irreversible** | The hash cannot be reversed to recover the original data. The metadata content cannot be derived from the hash alone. |
| **Widely standardised** | SHA-256 is supported by every major cryptographic library, every major programming language, and every major operating system. Independent verification requires no specialised software. |
## Process
The hashing step takes the [canonical JSON string](./canonicalization) and produces a 64-character hexadecimal digest:
1. The canonical JSON string (produced by deterministic serialisation) is encoded as **UTF-8 bytes**
2. The SHA-256 hash function is applied to the byte sequence
3. The resulting 256-bit digest is represented as a **64-character lowercase hexadecimal string**
```
Input: UTF-8 encoded canonical JSON string
Output: 64-character hexadecimal SHA-256 digest
```
### Example
Given a canonical JSON string for a track, the hash computation produces a digest such as:
```
Canonical JSON (truncated):
{"artist":"Iron Maiden","certification_version":"1.0","duration_ms":437000,"isrc":"GBAYE9200143",...}
SHA-256 hash:
a3c1f7e2b9d4056831ca9e7f2b8a1d3c5e4f6a7b8c9d0e1f2a3b4c5d6e7f8a9b
```
Any change to the underlying data — even a single character — produces a completely different hash. For example, correcting a writer's share from 50.00% to 50.01% would produce an entirely unrelated 64-character digest. There is no relationship between the magnitude of the change and the magnitude of the hash difference.
## Why hashing matters for certification
The hash serves three purposes in the certification pipeline:
1. **Integrity verification** — Anyone with the canonical JSON can recompute the hash and confirm it matches the certified value. If even one byte of the metadata has been altered, the hash will not match.
2. **Compact commitment** — A 64-character string represents an arbitrarily large metadata record. This compact representation is what gets assembled into the [Merkle tree](./merkle-tree) and ultimately [anchored to the blockchain](./blockchain-anchoring).
3. **Version chain linkage** — When metadata is [re-certified](./recertification), the new certification version references the hash of the previous version, forming a cryptographic linked list. This chain cannot be tampered with: modifying any historical version would change its hash, breaking the chain.
## Independent reproducibility
SHA-256 is available in every major programming environment:
- **Python:** `hashlib.sha256(data.encode('utf-8')).hexdigest()`
- **JavaScript:** `crypto.subtle.digest('SHA-256', data)` (Web Crypto API)
- **Command line:** `echo -n 'data' | sha256sum`
- **Go:** `sha256.Sum256([]byte(data))`
- **Java:** `MessageDigest.getInstance("SHA-256")`
No TrackForge software is required to verify a hash. Any party with the canonical JSON (included in the [proof bundle](./independent-verification)) can independently compute the SHA-256 digest and confirm it matches the certified hash.
## Related methodology pages
- **[Canonicalisation](./canonicalization)** — How the input to the hash function is constructed
- **[Merkle Tree Construction](./merkle-tree)** — How individual track hashes are assembled into a single batch commitment
- **[Independent Verification](./independent-verification)** — How third parties reproduce the hash and verify the certification
---
# Merkle Tree Construction
:::info Methodology Version
Methodology Version 1.0 — Effective February 2026
:::
After each track in a certification batch has been [canonicalised](./canonicalization) and [hashed](./hashing), the individual track hashes are assembled into a **binary Merkle tree**. This data structure allows a single root hash to cryptographically commit to every track in the batch, while still permitting each track to be independently verified.
## What is a Merkle tree?
A Merkle tree is a binary tree in which every leaf node contains a data hash and every non-leaf node contains the hash of its two children. The single hash at the top of the tree — the **Merkle root** — is a compact commitment to the entire dataset. Any change to any leaf (any track's metadata) propagates upward through the tree, producing a different root hash.
```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e8edf5', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#3d405b', 'secondaryColor': '#f0ece2', 'secondaryTextColor': '#1e293b', 'tertiaryColor': '#eef2ff', 'lineColor': '#64748b', 'fontFamily': 'Inter, system-ui, sans-serif', 'fontSize': '14px'}}}%%
graph TD
Root["Merkle Root
SHA-256(H_AB + H_CD)"]
HAB["Parent Node
SHA-256(H_A + H_B)"]
HCD["Parent Node
SHA-256(H_C + H_D)"]
HA["Track A Hash
a3c1f7...8a9b"]
HB["Track B Hash
b2d4e6...7c3f"]
HC["Track C Hash
c5f8a1...2e6d"]
HD["Track D Hash
d7b3c9...4f1a"]
Root --> HAB
Root --> HCD
HAB --> HA
HAB --> HB
HCD --> HC
HCD --> HD
style Root fill:#eef2ff,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
style HAB fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style HCD fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style HA fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style HB fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style HC fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style HD fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
```
In this example, the Merkle root commits to all four tracks. If Track B's metadata were altered, its leaf hash would change, which would change `H_AB`, which would change the root — making the tampering immediately detectable.
## Construction process
### 1. Sort leaf hashes
All track hashes within the certification batch are sorted **lexicographically** (alphabetical order of their hexadecimal representations). This ensures that the same set of tracks always produces the same tree structure, regardless of the order in which tracks were processed.
### 2. Build the tree bottom-up
Adjacent pairs of hashes are concatenated (left + right) and hashed with SHA-256 to form parent nodes:
```
parent_hash = SHA-256(left_child_hash + right_child_hash)
```
This process repeats upward through each layer until a single root hash remains.
### 3. Odd-number duplication rule
If any layer contains an odd number of nodes, the last node is duplicated to form a pair with itself. This ensures the tree is always a complete binary tree. The duplicated node is hashed with itself:
```
parent_hash = SHA-256(node_hash + node_hash)
```
### 4. Root hash
The final single hash at the top of the tree is the **Merkle root**. This 64-character hexadecimal string is what gets [anchored to the Bitcoin blockchain](./blockchain-anchoring).
## Inclusion proofs
A key property of Merkle trees is that any individual leaf can be verified against the root using a compact **inclusion proof** — a small set of sibling hashes from the leaf to the root.
For example, to prove that Track A is part of the certified batch, the proof consists of:
1. Track A's own hash (the leaf)
2. Track B's hash (the sibling at the leaf layer)
3. `H_CD` (the sibling at the next layer up)
With these three values, a verifier can reconstruct the path from Track A's leaf to the Merkle root:
```
Step 1: SHA-256(Track_A_hash + Track_B_hash) → H_AB
Step 2: SHA-256(H_AB + H_CD) → Root
Step 3: Compare computed root with the published root
```
If the computed root matches the [blockchain-anchored](./blockchain-anchoring) root, the track is confirmed as part of the certified batch.
### Proof size
The inclusion proof grows logarithmically with the number of tracks. For a catalogue of 10,000 tracks, each proof requires approximately 14 sibling hashes (log2(10,000) ≈ 13.3) — less than 1 KB of data, regardless of the catalogue size. This makes individual track verification efficient even for very large catalogues.
## Why a Merkle tree?
| Benefit | Explanation |
|:--|:--|
| **Single blockchain transaction** | The entire catalogue batch — regardless of size — is represented by one root hash, requiring only one [blockchain anchor](./blockchain-anchoring) |
| **Individual track verification** | Each track can be verified independently using its compact inclusion proof, without access to any other track's data |
| **Tamper detection** | Any modification to any track changes the root hash, making it impossible to alter a single track without invalidating the entire batch |
| **Scalability** | A 10,000-track catalogue and a 10-track catalogue both produce one root hash and one blockchain transaction |
| **Privacy** | An inclusion proof reveals only the sibling hashes along the path, not the data of other tracks in the batch |
## Related methodology pages
- **[Hashing](./hashing)** — How individual track hashes (the Merkle leaves) are computed
- **[Blockchain Anchoring](./blockchain-anchoring)** — How the Merkle root is anchored to the Bitcoin blockchain
- **[Independent Verification](./independent-verification)** — How Merkle proofs are used in the verification process
---
# Blockchain Anchoring
:::info Methodology Version
Methodology Version 1.0 — Effective February 2026
:::
Once the [Merkle tree](./merkle-tree) has been constructed and a single root hash produced for the certification batch, that root hash is anchored to the **Bitcoin blockchain** via the OpenTimestamps protocol. This creates a permanent, tamper-proof record that the hash existed at a specific point in time — a record that is independent of TrackForge and verifiable by anyone.
## The OpenTimestamps protocol
OpenTimestamps is an open protocol for creating timestamps backed by the Bitcoin blockchain. The process works as follows:
1. **Submission** — The Merkle root hash is submitted to one or more OpenTimestamps calendar servers as a raw 32-byte SHA-256 digest.
2. **Aggregation** — Calendar servers aggregate multiple timestamp requests from different parties into their own Merkle tree. This aggregation means that many timestamps share a single Bitcoin transaction, making the process cost-efficient.
3. **Bitcoin transaction** — The calendar server's aggregated Merkle root is embedded in a Bitcoin transaction, which is broadcast to the Bitcoin network. Calendar servers typically commit once per Bitcoin block (approximately every 10 minutes).
4. **Confirmation** — Once the Bitcoin transaction is included in a confirmed block, the timestamp is permanent. The block number, transaction ID, and confirmation timestamp are recorded.
5. **Proof upgrade** — The initial proof returned by the calendar server is a "pending" proof. Once the Bitcoin transaction is confirmed (typically within 1-3 hours), the proof can be "upgraded" to include the full path from the submitted hash to the Bitcoin block header.
## Why Bitcoin?
| Property | Significance for certification |
|:--|:--|
| **Immutability** | Once confirmed in a block, Bitcoin transactions cannot be altered, reversed, or deleted. The timestamp is permanent for as long as the Bitcoin network exists. |
| **Independence** | Verification does not require TrackForge to exist or to cooperate. Any party with a Bitcoin node or access to a public blockchain explorer can confirm the anchor. |
| **Transparency** | The Bitcoin blockchain is a public ledger. Anyone can inspect the transaction and verify that it contains the expected hash commitment. |
| **Cost efficiency** | Through the OpenTimestamps aggregation mechanism and TrackForge's own Merkle tree, a single Bitcoin transaction covers an entire catalogue batch — regardless of whether it contains 10 tracks or 100,000 tracks. |
| **Decentralisation** | No single entity controls the Bitcoin network. The timestamp does not depend on the continued operation of any single company, government, or institution. |
## What is recorded on the blockchain
The Bitcoin blockchain anchor contains **only the Merkle root hash** — a 64-character hexadecimal string derived from the [Merkle tree](./merkle-tree). No personal data, no metadata content, no track titles, no writer names, no IPI numbers, and no commercially sensitive information is written to the blockchain.
The relationship between the Merkle root and the individual track data is established through the [inclusion proofs](./merkle-tree#inclusion-proofs) stored in the certification database and proof bundles, not through the blockchain itself.
## Proof data
Each blockchain anchor produces an OpenTimestamps proof file (`.ots` format). This binary file contains the cryptographic path from the submitted hash, through the calendar server's aggregation tree, to the Bitcoin block header. The proof file is:
- Included in the certification proof bundle delivered to the catalogue owner
- Stored in the certification database for future verification
- Self-contained: it can be verified using the `ots` command-line tool or any compatible verifier, without contacting TrackForge or the calendar server
## Anchoring record
For each certification batch, TrackForge records:
| Field | Description |
|:--|:--|
| **Chain** | The blockchain used (Bitcoin) |
| **Status** | Pending, confirmed, or local-only |
| **Submitted at** | UTC timestamp of submission to calendar server |
| **Calendar URL** | Which OpenTimestamps calendar server accepted the submission |
| **Transaction ID** | The Bitcoin transaction ID (once confirmed) |
| **Block number** | The Bitcoin block number (once confirmed) |
| **Block timestamp** | The UTC timestamp of the confirming block |
| **Proof data** | The binary OpenTimestamps proof file |
## Graceful degradation
If all OpenTimestamps calendar servers are unreachable at the time of certification (a rare but possible scenario, as calendar servers are volunteer-operated), the system degrades gracefully:
- The certification proceeds with a **local-only** status
- The Merkle root, canonical JSON, and all other certification data are stored normally
- The blockchain anchor is retried when calendar servers become available
- Local-only certifications are clearly marked and do not claim blockchain verification until the anchor is confirmed
This ensures that certification is never blocked by transient network issues, while maintaining transparency about the anchoring status.
## Related methodology pages
- **[Merkle Tree Construction](./merkle-tree)** — How the root hash that gets anchored is produced
- **[Independent Verification](./independent-verification)** — How third parties verify the blockchain anchor
- **[Hashing](./hashing)** — The SHA-256 algorithm used throughout the pipeline, including by Bitcoin itself
---
# Independent Verification
:::info Methodology Version
Methodology Version 1.0 — Effective February 2026
:::
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.
```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e8edf5', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#3d405b', 'secondaryColor': '#f0ece2', 'secondaryTextColor': '#1e293b', 'tertiaryColor': '#eef2ff', 'lineColor': '#64748b', 'fontFamily': 'Inter, system-ui, sans-serif', 'fontSize': '14px'}}}%%
flowchart TD
S(["Start verification"]) --> A["Step 1: Re-compute\nSHA-256 hash of\ncanonical JSON"]
A --> B{"Hash matches\ncertified value?"}
B -- No --> F(["VERIFICATION FAILED\nMetadata has been altered"])
B -- Yes --> C["Step 2: Verify\nMerkle inclusion proof\nagainst root hash"]
C --> D{"Proof valid?"}
D -- No --> F
D -- Yes --> E["Step 3: Confirm\nMerkle root in referenced\nBitcoin transaction"]
E --> G{"Anchor\nconfirmed?"}
G -- No --> F
G -- Yes --> V(["VERIFIED\nMetadata integrity confirmed"])
style S fill:#f0ece2,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style A fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style B fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style C fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style D fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style E fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style G fill:#eef2ff,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style V fill:#d4edda,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
style F fill:#f8d7da,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
```
### Step 1: Re-compute the hash
Take the canonical JSON string (included in the certification proof bundle) and compute its SHA-256 hash using any standard implementation:
```
SHA-256( canonical_json_bytes ) → 64-character hex digest
```
Compare the computed digest with the `record_hash` stated in the certificate. If they match, the canonical JSON has not been altered since certification. If they do not match, the metadata 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](./merkle-tree#inclusion-proofs): 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 Bitcoin transaction. This can be done using:
- **Any public blockchain explorer** (e.g., blockstream.info, mempool.space)
- **A local Bitcoin 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 Bitcoin block header. Verification confirms that the hash was committed to the blockchain 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:
| Component | Purpose |
|:--|:--|
| **Canonical JSON** (per track) | The exact data that was hashed; input to Step 1 |
| **Record hash** (per track) | The SHA-256 digest to verify against |
| **Merkle inclusion proof** (per track) | Sibling hashes and directions for Step 2 |
| **Merkle root** | The batch-level commitment anchored to the blockchain |
| **OpenTimestamps proof file** (`.ots`) | Complete cryptographic path to the Bitcoin block header |
| **Bitcoin transaction ID** | Reference for blockchain explorer verification |
| **Block number and timestamp** | When the anchor was confirmed |
| **Operator audit trail** | Record of human review actions (B2B engagements) |
| **Methodology version** | Which version of this methodology governed the certification |
The proof bundle is self-contained. If TrackForge ceased to exist, a verifier with only the proof bundle and access to the Bitcoin 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 Bitcoin blockchain (Step 3)
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](/overview/scope) for the precise boundaries of what certification asserts.
## Related methodology pages
- **[Hashing](./hashing)** — The SHA-256 algorithm used in Step 1
- **[Merkle Tree Construction](./merkle-tree)** — The tree structure and inclusion proofs used in Step 2
- **[Blockchain Anchoring](./blockchain-anchoring)** — The OpenTimestamps protocol verified in Step 3
- **[Re-Certification](./recertification)** — How verification applies to tracks with multiple certification versions
---
# Re-Certification
:::info Methodology Version
Methodology Version 1.0 — Effective February 2026
:::
Music metadata is not static. Writer splits are corrected by PROs, contractual updates reassign shares, disputes are resolved, and enrichment sources provide improved data over time. TrackForge's re-certification process handles these changes while maintaining the integrity and verifiability of the full certification history.
## When re-certification occurs
Re-certification is triggered by any material change to a track's rights-critical metadata. The defined trigger categories are:
| Trigger | Description | Example |
|:--|:--|:--|
| **PRO correction** | A collection society updates its records for the work | PRS corrects a writer's share allocation from 50% to 33.33% |
| **Contractual update** | A rights transfer, reversion, or new agreement changes ownership | Publisher acquires a catalogue and writer shares are reassigned |
| **Dispute resolution** | A dispute over credits or shares is formally resolved | A co-writer's claim is accepted and added to the record |
| **Administrative correction** | A data error is identified and corrected | A misspelt writer name or incorrect IPI number is fixed |
| **Re-enrichment** | New or updated data becomes available from enrichment sources | MusicBrainz adds an ISWC that was previously missing |
Re-certification is **never automatic**. Every re-certification requires human operator review, regardless of the trigger. This ensures that metadata changes are intentionally approved, not silently propagated.
## The version chain
Each re-certification creates a new version of the track's certification, linked to its predecessor by hash. This forms a **cryptographic linked list** — a chain in which each version references the hash of the version before it.
```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#e8edf5', 'primaryTextColor': '#1a1a2e', 'primaryBorderColor': '#3d405b', 'secondaryColor': '#f0ece2', 'secondaryTextColor': '#1e293b', 'tertiaryColor': '#eef2ff', 'lineColor': '#64748b', 'fontFamily': 'Inter, system-ui, sans-serif', 'fontSize': '14px'}}}%%
graph LR
V1["Version 1
2026-02-01
a3c1f7...8a9b
Initial certification"]
V2["Version 2
2026-04-15
b2d4e6...7c3f
prev: a3c1f7...8a9b
PRO correction"]
V3["Version 3
2026-08-22
c5f8a1...2e6d
prev: b2d4e6...7c3f
Contractual update"]
V1 -->|"hash chain"| V2
V2 -->|"hash chain"| V3
style V1 fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style V2 fill:#e8edf5,stroke:#3d405b,stroke-width:1px,color:#1a1a2e
style V3 fill:#eef2ff,stroke:#3d405b,stroke-width:2px,color:#1a1a2e
```
In this example:
- **Version 1** is the initial certification. Its `previous_version_hash` is null.
- **Version 2** was triggered by a PRO correction. Its `previous_version_hash` is the hash of Version 1.
- **Version 3** (current) was triggered by a contractual update. Its `previous_version_hash` is the hash of Version 2.
### Chain integrity
The version chain has a critical property: **no version can be inserted, removed, or altered without detection**. Modifying any version's metadata would change its hash, which would break the chain linkage in the subsequent version. This can be verified by walking the chain from the latest version back to Version 1 and confirming that each `previous_version_hash` matches the preceding version's `record_hash`.
TrackForge provides automated chain integrity verification that checks:
- Version 1 has no predecessor (`previous_version_hash` is null)
- Each subsequent version's `previous_version_hash` matches the preceding version's `record_hash`
- Version numbers are sequential with no gaps
- Exactly one version is marked as current
## Full pipeline re-run
Re-certification is not a patch or a delta. Each re-certification runs the **entire certification pipeline** from the beginning:
1. **Enrichment** — The track is re-enriched against all sources in the [waterfall](./enrichment-validation), incorporating any new or updated data
2. **Operator review** — A human operator reviews the changes, confirms their correctness, and approves the re-certification
3. **Canonicalisation** — The updated metadata is [canonicalised](./canonicalization) using the same deterministic process
4. **Hashing** — A new [SHA-256 hash](./hashing) is computed from the updated canonical form
5. **Merkle tree** — The new hash is included in a [Merkle tree](./merkle-tree) with other tracks in the re-certification batch
6. **Blockchain anchoring** — The new Merkle root is [anchored to the Bitcoin blockchain](./blockchain-anchoring) via OpenTimestamps
This full re-run ensures that re-certified data receives the same level of verification as initial certifications. There are no shortcuts.
## Previous versions remain valid
When a track is re-certified, the previous version is **not invalidated or deleted**. It remains a valid, independently verifiable record of the metadata state at its certified date. The previous version is marked as superseded (with a `superseded_at` timestamp) but its hash, Merkle proof, and blockchain anchor continue to be verifiable.
This is intentional. The previous version is a historical record: it attests that the metadata was in a specific state at a specific time. That attestation remains true even after the metadata has changed. A verifier examining the full version chain can see exactly how the metadata evolved over time, when each change occurred, and what triggered it.
## Chain of title at the data level
The version chain constitutes a **chain of title at the data level**: a cryptographically-linked, independently verifiable history of how a track's rights-critical metadata evolved over time. Each link in the chain records:
- The exact metadata state (via the canonical JSON and hash)
- When the certification was issued
- What triggered the change
- Whether the change was material or administrative
- Who approved it (via the operator audit trail)
- A blockchain-anchored timestamp proving when the certification existed
For parties conducting due diligence on a catalogue — business affairs teams, sync licensing departments, dispute lawyers, insurers — this chain provides a structured, verifiable record of the catalogue's metadata history that would otherwise require extensive manual research.
## Change categories
Each re-certification is classified into one of two categories:
| Category | Definition | Examples |
|:--|:--|:--|
| **Material** | Changes to rights-determinative data that affect royalty routing or ownership | Writer share changes, new writer added, publisher assignment, ISWC correction |
| **Administrative** | Corrections that do not affect the substance of the rights claim | Name spelling correction, IPI format normalisation |
Both categories result in a new certification version with a new hash and blockchain anchor. The distinction is recorded for audit purposes and to help downstream consumers assess the significance of changes.
## Related methodology pages
- **[Golden Record Selection](./golden-record-selection)** — The completeness criteria re-evaluated during re-certification
- **[Enrichment & Cross-Source Validation](./enrichment-validation)** — The enrichment pipeline that runs again during re-certification
- **[Canonicalisation](./canonicalization)** — The deterministic serialisation applied to updated metadata
- **[Independent Verification](./independent-verification)** — How any version in the chain can be independently verified
---
---
# For Lawyers
# Scope & Legal Positioning
This section defines the precise legal positioning of TrackForge's tiered certification system. It is intended for solicitors, barristers, and in-house counsel who need to understand what a TrackForge certification constitutes and, critically, what it does not.
## The core distinction: process fidelity, not legal truth
TrackForge certifies **process fidelity**. This is the single most important concept in evaluating a TrackForge certification. Every certification attests that a defined, documented, repeatable verification process was followed and that the metadata was in the stated condition at the stated time. It does not attest to the absolute legal accuracy of the underlying data.
The depth of that process varies by [certification tier](/methodology/golden-record-selection). A Gold certification reflects multi-source corroboration with human review. A Declared certification reflects only that the submitting party's data was cryptographically timestamped. The process fidelity claim is scaled accordingly.
## What TrackForge certifies
Each certification confirms the following elements, with the scope varying by tier:
1. **Documented multi-source enrichment** — The track metadata was processed through TrackForge's enrichment pipeline, consulting multiple authoritative sources (Spotify, MusicBrainz, Discogs, Last.fm, PRS for Music, MLC, and additional collecting societies). *(Gold, Silver, Bronze only — not applicable to Declared.)*
2. **Cross-source validation** — Validation was performed across these sources. Where sources disagreed, conflicts were identified, scored by confidence, and resolved either algorithmically or by a human operator. *(Gold, Silver, Bronze only.)*
3. **Quality gates passed** — The metadata met all defined quality thresholds required for the assigned tier (see [Certification Tiers](/methodology/golden-record-selection) for tier-specific requirements).
4. **Operator review** — A trained operator reviewed and approved the certified data. The operator's actions are recorded in a comprehensive audit trail. *(Gold tier only.)*
5. **Point-in-time attestation** — The certified metadata was in the stated condition at the stated time. The certification is a snapshot, not a continuing representation. *(All tiers.)*
6. **Cryptographic verifiability** — The certification hash is independently verifiable against a Bitcoin blockchain anchor via OpenTimestamps. Any party can confirm that the data has not been altered since the certification date. *(All tiers.)*
7. **Methodology compliance** — The published certification methodology (versioned and publicly available) was followed throughout the process. *(All tiers.)*
8. **Tier assignment** — The track was classified according to the documented tier criteria, and the assigned tier accurately reflects the verification depth applied. *(All tiers.)*
## What TrackForge does NOT certify
TrackForge certification **does not** assert any of the following:
1. **Legal ownership** — Certification does not confirm, establish, or imply legal ownership of copyright, neighbouring rights, or any other intellectual property right.
2. **Definitive writer splits** — Certification does not assert that writer shares are legally settled, binding, or free from dispute.
3. **Absence of future contradictions** — Certification does not guarantee that no future claim, correction, or contradictory evidence could emerge.
4. **Upstream accuracy** — Certification does not warrant that the source databases consulted (Spotify, MusicBrainz, PRS, MLC, and others) are free from errors or omissions.
5. **Legal advice** — Certification does not constitute legal advice or a legal opinion of any kind.
6. **Substitute for title search** — Certification is not a substitute for a formal title search, legal due diligence, or independent legal counsel.
:::caution Important notice
TrackForge certification confirms the metadata state verified by TrackForge's multi-source enrichment pipeline and quality gates as of the date shown. It does not constitute legal proof of copyright ownership, authorship rights, or entitlement to royalties. TrackForge certifies process fidelity — that the stated methodology was followed and that the data was in this state at this time — not the absolute legal accuracy of the underlying metadata. This certification should not be relied upon as a substitute for independent legal advice or formal title searches.
:::
## Evidentiary weight by certification tier
The certification tier directly affects the evidentiary weight that may reasonably be attributed to a certification. Legal practitioners should consider the tier when assessing the probative value of a TrackForge certification.
| Tier | Process depth | Human involvement | Evidentiary considerations |
|:-----|:-------------|:------------------|:---------------------------|
| **Gold** | Multi-source enrichment, cross-referencing, share validation, 2+ source corroboration | Trained operator reviewed and approved; full audit trail | Highest evidentiary weight. Combines automated verification with documented human scrutiny. Analogous to an independent auditor's report. |
| **Silver** | Multi-source enrichment, cross-referencing, quality gates | Automated pipeline; no dedicated human review of individual tracks | Strong automated verification. Structurally complete metadata verified against authoritative sources. Analogous to an automated compliance check against defined criteria. |
| **Bronze** | Partial enrichment; documented gaps | Automated pipeline only | Partial verification with transparent gap documentation. The certification honestly reflects what is known and what is missing. Useful as evidence of due diligence effort, but gaps should be noted. |
| **Declared** | No independent verification by TrackForge | None — user-submitted data only | Lowest evidentiary weight as verification evidence. Value lies in the cryptographic timestamp proving the data was declared at a specific point in time. Analogous to a notarised declaration — it proves the declaration was made, not that the declaration is accurate. |
### Tier-specific legal disclaimers
Each tier carries a distinct legal disclaimer that reflects its verification depth. These disclaimers are embedded in the certificate at issuance and cannot be altered. See [Certificate Wording & Disclaimer](/for-lawyers/certificate-wording) for the full text of each disclaimer.
- **Gold and Silver** certificates carry the B2B verification disclaimer, with Gold additionally noting human operator review.
- **Bronze** certificates carry a modified verification disclaimer that explicitly identifies documented gaps.
- **Declared** certificates carry a materially different disclaimer making clear that TrackForge has not independently verified the metadata.
## Analogies for legal practitioners
Two analogies assist in positioning TrackForge certification within familiar legal frameworks.
### Title insurance
In property conveyancing, a title insurer conducts a thorough search of land registry records, historical deeds, and encumbrances. The resulting policy attests: "We searched thoroughly using a documented process and found no issues." It does not assert: "There are definitively no issues anywhere in the world."
TrackForge certification operates on the same principle. If a previously unknown rights claimant surfaces after certification, the certification remains a valid record of what was known and verified at that point in time, using the methodology then in force.
The tier determines the depth of the search: Gold represents a comprehensive search with human verification; Bronze represents a partial search with documented gaps; Declared represents only the owner's own declaration.
### Credit rating agencies
Moody's or S&P rate a bond based on documented criteria applied consistently. The rating reflects their assessment methodology, not an absolute guarantee of creditworthiness. Similarly, TrackForge certifies metadata based on a published methodology applied consistently. The certification reflects process fidelity, not an absolute guarantee of metadata accuracy.
The tier is analogous to the rating grade itself — it communicates the depth and rigour of the assessment process applied.
In both cases, the value lies in the **documented, repeatable, independently verifiable process** rather than a claim of infallibility.
## B2B vs Self-Service certification
TrackForge offers certification at different service tiers. The level of human involvement differs materially between them, and this distinction is relevant when assessing the evidentiary weight of a certification.
| Aspect | B2B Certification (Tier 2/3) | Self-Service (Tier 1, future) |
|--------|------------------------------|-------------------------------|
| **Analogy** | Independent auditor | Notary public |
| **Certification tiers available** | Gold, Silver, Bronze | Bronze, Declared |
| **Human review** | Trained operator reviews and approves each track (Gold tier) | Automated pipeline only |
| **Conflict resolution** | Operator reviews ambiguous conflicts with full audit trail | Algorithmic resolution only |
| **Attestation strength** | Process fidelity + human verification (Gold) or automated verification (Silver/Bronze) | Process fidelity only (timestamp attestation) |
| **Use case** | Catalogue acquisitions, dispute evidence, sync licensing, insurance | Internal catalogue monitoring, ongoing QA |
| **Appropriate for** | Legal proceedings, due diligence, commercial transactions | Internal confidence scoring, trend analysis |
For B2B engagements, TrackForge operates as an **auditor**: a qualified operator examines the evidence, makes documented decisions, and approves the result. The full operator audit trail — recording every action, decision, and review — is included in the certification proof bundle.
For self-service (when available), TrackForge operates as a **notary**: it attests that a defined automated process was followed and records the result with a blockchain-anchored timestamp, but does not apply independent human evaluation.
Both service levels produce cryptographically verifiable, blockchain-anchored certifications. The distinction lies in the depth of human scrutiny applied before certification, which may be relevant when assessing the weight to be given to the certification in any particular context.
---
# Certificate Wording & Disclaimer
This section sets out the standard disclaimer text that appears on every TrackForge certificate, explains where it appears, addresses why precise wording matters, and documents the tier-specific distinctions between Gold, Silver, Bronze, and Declared certification.
## Tier-specific disclaimers
Each certification tier carries a distinct disclaimer that reflects the verification depth applied. The disclaimer is embedded in the certificate at the time of generation and cannot be modified after issuance.
### Gold disclaimer
The following disclaimer appears on certificates issued at the **Gold** tier — meaning certificates where TrackForge has performed multi-source enrichment, cross-referencing, quality gates, share validation, and a trained human operator has reviewed and approved the data:
> "This certification confirms the metadata state independently verified across multiple authoritative sources, with human operator review and approval, as of the date shown. Writer ownership shares have been validated to sum to approximately 100%. The cryptographic hash of this certified state has been anchored to a public blockchain and can be independently verified at trackforge.studio/verify.
>
> TrackForge certifies process fidelity — that the stated methodology was followed, that multi-source corroboration was achieved, that a trained operator reviewed the data, and that the data was in this state at this time — not the absolute legal accuracy of the underlying metadata. Certification reflects the consensus of available authoritative sources at the time of verification. Music metadata is subject to change through legitimate rights transfers, corrections, and industry updates.
>
> This certification does not constitute legal proof of copyright ownership, authorship rights, or entitlement to royalties, and should not be relied upon as a substitute for independent legal advice or formal title searches. See trackforge.studio/methodology for the full certification process description."
### Silver disclaimer
The following disclaimer appears on certificates issued at the **Silver** tier — meaning certificates where TrackForge has performed multi-source enrichment and the metadata is structurally complete (ISRC, ISWC, duration, writer with IPI), but without dedicated human review of the individual track:
> "This certification confirms the metadata state verified through TrackForge's automated multi-source enrichment pipeline and quality gates as of the date shown. The metadata is structurally complete for royalty collection purposes. The cryptographic hash of this certified state has been anchored to a public blockchain and can be independently verified at trackforge.studio/verify.
>
> TrackForge certifies process fidelity — that the stated methodology was followed and that the data was in this state at this time — not the absolute legal accuracy of the underlying metadata. Certification reflects the consensus of available authoritative sources at the time of verification. Music metadata is subject to change through legitimate rights transfers, corrections, and industry updates.
>
> This certification does not constitute legal proof of copyright ownership, authorship rights, or entitlement to royalties, and should not be relied upon as a substitute for independent legal advice or formal title searches. See trackforge.studio/methodology for the full certification process description."
### Bronze disclaimer
The following disclaimer appears on certificates issued at the **Bronze** tier — meaning certificates where TrackForge has performed partial enrichment and the metadata meets minimum certification requirements but has documented gaps:
> "This certification confirms partially enriched metadata that meets minimum certification requirements as of the date shown. Documented gaps exist in the metadata — refer to the certificate details for specifics. The cryptographic hash of this certified state has been anchored to a public blockchain and can be independently verified at trackforge.studio/verify.
>
> TrackForge certifies process fidelity — that the stated methodology was followed and that the data was in this state at this time — not the absolute legal accuracy of the underlying metadata. Gaps in the certified metadata are documented transparently. Music metadata is subject to change through legitimate rights transfers, corrections, and industry updates.
>
> This certification does not constitute legal proof of copyright ownership, authorship rights, or entitlement to royalties, and should not be relied upon as a substitute for independent legal advice or formal title searches. See trackforge.studio/methodology for the full certification process description."
### Declared disclaimer
For the Declared tier — where a submitting party enters their own metadata and TrackForge has **not** independently verified it — a materially different disclaimer is required:
> "This certification confirms that the metadata shown was declared by the submitting party and cryptographically timestamped on the date shown. TrackForge has not independently verified the accuracy of the declared metadata. This is a record of declaration, not a verification of rights."
:::danger Four tiers, four disclaimers
These four tiers **must never** use the wrong disclaimer. A Declared certification carrying Gold or Silver verification language would be misleading and legally dangerous — it would imply that TrackForge had verified metadata that was in fact only declared by the submitting party. Equally, a Gold certification carrying Bronze language would understate the verification depth applied.
The certification tier and its corresponding disclaimer are embedded in the certificate metadata and cannot be changed after issuance.
:::
## Where the disclaimer appears
The disclaimer is displayed on every certificate output without exception:
| Output format | Placement |
|---------------|-----------|
| **PDF certificate** | Footer of every page |
| **HTML certificate** | Footer section, visible without scrolling on the certificate page |
| **Web portal** | Displayed beneath the certificate details on the verification and download pages |
| **Proof bundle** | Included in the bundle metadata and in the human-readable certificate document |
The disclaimer text is embedded in the certificate at the time of generation. It is not dynamically loaded or subject to subsequent modification on issued certificates.
## Verification page statement
The public certificate verification page (accessible without authentication) allows any party to verify a certification by submitting a hash or certificate identifier. The verification page:
- Confirms whether a valid certification exists for the submitted hash
- Displays the certification date, ISRC, certification tier, and methodology version
- Does not display any personal data (writer names, IPI numbers, splits, or catalogue names)
- Operates without cookies, tracking, or analytics
- Includes the tier-appropriate disclaimer text
- Confirms the blockchain anchoring status (pending, confirmed, or independently verifiable)
## Why this wording matters
The precise wording of the certificate disclaimer is a deliberate legal choice, not a formality. The following considerations inform the current text.
### Certificates in the wild
Once a certificate is issued, it enters circulation. It may be presented to counterparties, included in due diligence bundles, filed in legal proceedings, or relied upon by parties unknown to TrackForge at the time of issuance. Retroactive changes to the disclaimer text on previously issued certificates are not possible — the certificate is a fixed document, and its hash is anchored to the blockchain.
This means the disclaimer wording must be sufficient at the point of issuance to address all foreseeable contexts in which the certificate might be used or relied upon.
### Key elements of the Gold/Silver wording
The disclaimer is constructed to address the following points:
1. **Process fidelity, not legal truth** — The phrase "certifies process fidelity" is the core limitation. It establishes that TrackForge's attestation relates to the rigour of its own process, not to the absolute accuracy of the underlying data. This is the precise concept that clients and lawyers need to understand.
2. **Verification depth** — Gold certificates explicitly reference "multiple authoritative sources" and "human operator review." Silver certificates reference "automated multi-source enrichment pipeline." This distinction ensures the reader understands the level of scrutiny applied.
3. **Cryptographic anchoring** — The reference to public blockchain anchoring establishes that the proof exists independently of TrackForge. If TrackForge ceased to exist, the Bitcoin transaction would still be there and the hash would still be verifiable. This is what makes the certification independently verifiable rather than merely an assertion.
4. **Point-in-time qualification** — The phrase "as of the date shown" limits the attestation to a specific moment. The certification is a snapshot, not a continuing representation.
5. **Source characterisation** — The phrase "reflects the consensus of available authoritative sources at the time of verification" frames the inherent nature of music rights data correctly. Music metadata is subject to change through legitimate rights transfers, corrections, and industry updates — this is a characteristic of the domain, not a weakness in the process.
6. **No ownership assertion** — The phrase "does not constitute legal proof of copyright ownership, authorship rights, or entitlement to royalties" expressly excludes the most common potential misuse of the certification.
7. **Professional advice carve-out** — The phrase "should not be relied upon as a substitute for independent legal advice or formal title searches" directs the reader to seek appropriate professional guidance.
8. **Methodology reference** — The reference to trackforge.studio/methodology ensures that any party examining the certificate can access the full methodology description, providing transparency about the process that produced the certification.
### Key elements of the Bronze wording
The Bronze disclaimer adds:
- **Explicit gap disclosure** — The phrase "documented gaps exist in the metadata" ensures that a Bronze certificate cannot be mistaken for a fully verified record.
- **Transparency commitment** — The phrase "gaps in the certified metadata are documented transparently" reinforces that the certification is honest about what it does and does not cover.
### Key elements of the Declared wording
The Declared disclaimer is deliberately minimal and materially different:
- **No verification claim** — The phrase "TrackForge has not independently verified" makes unambiguously clear that no independent verification was performed.
- **Declaration framing** — The phrase "record of declaration, not a verification of rights" positions the certificate correctly as a timestamped declaration, not an audit result.
### Consistency across formats
The disclaimer text for each tier is identical across all certificate formats (PDF, HTML, web portal). This consistency is maintained to avoid any argument that a party received a certificate with a different or lesser disclaimer than another party, and to ensure that the legal positioning of the certification is uniform regardless of how it is encountered.
:::caution Do not modify
The standard disclaimer text should not be modified, abbreviated, or omitted on any certificate output. Any proposed changes to the disclaimer wording should be reviewed by legal counsel before implementation, with particular attention to the implications for certificates already in circulation.
:::
---
# Liability & Risk Framework
This section sets out the liability framework for TrackForge's Golden Record Certification service, identifies foreseeable risk scenarios, and addresses the inherent limitations of any metadata certification system (the "Oracle Problem").
## Liability limitations
TrackForge's certification service operates within the following liability boundaries:
1. **Liability cap** — Total liability for the certification service is capped at the fees paid by the client during the relevant contract period.
2. **Upstream errors excluded** — TrackForge does not accept liability for errors or omissions in the source databases consulted (Spotify, MusicBrainz, PRS for Music, MLC, Discogs, Last.fm, and others). The certification methodology documents which sources were consulted and how conflicts were resolved, but does not warrant the accuracy of those sources.
3. **Reliance without legal advice** — TrackForge does not accept liability where a party relies upon a certification without obtaining independent legal advice appropriate to their circumstances.
4. **Consequential and indirect losses excluded** — Liability for indirect, consequential, or special losses is excluded to the fullest extent permitted by law.
5. **Professional indemnity insurance** — TrackForge maintains professional indemnity insurance appropriate to the certification service. PI cover is in place before the first B2B client engagement.
:::caution Contractual terms prevail
The specific liability terms applicable to any engagement are set out in the relevant client contract and Data Processing Agreement. This documentation provides a general overview of TrackForge's approach to liability and risk. It does not constitute a contractual commitment and is subject to the terms agreed with each client.
:::
## Risk scenarios
The following table identifies foreseeable risk scenarios and the corresponding mitigations built into the certification framework.
| Scenario | Description | Mitigations |
|----------|-------------|-------------|
| **Certification relied upon in dispute** | A party presents a TrackForge certification as evidence in a rights dispute and subsequently loses. The party seeks to recover against TrackForge. | Liability cap (fees paid). Certificate disclaimer states process fidelity, not legal truth. Methodology defence: documented, repeatable process was followed correctly. |
| **Conflicting certifications** | Two parties hold TrackForge certifications for the same ISRC with different metadata (e.g., different writer splits). | Both certifications stand as valid records of the metadata state at their respective certification dates. The system flags the conflict. TrackForge does not adjudicate between competing claims. See [Conflicting Certifications Policy](./conflicting-certifications). |
| **Upstream source error** | A source database (e.g., MusicBrainz, PRS) contained an error at the time of certification, which was propagated into the certified metadata. | Methodology defence: the published methodology was followed. Certification attests to process fidelity, not upstream accuracy. The certificate disclaimer addresses this expressly. |
| **Bad faith reliance** | A party uses a certification as "proof" of ownership in circumstances where it was not intended to serve that purpose. | Acceptable use terms in the client contract. Certificate disclaimer is explicit that certification does not constitute proof of ownership. Published scope documentation (this page and the [Scope & Legal Positioning](./certification-scope) page). |
| **Post-anchor error discovered** | An error in the certified metadata is discovered after blockchain anchoring. | Re-certification is available. The original certification remains on the blockchain as a historical record. The new certification supersedes it, with the re-certification event documented in the audit trail. |
| **GDPR deletion request** | A data subject requests deletion of their personal data, which appears in certified records. | The blockchain anchor contains only the Merkle root hash — no personal data. Underlying records are handled per the Data Processing Agreement. The hash persists (it is not personal data), but the underlying metadata can be deleted or anonymised as required. See [Data Handling & GDPR](./data-handling-gdpr). |
## The Oracle Problem
Any system that certifies real-world data faces a fundamental epistemological limitation known as the "Oracle Problem": the certification system can verify that its own process was followed correctly, but cannot independently verify the absolute truth of the underlying data obtained from external sources.
TrackForge operates as a **Trusted Gateway** between external metadata sources and the certified output. The integrity of the certification depends on both the rigour of the internal process and the quality of the external sources consulted. TrackForge mitigates the Oracle Problem through the following measures:
1. **Published methodology** — The certification methodology is published, versioned, and available for independent review. Any party can assess the rigour of the process that produced a given certification.
2. **Operator review** — In B2B engagements, a trained human operator reviews the enrichment results, conflict resolutions, and quality gate outcomes before certification. The operator audit trail provides a complete record of every action taken, every review performed, and every decision made during the certification process.
3. **Re-certification** — Where errors are discovered post-certification, the system supports re-certification. The original certification remains as a historical record; the new certification supersedes it.
4. **Explicit disclaimer** — Every certificate carries a disclaimer that expressly addresses the limitation. The certification attests to process fidelity, not the absolute accuracy of the underlying metadata.
5. **Professional indemnity insurance** — PI cover provides a financial backstop where the certification service falls below the standard required.
### Operator audit trail
The operator audit trail is a material component of the risk mitigation framework. For every B2B certification, the system records:
- The identity of the operator who performed each action
- The precise action taken (certification, review, export, enrichment, or administrative)
- The catalogue, ISRC, and batch affected
- A detailed record of the decision context (stored as structured data)
- The timestamp, IP address, and client information for each action
This audit trail is included in the certification proof bundle delivered to the client. It provides contemporaneous evidence that human review was conducted and documents the basis on which certification decisions were made. In the event of a dispute, the audit trail serves as evidence of the standard of care applied during the certification process.
---
# Data Handling & GDPR
This section addresses how TrackForge handles personal data within the certification process, the GDPR implications, and the measures taken to ensure compliance. It is intended for data protection officers, privacy counsel, and any party conducting due diligence on TrackForge's data handling practices.
## Personal data classification
The certification process involves the following categories of data, each with distinct privacy characteristics:
| Data Category | Classification | Rationale |
|---------------|---------------|-----------|
| **Writer names** | Personal data | Names of natural persons; identifiable individuals. |
| **IPI numbers** | Personal data (professional identifier) | Assigned to identified individuals by collecting societies; constitutes a persistent professional identifier linked to a natural person. |
| **Writer shares / splits** | Commercially sensitive data | Percentage allocations of rights; may also be personal data where attributable to an identified individual. |
| **Catalogue metadata** (titles, ISRCs, ISWCs, durations) | Client commercial data | Generally not personal data, though edge cases exist (e.g., an artist who is the sole writer of a uniquely titled work). |
| **Operator actions** | Personal data (employment context) | Operator names and actions recorded in the audit trail; handled under the employment/engagement relationship. |
## Legal basis for processing
TrackForge processes personal data in the certification context on the basis of **legitimate interest** (Article 6(1)(f) GDPR). The legitimate interest is the provision of a metadata certification service that benefits the music industry by improving the accuracy and reliability of rights data used in royalty distribution.
A Legitimate Interest Assessment (LIA) has been conducted and is available upon request.
## Data Processing Agreement requirements
A Data Processing Agreement (DPA) is required for every B2B engagement. The DPA addresses the following matters:
1. **Data ownership** — The client remains the data controller. TrackForge processes data on the client's behalf as a data processor.
2. **Processing purpose** — Data is processed solely for the purpose of catalogue enrichment, verification, and certification as described in the service agreement.
3. **Sub-processors** — TrackForge consults external data sources as part of the enrichment pipeline. These include Spotify (API), MusicBrainz (API), Discogs (API), Last.fm (API), PRS for Music, MLC, and additional collecting societies. Each sub-processor consultation is documented in the certification methodology. The current sub-processor list is maintained and made available to the client.
4. **Data retention** —
- Certification records (certificates, Merkle proofs, blockchain anchors): retained indefinitely, as these constitute the certification output.
- Working data (intermediate enrichment results, draft records): retained per the schedule agreed in the DPA, then deleted.
- Operator audit trail: retained for the duration specified in the DPA (minimum period aligned with the applicable limitation period for professional negligence claims).
5. **Termination** — Upon termination, working data is deleted per the agreed schedule. Certification records persist (they are the deliverable of the service and are anchored to the blockchain).
6. **Security measures** — Technical and organisational measures are documented in the DPA, including encryption at rest and in transit, access controls, and audit logging.
7. **Breach notification** — TrackForge commits to notifying the client of any personal data breach without undue delay, and in any event within the timeframe specified in the DPA (not exceeding the 72-hour GDPR requirement for controller notification to the supervisory authority).
## Self-service privacy considerations
For the self-service tier (when available):
- **Account deletion** — A user may request deletion of their account and associated data. Certification records (certificates, hashes, blockchain anchors) persist, as they are the deliverable of the service. The underlying metadata can be deleted or anonymised.
- **Verification page** — The public certificate verification page operates without cookies, tracking, or analytics. It accepts a certification hash and confirms whether a valid certification exists for that hash. No personal data is displayed on the verification page.
## Public vs private data boundary
This boundary is critical and is enforced at every level of the system. The following data may appear on publicly accessible certificates, verification pages, or blockchain records:
| Public (may be exposed) | Private (never exposed publicly) |
|--------------------------|----------------------------------|
| ISRC (recording identifier) | Writer names |
| Certification date | IPI numbers |
| SHA-256 hash of canonical metadata | Writer splits / shares |
| Merkle root hash | Catalogue names |
| Bitcoin blockchain transaction ID | Track titles |
| Methodology version | Canonical JSON content |
:::caution Critical privacy boundary
**No personal data is written to the Bitcoin blockchain or exposed on public verification pages.** The blockchain anchor contains only the Merkle root hash — a cryptographic digest that cannot be reversed to recover the underlying data. Writer names, IPI numbers, splits, shares, catalogue names, and track titles are never included in any public-facing output.
:::
## What goes on the blockchain
The Bitcoin blockchain anchor consists solely of the **Merkle root hash** — a single SHA-256 digest derived from the Merkle tree of all track hashes in the certification batch. This hash is anchored via OpenTimestamps.
The Merkle root hash is:
- **Not personal data** — It is a fixed-length cryptographic digest (256 bits) that cannot be reversed, decoded, or used to identify any natural person.
- **Not catalogue data** — It reveals nothing about the content, titles, writers, or commercial terms of the certified catalogue.
- **Persistent** — Once anchored, the hash cannot be removed from the blockchain. This is by design: it provides the tamper-proof timestamp that underpins the certification.
Because the blockchain anchor contains no personal data, GDPR deletion requests do not require (and cannot achieve) removal of the hash from the blockchain. The underlying metadata records held by TrackForge can be deleted or anonymised in compliance with a valid deletion request, while the hash — which is not personal data — persists as proof that a certification was issued at a specific time.
---
# Conflicting Certifications Policy
This section addresses the scenario in which two or more TrackForge certifications exist for the same ISRC (International Standard Recording Code) but contain different metadata — for example, different writer splits, different writer attributions, or different compositional data.
## Policy
TrackForge's policy on conflicting certifications is defined by the following five principles:
1. **Both certifications stand.** Each certification is a valid, independently verifiable record of the metadata state at its respective certification date. Neither certification is invalidated, withdrawn, or superseded by the existence of the other.
2. **The system flags the conflict.** When a conflict is detected (i.e., two certifications for the same ISRC with materially different rights-determinative metadata), the system records the conflict and makes it visible to both parties.
3. **TrackForge does not adjudicate.** TrackForge does not determine which certification is "correct" or which party's metadata reflects the true legal position. Adjudication of rights disputes is a matter for the parties, their legal advisers, or the relevant judicial or arbitral forum.
4. **Neither certification is invalidated.** The existence of a conflicting certification does not affect the validity of either certification as a record of process fidelity. Each certification attests that the stated methodology was followed and that the data was in the stated condition at the stated time — and both statements remain true.
5. **The conflict is visible to both parties.** Transparency is fundamental. Both parties are made aware that a conflicting certification exists. Neither party is left with the impression that their certification is the sole record for that ISRC.
## Why both certifications stand
This policy follows directly from the nature of TrackForge certification and the properties of the blockchain anchor.
### Process fidelity, not legal truth
Each certification attests to process fidelity: the documented methodology was followed, the quality gates were passed, and the metadata was in the stated condition at the stated time. Both of these statements can be simultaneously true even when the underlying metadata differs. The certification does not assert that the metadata is the definitive legal truth — only that the process was followed correctly.
Two certifications with different writer splits do not represent a failure of the certification system. They represent two independently verified snapshots of the metadata as it existed in each party's catalogue at the time of certification. The difference between them is a matter for the parties to resolve through their own legal or commercial processes.
### Blockchain immutability
Each certification is anchored to the Bitcoin blockchain via OpenTimestamps. Once anchored, the certification hash cannot be removed, altered, or revoked. This immutability is a feature, not a limitation — it ensures that no party can retrospectively alter or suppress a certification.
Invalidating one certification in favour of another would require the ability to remove an anchor from the blockchain, which is not technically possible. The policy therefore reflects the technical reality as well as the principled position.
## Conflict detection
TrackForge detects conflicts through the following mechanism:
- When a new certification is created, the system checks whether any existing certification covers the same ISRC.
- If an existing certification is found and the rights-determinative metadata differs materially (different writers, different splits, different ISWCs), a conflict is recorded.
- Both the existing and new certification holders are notified of the conflict through their respective TrackForge accounts.
- The conflict is recorded in the system metadata but does not appear on the certificates themselves. The certificates remain clean records of the metadata state at their respective certification dates.
## Implications for relying parties
Parties who rely upon a TrackForge certification should be aware of the following:
1. **A certification is not exclusive.** The existence of a certification for a given ISRC does not preclude the existence of another certification for the same ISRC with different metadata.
2. **Check for conflicts.** Relying parties conducting due diligence should enquire whether any conflicting certifications exist for the ISRCs in question. This information is available through TrackForge's platform.
3. **Certification does not resolve disputes.** Where conflicting certifications exist, the certification system provides evidence of what each party's metadata stated at a given time. It does not resolve the underlying dispute. Resolution requires reference to the relevant agreements, collecting society records, and — where necessary — legal proceedings.
4. **Evidentiary value is preserved.** A certification retains its evidentiary value as a record of process fidelity even in the presence of a conflicting certification. The fact that another party holds a different certification does not diminish the attestation that the methodology was followed correctly in producing either certification.
5. **Re-certification is available.** Where a conflict is identified and the parties resolve the underlying dispute, either or both parties may request re-certification with corrected metadata. The new certification supersedes the previous one (though the previous certification remains on the blockchain as a historical record).
:::caution Not a dispute resolution mechanism
TrackForge certification is not a dispute resolution mechanism. Where conflicting certifications exist, the parties should seek independent legal advice to resolve the underlying rights question. TrackForge provides evidence of the metadata state at a point in time; it does not adjudicate between competing claims.
:::
---
---
# For Catalogue Owners
# What You Get
When TrackForge certifies your catalogue, you receive four distinct deliverables. Each serves a different purpose and audience. Together, they form a complete, independently verifiable evidence package for your metadata.
## The four deliverables at a glance
| Deliverable | Format | What it is | Primary audience |
|-------------|--------|-----------|-----------------|
| **Track Certificate** | JSON + HTML | Per-track certification with Merkle proof | Catalogue managers, internal QA |
| **Catalogue Report** | JSON + HTML | Aggregate certification summary for the batch | Senior management, business development |
| **Chain of Title Export** | JSON | Full rights chain with writer details and blockchain proof | Business Affairs, sync licensing, legal |
| **Proof Bundle** | ZIP archive | Self-contained verification package | Due diligence teams, dispute evidence, archival |
All four deliverables are produced for every certification tier (Gold, Silver, Bronze, and Declared). The tier badge on each deliverable indicates the verification depth applied, and the disclaimer text varies by tier, but the deliverable structure and cryptographic proofs are identical across all tiers.
## What varies by tier
| Aspect | Gold | Silver | Bronze | Declared |
|:-------|:-----|:-------|:-------|:---------|
| **Deliverables included** | All four | All four | All four | All four |
| **Tier badge** | Gold | Silver | Bronze | Declared |
| **Disclaimer text** | B2B verification + human review | B2B verification (automated) | Partial verification, gaps documented | NOT independently verified |
| **Human review confirmation** | Included in audit trail | Not applicable | Not applicable | Not applicable |
| **Operator audit trail** | Full trail with human review actions | Full trail (automated actions) | Full trail (automated actions) | Minimal (timestamp only) |
| **Gap documentation** | N/A (no gaps at Gold) | N/A (structurally complete) | Gaps listed in certificate | N/A (no verification performed) |
## Track Certificate
A Track Certificate is issued for each individual track that is certified. It is the most granular certification document. The certificate displays the assigned tier badge (Gold, Silver, Bronze, or Declared) prominently.
**What it contains:**
| Field | Description |
|-------|-------------|
| `isrc` | The track's International Standard Recording Code |
| `title` / `artist` | Track title and performing artist |
| `iswc` | International Standard Musical Work Code (the underlying composition) |
| `writers` | Songwriter details: name, IPI number, role, and share percentage |
| `certification_tier` | The tier assigned to this track (gold, silver, bronze, or declared) |
| `record_hash` | SHA-256 hash of the certified metadata — the cryptographic fingerprint |
| `canonical_json` | The exact data that was hashed (allows independent re-verification) |
| `certification_version` | Which version of the certification methodology was applied |
| `certified_at` | Timestamp of certification |
| `merkle_proof` | Cryptographic proof linking this track to the batch Merkle root |
| `anchors` | Blockchain anchor details (Bitcoin transaction, OpenTimestamps proof) |
| `verification_url` | URL where you can verify the certificate online |
**Available as:** Machine-readable JSON and a printable HTML document.
:::tip When to use it
Track Certificates are useful when you need to demonstrate the certified state of a specific recording — for example, when responding to a metadata query from a PRO or resolving a discrepancy with a distributor.
:::
## Catalogue Report
The Catalogue Report is an aggregate summary covering all certified tracks in a batch. It provides the big picture, including a breakdown of how many tracks achieved each certification tier.
**What it contains:**
| Field | Description |
|-------|-------------|
| `catalog_id` / `batch_id` | Identifiers for the catalogue and certification batch |
| `merkle_root` | The root hash of the Merkle tree covering all tracks in the batch |
| `total_tracks` | Number of tracks submitted |
| `tier_counts` | Breakdown by tier: how many Gold, Silver, Bronze, and Declared |
| `certified_at` | Timestamp of certification |
| `certification_version` | Methodology version applied |
| `status` | Certification status (e.g. `anchored`, `pending`) |
| `anchors` | Blockchain anchor details |
| `tracks` | Summary listing of all certified tracks with their assigned tiers |
| `methodology` | The certification methodology text in effect at time of certification |
**Available as:** Machine-readable JSON and a printable HTML document.
:::tip When to use it
The Catalogue Report is the document to share with potential buyers during catalogue acquisition discussions, or to present to senior management as evidence of metadata quality across the catalogue. The tier breakdown gives an immediate picture of overall catalogue health.
:::
## Chain of Title Export
The Chain of Title Export is the document that Business Affairs teams, sync licensing desks, and dispute lawyers reach for first. It maps out the full rights chain for every certified track, backed by cryptographic proof.
**What it contains:**
For each track in the catalogue:
- **ISRC, title, artist, ISWC** — Core identifiers
- **Writers** — Each songwriter's name, IPI number, role (e.g. composer, lyricist), and share percentage
- **Certification tier** — The tier assigned to this track
- **Record hash and canonical JSON** — For independent re-verification
- **Merkle proof** — Cryptographic proof linking to the batch root
- **Certified at** — Timestamp
At the catalogue level:
- **Merkle root** — The batch-level root hash
- **Blockchain anchors** — Bitcoin transaction details and OpenTimestamps proof
- **Operator audit trail** — Evidence that a trained human operator reviewed and approved the certification (see below)
- **Verification URL** — For online verification
**Available as:** Machine-readable JSON.
:::tip When to use it
The Chain of Title Export is designed for catalogue acquisitions, sync licensing clearance, and dispute resolution. It answers the question "who wrote this, what are their shares, and can you prove it?" in a single document. The tier for each track indicates the verification depth behind that answer.
:::
## Proof Bundle
The Proof Bundle is a self-contained ZIP archive that includes everything needed to independently verify the certification — even if TrackForge no longer exists. It is designed for archival, due diligence, and legal evidence purposes.
**What it contains:**
| File | Description |
|------|-------------|
| `catalog_report.json` | Full catalogue certification report with tier breakdown |
| `chain_of_title.json` | Complete chain of title with writer details and Merkle proofs |
| `tracks/` | Individual track certificates (one JSON file per ISRC) |
| `merkle_tree.json` | Full Merkle tree serialisation (all leaf hashes and root) |
| `proofs/` | OpenTimestamps `.ots` proof files for blockchain verification |
| `operator_audit_trail.json` | Record of all operator review actions |
| `methodology.txt` | The certification methodology in effect at time of certification |
| `README.txt` | Step-by-step verification instructions |
**Available as:** ZIP archive.
For a detailed walkthrough of the Proof Bundle, see [The Proof Bundle](./proof-bundle).
## The operator audit trail
For B2B engagements (Tier 2 and Tier 3), every certification includes an **operator audit trail**. This is a timestamped record of every action taken by the human operator who reviewed and approved the certification.
Each entry records:
- **Operator** — Username of the reviewing operator
- **Action** — What was done (e.g. certification approval, conflict resolution)
- **Detail** — Specifics of the action taken
- **Timestamp** — When the action occurred
The audit trail is included in both the Chain of Title Export and the Proof Bundle. Its purpose is to provide evidence that a qualified human reviewed the data before certification — not just an automated pipeline.
For **Gold** tier certifications, the audit trail includes explicit human review and approval actions. For **Silver** and **Bronze** tiers, the audit trail records the automated pipeline actions. For **Declared** tier, the audit trail records only the timestamping action.
:::tip Why the audit trail matters
In legal and commercial contexts, the difference between "a computer checked this" and "a trained professional reviewed and approved this" is significant. The operator audit trail bridges that gap, providing documentary evidence of human oversight. The certification tier makes the level of human involvement explicit.
:::
## What's next
- **[Understanding Your Certificate](./reading-your-certificate)** — A field-by-field walkthrough of a Track Certificate, including the tier badge.
- **[The Proof Bundle](./proof-bundle)** — How to use the self-contained verification archive.
---
# Understanding Your Certificate
This page walks through each field in a TrackForge Track Certificate, explaining what it means and why it matters. If you have received a certificate in HTML format, the same information is presented in a more readable layout, but the underlying data is identical.
## Certification tier badge
Every certificate displays a **tier badge** indicating the depth of verification applied to the track. The badge appears prominently at the top of the certificate.
| Badge | Tier | What it means |
|:------|:-----|:--------------|
| **Gold** | Gold | The track has been independently verified across multiple authoritative sources, with complete writer ownership shares and human operator review. This is the highest certification standard. |
| **Silver** | Silver | The track has structurally complete metadata (ISRC, ISWC, duration, writer with IPI) verified through TrackForge's automated enrichment pipeline. |
| **Bronze** | Bronze | The track has partially enriched metadata meeting minimum certification requirements. Some gaps exist and are documented in the certificate. |
| **Declared** | Declared | The metadata was submitted by you (the catalogue owner) and cryptographically timestamped by TrackForge, but has NOT been independently verified. |
### What determines the tier?
The tier is assigned based on how much verified data is available for the track. The full criteria are documented in the [Certification Tiers](/methodology/golden-record-selection) methodology page. In summary:
- **Gold** requires: ISRC + ISWC + duration + writer(s) with name, IPI, and role + shares summing to ~100% + corroboration from 2+ sources + human operator review
- **Silver** requires: ISRC + ISWC + duration + writer(s) with name and IPI
- **Bronze** requires: ISRC + duration + at least one of ISWC or writer with name
- **Declared** requires: ISRC present; metadata supplied by you
### How to improve your tier
If your tracks are certified at a lower tier than you expected, you may be able to help improve them:
- **Declared to Bronze**: Provide additional metadata (writer names, ISWCs) or allow TrackForge to run enrichment against your catalogue
- **Bronze to Silver**: Supply missing ISWCs or writer IPI numbers. TrackForge can also attempt to resolve these through PRO database lookups
- **Silver to Gold**: Provide complete writer share breakdowns. TrackForge will corroborate against additional sources and apply human review
When a track is promoted to a higher tier, it is re-certified. The new certification links cryptographically to the previous one, preserving the full audit history.
## Track identification
The first group of fields identifies the recording and the underlying musical work.
### ISRC
The **International Standard Recording Code** — a 12-character identifier that uniquely identifies a specific recording. Every legitimate commercial recording should have one.
Example: `GBAYE0100538`
:::tip What to look for
Verify that the ISRC on the certificate matches the ISRC in your catalogue management system. If they differ, it may indicate a data entry error in the original upload.
:::
### Title and Artist
The track title and performing artist as verified through TrackForge's multi-source enrichment pipeline. These are cross-referenced against Spotify, MusicBrainz, Discogs, and other authoritative sources.
### ISWC
The **International Standard Musical Work Code** — identifies the underlying composition (the song itself, as distinct from the recording). Where available, this links the recording to its registered musical work.
Example: `T-010.466.580-3`
:::tip What to look for
The presence of an ISWC is a strong indicator of proper registration with a collecting society. If the ISWC is present, it means TrackForge found a matching work registration in at least one authoritative source.
:::
### Writers
Each songwriter is listed with:
- **Name** — The songwriter's name as registered
- **IPI** — Their Interested Parties Information number (the global identifier for rights holders)
- **Role** — Their contribution (e.g. Composer, Author/Lyricist, Composer & Author)
- **Share** — Their ownership percentage of the work
:::tip What to look for
Check that writer shares sum to approximately 100% (rounding may cause minor variations). Missing IPI numbers may indicate that a writer is not yet registered with a PRO, which could affect royalty collection.
:::
## The cryptographic proof
The next group of fields is the core of the certification — the cryptographic evidence that this metadata was verified and anchored at a specific point in time.
### `record_hash`
A **SHA-256 hash** of the certified metadata. This is a 64-character hexadecimal string that acts as a unique fingerprint. If even a single character of the certified data were changed, the hash would be completely different.
Example: `a1b2c3d4e5f6...` (64 characters)
**What it proves:** The metadata has not been altered since certification. Anyone with the canonical data can recompute the hash and confirm it matches.
### `canonical_json`
The **exact data that was hashed** to produce the `record_hash`. This is a deterministic JSON serialisation of the rights-determinative fields — the fields that matter for royalty collection and rights management.
**Why it matters:** The canonical JSON is included so that anyone can independently verify the hash. You do not need to trust TrackForge's hash — you can recompute it yourself from the canonical JSON using any SHA-256 tool.
:::tip What to look for
The canonical JSON contains only rights-determinative fields (ISRC, ISWC, writers, duration, etc.). Cosmetic metadata like album art or genre tags is deliberately excluded — only data that affects royalty calculations is certified.
:::
### `merkle_proof`
A **Merkle inclusion proof** — a small set of hashes that proves this track's `record_hash` is included in the batch's Merkle tree without needing to see every other track in the batch.
The proof contains:
- **`proof_hashes`** — The sibling hashes needed to walk up the tree
- **`proof_directions`** — Whether each sibling is on the left or right
**What it proves:** This track was part of the certified batch. The proof mathematically links the individual track hash to the batch-level Merkle root.
### `anchors`
The **blockchain anchor** details. Each anchor records:
- **`anchor_type`** — The anchoring method (e.g. `opentimestamps`)
- **`anchor_hash`** — The Merkle root that was anchored
- **`bitcoin_block`** — The Bitcoin block number containing the anchor (once confirmed)
- **`bitcoin_txid`** — The Bitcoin transaction ID
- **`anchored_at`** — The timestamp of anchoring
**What it proves:** The Merkle root (and therefore every track hash in the tree) existed at or before the time recorded in the Bitcoin blockchain. This cannot be forged or backdated.
:::tip What to look for
If the anchor shows a `bitcoin_block` number, the certification is fully confirmed on the blockchain. If it shows `pending`, the OpenTimestamps proof has been submitted but not yet included in a block — this typically resolves within a few hours.
:::
## Administrative fields
### `certification_version`
The version of TrackForge's certification methodology that was applied. This determines which enrichment sources were consulted, which quality thresholds were required, and which validation rules were enforced.
### `certification_tier`
The tier assigned to this track: `gold`, `silver`, `bronze`, or `declared`. See the [Certification tier badge](#certification-tier-badge) section above for what each tier means.
### `certified_at`
The timestamp when certification was issued. Combined with the blockchain anchor, this establishes the point in time at which the metadata was in the certified state.
### `batch_id` and `catalog_id`
Internal identifiers linking this certificate to its certification batch and catalogue. The `batch_id` connects the track to the Catalogue Report and the shared Merkle tree.
### `verification_url`
The URL where you can verify the certificate online. At this page, you paste the canonical JSON and the hash is computed in your browser — no data is transmitted to TrackForge's servers.
## The disclaimer
Every certificate includes a disclaimer whose wording depends on the certification tier:
- **Gold** certificates state that the metadata was "independently verified across multiple authoritative sources, with human operator review and approval."
- **Silver** certificates state that the metadata was "verified through TrackForge's automated multi-source enrichment pipeline and quality gates."
- **Bronze** certificates state that the metadata is "partially enriched" with "documented gaps."
- **Declared** certificates state that the metadata "was declared by the submitting party" and that "TrackForge has not independently verified the accuracy of the declared metadata."
The full disclaimer text for each tier is documented in [Certificate Wording & Disclaimer](/for-lawyers/certificate-wording). The key point is the same across all tiers: TrackForge certification attests that a thorough, documented verification process was followed (at the depth indicated by the tier) and the metadata met all quality thresholds at the time of certification. It does not make legal claims about ownership — that is a matter for courts and contracts.
Think of it like a property survey: the surveyor attests to what they found using professional methods, but does not guarantee that no undisclosed issues exist.
:::tip How to present this to third parties
When sharing certificates with potential buyers or legal teams, frame it as: "This is independent evidence of the metadata state, produced through a documented, auditable process." The tier badge communicates the verification depth at a glance. Do not present it as a legal determination of ownership.
:::
## What's next
- **[How to Verify Independently](./verification)** — Three ways to verify your certificate without relying on TrackForge.
- **[The Proof Bundle](./proof-bundle)** — The self-contained verification archive.
---
# The Proof Bundle
The Proof Bundle is a ZIP archive designed to be a **complete, self-contained evidence package**. It includes everything needed to independently verify the certification of your catalogue — even if TrackForge no longer exists.
## What the bundle contains
| File / Directory | Description |
|-----------------|-------------|
| `catalog_report.json` | Full catalogue certification report: summary statistics, Merkle root, anchor details, and a listing of all certified tracks. |
| `chain_of_title.json` | Complete chain of title for every certified track. Includes writer details (name, IPI, role, share percentage), ISWCs, Merkle proofs, blockchain anchor data, and the canonical JSON for each track. **This is the primary document for Business Affairs.** |
| `tracks/` | Individual track certificates, one JSON file per ISRC (e.g. `tracks/GBAYE0100538.json`). Each contains the canonical JSON, Merkle inclusion proof, and blockchain anchor data. |
| `merkle_tree.json` | Full Merkle tree serialisation — all leaf hashes and the root hash. Used to independently verify any track's inclusion proof. |
| `proofs/` | OpenTimestamps (`.ots`) proof files for blockchain verification. These allow direct verification against the Bitcoin blockchain without any third-party service. |
| `operator_audit_trail.json` | Timestamped record of all operator review and certification actions. Provides evidence that a trained human reviewed the data (B2B engagements). |
| `methodology.txt` | The certification methodology document that was in effect at the time of certification. |
| `README.txt` | Plain-text verification instructions — the same 7-step procedure described below. |
## Why self-containment matters
The Proof Bundle is deliberately designed so that **no external service is required** to verify it. This matters in several scenarios:
- **Catalogue acquisitions** — A buyer's due diligence team can verify the metadata certification 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 `chain_of_title.json` to review writers, shares, and ISWCs for every track.
2. Cross-reference writer IPIs against their own PRO databases.
3. Verify the cryptographic proofs to confirm the data has not been altered since certification.
4. Review `operator_audit_trail.json` to confirm human oversight was applied.
5. Check the blockchain anchors to confirm the certification timestamp.
:::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 `chain_of_title.json` provides:
- All writers with their IPI numbers and share percentages
- The ISWC linking the recording to the registered work
- Cryptographic proof that this information was verified by a documented, multi-source process
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 **canonical JSON** shows exactly what data was certified.
- The **Merkle proof** shows this track was part of the certified batch (not added after the fact).
- The **operator audit trail** shows that a human operator reviewed and approved the data.
### For PRO registration
The `chain_of_title.json` contains the writer information (names, IPIs, roles, shares) needed for registering or updating works with PROs. While it does not replace the formal registration process, it provides a verified reference point.
## The 7-step verification procedure
This is the same procedure included in the bundle's `README.txt`. It allows complete, independent verification using standard tools.
**Step 1.** Open the track's JSON file (from `tracks/`) or `chain_of_title.json`.
**Step 2.** Locate the `canonical_json` field. This is the exact data that was certified.
**Step 3.** Compute the SHA-256 hash of that exact string. Any SHA-256 tool will work:
```bash
echo -n '' | shasum -a 256
```
**Step 4.** Verify that the computed hash matches the `record_hash` field in the same file.
**Step 5.** Use the Merkle proof (`proof_hashes` and `proof_directions`) to walk from the leaf hash (the track's `record_hash`) up to the Merkle root. At each level, combine the current hash with the proof hash (left or right as indicated) and compute SHA-256 of the pair.
**Step 6.** Verify that the final hash matches the `merkle_root` in `catalog_report.json`.
**Step 7.** Use the `.ots` proof file from the `proofs/` directory to verify the Merkle root is anchored on the Bitcoin blockchain. You can use the `ots` command-line tool, the OpenTimestamps website, or any Bitcoin node.
:::tip You do not need to verify everything
For most practical purposes, Steps 1-4 (verifying a single track's hash) are sufficient to confirm that the data has not been altered. Steps 5-7 add progressively stronger guarantees — batch integrity and blockchain anchoring — which matter most in legal or adversarial contexts.
:::
## What's next
- **[How to Verify Independently](./verification)** — More detail on each verification method.
- **[Re-Certification](./recertification)** — What happens when metadata changes after certification.
---
# Re-Certification: When and Why
Music metadata is not static. Writers are added to registrations, PROs issue corrections, contracts are renegotiated, and disputes are resolved. When certified metadata changes, TrackForge issues a **re-certification** — a new version of the certification that is cryptographically linked to the previous one.
## What triggers re-certification
Re-certification is triggered when a change affects the rights-determinative fields of a previously certified track. There are five defined triggers:
| Trigger | What happened | Example |
|---------|---------------|---------|
| **Contract change** | The underlying rights agreement was modified | A writer's share percentage changed following a renegotiation |
| **PRO correction** | A collecting society issued a correction | PRS updated a writer's IPI number or corrected a work registration |
| **Dispute resolution** | A dispute was settled and the metadata updated | A co-writing credit was confirmed following mediation |
| **Administrative correction** | A factual error was corrected | A misspelt writer name, a transposed ISRC digit |
| **Re-enrichment** | New enrichment data became available | A previously missing ISWC was found in a newly available source |
Re-certification is **not** triggered by cosmetic changes (such as updated album art or genre tags) — only changes to fields that affect royalty calculations and rights determinations.
## How re-certification works
When a track is re-certified, the following happens:
1. **New canonical JSON** is generated from the updated metadata.
2. **New SHA-256 hash** is computed from the new canonical JSON.
3. **New version** is created with the new hash, linked to the previous version's hash.
4. **Previous version** is marked as superseded (but not deleted).
5. **Human operator** reviews and approves the change (for B2B engagements).
6. **New Merkle tree** is built for the certification batch.
7. **New blockchain anchor** is created for the updated batch.
Each re-certification is categorised as either:
- **Material** — A substantive change affecting rights (contract change, dispute resolution)
- **Administrative** — A correction that does not change the underlying rights position (typo fix, PRO correction of an identifier)
## The version chain
Every re-certification creates a new version that is cryptographically linked to its predecessor, forming a **version chain** — a tamper-proof sequence of metadata states.
```
v1 (initial)
├─ record_hash: a1b2c3...
└─ previous_version_hash: (none)
↓ PRO correction
v2
├─ record_hash: d4e5f6...
└─ previous_version_hash: a1b2c3... ← matches v1's hash
↓ contract change
v3 (current)
├─ record_hash: g7h8i9...
└─ previous_version_hash: d4e5f6... ← matches v2's hash
```
The chain has three properties that can be independently verified:
1. **Version 1 has no predecessor** — its `previous_version_hash` is empty.
2. **Each subsequent version's `previous_version_hash` matches the predecessor's `record_hash`** — proving the chain is unbroken.
3. **Exactly one version is marked as current** — the latest, active certification.
This structure proves that no version has been inserted, removed, or reordered after the fact. The integrity of the chain can be verified by anyone with access to the version history.
## Why previous certifications remain valid
A common question: "If my catalogue is re-certified, does the old certification become invalid?"
**No.** Previous certifications remain valid as historical records. They accurately attest to what the metadata looked like at the time they were issued.
Consider an analogy: a property survey conducted in 2020 does not become "invalid" because a new survey was conducted in 2025 after an extension was built. The 2020 survey accurately records the property's state at that time. Both surveys are truthful — they simply describe different moments.
Similarly:
- **Version 1** certifies: "On 15 January 2026, the metadata for this track was in this state, and it met all quality thresholds."
- **Version 2** certifies: "On 3 March 2026, after a PRO correction, the metadata was updated to this state, and it still meets all quality thresholds."
Both statements are true. Both are blockchain-anchored. Both are independently verifiable. The version chain shows exactly what changed and when.
:::tip For legal contexts
The version history can be valuable evidence in disputes. If a writer's share was changed, the version chain shows: what the original certified state was, when the change occurred, what triggered it, and who approved it (via the operator audit trail). This creates a clear, auditable timeline.
:::
## When to request re-certification
You should consider re-certification when:
- **Writer shares change** — Following a renegotiation, settlement, or newly discovered co-writer.
- **A PRO issues a correction** — Updated IPI numbers, corrected work registrations, or amended share allocations.
- **A dispute is resolved** — The outcome changes the rights position for one or more tracks.
- **An error is discovered** — A factual mistake in the certified metadata (misspelt name, incorrect ISRC).
- **New data becomes available** — A previously missing ISWC or writer credit is found through new enrichment sources.
You do **not** need re-certification for cosmetic changes that do not affect rights-determinative fields.
:::tip Proactive re-certification
If you are preparing a catalogue for sale, it is worth checking whether any PRO corrections or new registrations have been issued since the last certification. A current certification with a clean version chain is stronger evidence than an older certification supplemented by informal corrections.
:::
## What's next
- **[What You Get](./deliverables)** — Overview of all certification deliverables.
- **[Understanding Your Certificate](./reading-your-certificate)** — Field-by-field guide to the Track Certificate.
---
# 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.
1. Go to [trackforge.studio/verify](https://trackforge.studio/verify).
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.
:::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 Proof Bundle. You will see files including `catalog_report.json`, `chain_of_title.json`, a `tracks/` directory, `merkle_tree.json`, and a `proofs/` directory.
**Step 2 — Open the track data**
Open the track's JSON file from the `tracks/` directory (named by ISRC, e.g. `tracks/GBAYE0100538.json`), or open `chain_of_title.json` to see all tracks.
**Step 3 — Extract the canonical JSON**
Find the `canonical_json` field. This is the exact string that was hashed during certification.
**Step 4 — Compute the SHA-256 hash**
Hash the canonical JSON string using any SHA-256 tool:
```bash
# macOS / Linux
echo -n '' | shasum -a 256
# Windows PowerShell
$bytes = [System.Text.Encoding]::UTF8.GetBytes('')
$hash = [System.Security.Cryptography.SHA256]::Create().ComputeHash($bytes)
[System.BitConverter]::ToString($hash).Replace('-','').ToLower()
```
:::tip Mind the exact string
The canonical JSON must be hashed exactly as it appears in the file — including all whitespace, key ordering, and escaping. Do not reformat or pretty-print it before hashing.
:::
**Step 5 — Verify the hash matches**
Compare your computed hash with the `record_hash` field in the track's JSON. They should be identical.
If they match, you have confirmed that the certified data has not been altered.
**Step 6 — Verify the Merkle proof**
The track's JSON includes a `merkle_proof` with `proof_hashes` and `proof_directions`. Starting from the track's `record_hash`, combine it with each proof hash in sequence (left or right, as indicated by the direction), hashing at each step. The final result should match the `merkle_root` in `catalog_report.json`.
This confirms that the track was included in the certified batch.
**Step 7 — Verify the blockchain anchor**
Open the corresponding `.ots` file from the `proofs/` directory. Use an OpenTimestamps verifier to confirm that the Merkle root is anchored in the Bitcoin blockchain:
```bash
# Using the ots command-line tool
ots verify proofs/batch_.ots
# Or use the online verifier at opentimestamps.org
```
This confirms that the Merkle root (and therefore every track hash in the tree) existed at or before the time recorded in the Bitcoin 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 `canonical_json` for the track (from any source — your certificate, the proof bundle, or a counterparty)
- The claimed `record_hash`
- The claimed `merkle_root` and the Bitcoin transaction ID
- Any SHA-256 implementation
- Access to a Bitcoin blockchain explorer (e.g. blockstream.info, mempool.space)
### Step-by-step
1. **Hash the canonical JSON** using any SHA-256 implementation in any programming language. Verify it matches the claimed `record_hash`.
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 Bitcoin transaction** using the `bitcoin_txid` on any blockchain explorer. The transaction's `OP_RETURN` data (via the OpenTimestamps protocol) commits to the Merkle root.
4. **Verify the timestamp.** The Bitcoin block timestamp proves the data existed at or before that time. Bitcoin 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, Bitcoin, OpenTimestamps). Any competent technical expert can verify them using publicly available tools and the Bitcoin 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.
- **[Re-Certification](./recertification)** — What happens when certified metadata changes.
---
---
# Technical Reference
# Canonical JSON Schema
Every certification is derived from a **canonical JSON representation** of the track's rights-determinative metadata. The canonical form is deterministic: given identical input data, the same byte-exact JSON string is always produced, yielding the same SHA-256 hash.
This determinism is the foundation of the entire certification system. If you can reproduce the canonical JSON, you can reproduce the hash, and therefore independently verify any certification.
## Certified fields
The canonical JSON includes only fields that are relevant to rights determination. Transient data, engagement metrics, and internal workflow state are excluded.
### Field reference
| Field | Type | Sort Order | Description |
|-------|------|------------|-------------|
| `certification_version` | `string` | N/A | Schema version (e.g. `"2.0"`). |
| `certification_tier` | `string` | N/A | Certification tier: `"gold"`, `"silver"`, `"bronze"`, `"declared"`, or `null` for legacy v1.0 certifications. |
| `isrc` | `string` | N/A | International Standard Recording Code. |
| `iswc` | `string` | N/A | Primary ISWC for the underlying work. |
| `title` | `string` | N/A | Track title. |
| `artist` | `string` | N/A | Primary artist name. |
| `release_date` | `string` | N/A | Release date (ISO 8601 date). |
| `duration_ms` | `integer` | N/A | Duration in milliseconds. |
| `source_count` | `integer` | N/A | Number of independent authoritative sources that corroborated the metadata. |
| `performers` | `array` | Sorted by `(role, name)` | Performing artists with roles. |
| `writers` | `array` | Sorted by `(ipi, name)` | Songwriter/composer credits. |
| `pro_work_ids` | `object` | Sorted by key | PRO-specific work identifiers (e.g. `{"prs": "12345", "ascap": "98765"}`). |
| `territory_registrations` | `object` | Sorted by key | Territory-level registration data. |
| `publisher_chains` | `array` | Sorted by publisher name | Publishing chain information. |
| `iswcs` | `object` | Sorted by key | Additional ISWC mappings. |
### New in v2.0
The following fields were added in schema version 2.0:
- **`certification_tier`** — Indicates the verification depth applied. Values: `"gold"`, `"silver"`, `"bronze"`, `"declared"`. Legacy certifications produced under v1.0 will have this field set to `null` or absent.
- **`source_count`** — The number of independent authoritative sources that corroborated the metadata. This is relevant to the Gold tier requirement of 2+ source corroborations. For Declared tier, this will be `0` or absent.
- **`pro_work_ids`** — An object mapping PRO names to their work identifiers for the track. Keys are lowercase PRO abbreviations (e.g. `"prs"`, `"ascap"`, `"bmi"`, `"gema"`, `"sacem"`). Values are the work identifier strings assigned by each PRO.
:::caution v2.0 hashes differ from v1.0
Because the canonical JSON now includes additional fields (`certification_tier`, `source_count`, `pro_work_ids`), a v2.0 certification of the same track will produce a **different hash** from a v1.0 certification. This is expected and correct — the `certification_version` field distinguishes the two schema versions, and older certifications remain independently verifiable against their original v1.0 schema.
:::
### Performers
Each performer entry contains:
```json
{
"name": "Bruce Dickinson",
"role": "vocals"
}
```
Performers are sorted lexicographically by `(role, name)` — role takes priority, then name within the same role.
### Writers
Each writer entry contains:
```json
{
"name": "Steve Harris",
"ipi": "00026781433",
"role": "composer",
"share": 33.34
}
```
Writers are sorted lexicographically by `(ipi, name)` — IPI takes priority, then name for writers sharing the same IPI.
| Field | Type | Description |
|-------|------|-------------|
| `name` | `string` | Writer's name. |
| `ipi` | `string` | IPI number (Interested Party Information). |
| `role` | `string` | Writer role (e.g. `"composer"`, `"lyricist"`, `"composer/lyricist"`). |
| `share` | `float` | Ownership share as a percentage. |
### PRO work IDs
The `pro_work_ids` object maps PRO names to their work identifiers:
```json
{
"ascap": "894523170",
"prs": "30118462"
}
```
Keys are sorted lexicographically. Only PROs where a work identifier has been confirmed are included.
## Excluded fields
The following categories of data are **never** included in the canonical JSON, even if present in the underlying record:
| Category | Examples | Reason |
|----------|----------|--------|
| Engagement metrics | Play counts, skip rates, playlist adds | Volatile; not rights-determinative. |
| Source identifiers | Spotify URI, MusicBrainz MBID, Discogs ID | Platform-specific; not rights-determinative. |
| Confidence scores | Enrichment confidence, match scores | Internal quality metrics. |
| Workflow state | Pipeline stage, operator assignment | Internal process data. |
| Enrichment metadata | Source timestamps, API response logs | Audit trail data, not certified content. |
| Timestamps | Created/updated timestamps | Only the certification date is recorded (outside the canonical JSON, in the certification record). |
This separation ensures that the certification hash depends solely on rights-critical data. Changes to engagement metrics, internal workflow, or enrichment logs do not invalidate an existing certification.
## Serialisation rules
The canonical JSON is produced using the following deterministic serialisation:
```python
json.dumps(data, sort_keys=True, separators=(',', ':'), ensure_ascii=True)
```
### Rules in detail
1. **Key sorting** — All object keys are sorted lexicographically (`sort_keys=True`).
2. **No whitespace** — No spaces after colons or commas (`separators=(',', ':')`).
3. **ASCII-safe** — All non-ASCII characters are escaped to `\uXXXX` sequences (`ensure_ascii=True`).
4. **UTF-8 encoding** — The resulting string is encoded as UTF-8 bytes before hashing.
5. **No trailing newline** — The serialised string has no trailing newline or whitespace.
6. **Null/empty removal** — Fields with `None`, empty list (`[]`), or empty dict (`{}`) values are removed before serialisation.
### Null/empty value removal
Before serialisation, the canonicaliser strips any field whose value is `None`, `[]`, or `{}`:
```python
certified_fields = {
k: v
for k, v in certified_fields.items()
if v is not None and v != [] and v != {}
}
```
This ensures that the absence of optional data does not affect the hash. A track with no `territory_registrations` produces the same hash regardless of whether the field was `None` or simply absent.
## Example canonical JSON
For a fictional track with three writers and two performers, certified at Gold tier:
```json
{"artist":"Iron Maiden","certification_tier":"gold","certification_version":"2.0","duration_ms":437000,"isrc":"GBAYE0100538","iswc":"T-010.466.720-3","performers":[{"name":"Dave Murray","role":"guitar"},{"name":"Bruce Dickinson","role":"vocals"}],"pro_work_ids":{"ascap":"894523170","prs":"30118462"},"release_date":"2000-05-29","source_count":3,"title":"The Wicker Man","writers":[{"ipi":"00026781411","name":"Adrian Smith","role":"composer","share":33.33},{"ipi":"00026781422","name":"Bruce Dickinson","role":"composer","share":33.33},{"ipi":"00026781433","name":"Steve Harris","role":"composer","share":33.34}]}
```
Note the characteristics:
- No whitespace between tokens.
- Keys in alphabetical order (`artist` before `certification_tier` before `certification_version` before `duration_ms`).
- `certification_tier` is `"gold"` and `certification_version` is `"2.0"`.
- `pro_work_ids` keys sorted alphabetically: `"ascap"` before `"prs"`.
- `source_count` is `3`, indicating three independent sources corroborated the metadata.
- Performers sorted by `(role, name)`: Dave Murray (`guitar`) appears before Bruce Dickinson (`vocals`) because `"guitar"` sorts before `"vocals"`.
- Writers sorted by `(ipi, name)`: Adrian Smith (`00026781411`) before Bruce Dickinson (`00026781422`) before Steve Harris (`00026781433`).
## Producing the record hash
The record hash is the SHA-256 digest of the canonical JSON string, encoded as UTF-8:
```python
import hashlib
import json
record_hash = hashlib.sha256(canonical_json.encode("utf-8")).hexdigest()
```
The result is a 64-character lowercase hexadecimal string. This hash is the leaf value used in the [Merkle tree](./merkle-proof-format).
## Verification procedure
To verify that a certified track's metadata has not been altered:
1. **Obtain the canonical JSON** — Either from the track certificate (`canonical_json` field) or by re-serialising the metadata using the rules above.
2. **Compute the SHA-256 hash** — Hash the canonical JSON string (UTF-8 encoded) to produce a 64-character hex digest.
3. **Compare** — The computed hash must match the `record_hash` stored in the certification.
4. **Verify via API** — Submit the canonical JSON to the public [`POST /verify`](./verification-api#public-verification-endpoint) endpoint. The response confirms whether the hash matches a certified record and returns blockchain anchor details.
If any field in the canonical JSON differs — even by a single character — the hash will be completely different, and verification will fail. This is the fundamental property that makes the certification tamper-evident.
## Certification version
The `certification_version` field (currently `"2.0"`) is included in the canonical JSON itself. If the schema changes in a future version (e.g. adding new certified fields or changing sort orders), the version number will increment. This ensures that certifications produced under different schema versions are distinguishable and that older certifications remain independently verifiable against their original schema.
Legacy certifications produced under version `"1.0"` will not have the `certification_tier`, `source_count`, or `pro_work_ids` fields. They remain valid and verifiable against the v1.0 schema specification.
---
# Verification API
TrackForge exposes nine certification endpoints under the `/api/v1/certifications` prefix. One endpoint is fully public; the remainder require authentication.
All authenticated endpoints use Clerk bearer tokens. The base URL for all endpoints is your TrackForge instance (e.g. `https://api.trackforge.studio`).
## Endpoint summary
| Method | Path | Auth | Description |
|--------|------|------|-------------|
| `POST` | `/verify` | None (public) | Verify a golden record against certified data |
| `GET` | `/batch/{batch_id}` | User | Batch certification status with anchor info |
| `GET` | `/{catalog_id}/certificate/{isrc}` | User | Download per-track certificate (JSON) |
| `GET` | `/{catalog_id}/report` | User | Download full catalogue certification report (JSON) |
| `GET` | `/{catalog_id}/chain-of-title` | User | Download chain of title export (JSON) |
| `GET` | `/{catalog_id}/proof-bundle` | User | Download complete proof bundle (ZIP) |
| `GET` | `/{catalog_id}/{isrc}` | User | Track certification status |
| `GET` | `/{catalog_id}` | User | Catalogue certification summary |
| `POST` | `/{catalog_id}/certify` | Admin | Trigger certification workflow |
---
## Public verification endpoint
### `POST /api/v1/certifications/verify`
**Authentication:** None. This endpoint is intentionally public so that any third party can independently verify a golden record without needing a TrackForge account.
**Rate limit:** 100 requests per minute per IP address. Exceeding this limit returns `429 Too Many Requests`.
#### Request body
```json
{
"canonical_json": ""
}
```
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `canonical_json` | `string` | Yes | The canonical JSON representation of the golden record. Must be serialised using the exact rules defined in the [Canonical JSON Schema](./canonical-json-schema). |
#### Response body
```json
{
"verified": true,
"record_hash": "a1b2c3d4e5f6...64 hex characters",
"certification": {
"isrc": "GBAYE0100538",
"certified_at": "2026-01-15T14:30:00Z",
"certification_version": "1.0",
"is_current": true,
"batch_id": "batch_01HZ...",
"merkle_root": "e7f8a9b0c1d2...64 hex characters"
},
"anchors": [
{
"chain": "bitcoin",
"status": "confirmed",
"tx_id": "3a1b2c3d4e5f...64 hex characters",
"block_number": 879234,
"block_timestamp": "2026-01-15T15:42:00Z"
}
]
}
```
| Field | Type | Description |
|-------|------|-------------|
| `verified` | `boolean` | Whether the submitted canonical JSON matches a certified record. |
| `record_hash` | `string` | SHA-256 hex digest of the submitted canonical JSON. Always returned, even if `verified` is `false`. |
| `certification` | `object \| null` | Certification metadata. `null` if no matching certification exists. |
| `certification.isrc` | `string` | The ISRC of the certified track. |
| `certification.certified_at` | `string` | ISO 8601 timestamp of certification. |
| `certification.certification_version` | `string` | Version of the certification schema (e.g. `"1.0"`). |
| `certification.is_current` | `boolean` | Whether this is the current (latest) certification for the track. |
| `certification.batch_id` | `string` | Identifier of the certification batch. |
| `certification.merkle_root` | `string` | Merkle root of the batch's Merkle tree. |
| `anchors` | `array` | Blockchain anchor records. Empty if not yet anchored. |
| `anchors[].chain` | `string` | Blockchain name (currently always `"bitcoin"`). |
| `anchors[].status` | `string` | Anchor status: `"pending"`, `"submitted"`, or `"confirmed"`. |
| `anchors[].tx_id` | `string` | Bitcoin transaction ID containing the timestamp. |
| `anchors[].block_number` | `integer` | Bitcoin block number. |
| `anchors[].block_timestamp` | `string` | ISO 8601 timestamp of the Bitcoin block. |
#### Example: verified record
```bash
curl -X POST https://api.trackforge.studio/api/v1/certifications/verify \
-H "Content-Type: application/json" \
-d '{"canonical_json": "{\"artist\":\"Iron Maiden\",\"certification_version\":\"1.0\",\"duration_ms\":437000,\"isrc\":\"GBAYE0100538\",\"iswc\":\"T-010.466.720-3\",\"performers\":[{\"name\":\"Bruce Dickinson\",\"role\":\"vocals\"},{\"name\":\"Dave Murray\",\"role\":\"guitar\"}],\"release_date\":\"2000-05-29\",\"title\":\"The Wicker Man\",\"writers\":[{\"ipi\":\"00026781411\",\"name\":\"Adrian Smith\",\"role\":\"composer\",\"share\":33.33},{\"ipi\":\"00026781422\",\"name\":\"Bruce Dickinson\",\"role\":\"composer\",\"share\":33.33},{\"ipi\":\"00026781433\",\"name\":\"Steve Harris\",\"role\":\"composer\",\"share\":33.34}]}"}'
```
#### Example: unverified record
If the canonical JSON does not match any certified record, the response returns `verified: false` with a `null` certification:
```json
{
"verified": false,
"record_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
"certification": null,
"anchors": []
}
```
#### Error responses
| Status | Condition |
|--------|-----------|
| `422` | Missing or malformed `canonical_json` field. |
| `429` | Rate limit exceeded (100 requests/minute/IP). |
| `500` | Internal server error. |
---
## Authenticated endpoints
All endpoints below require a valid Clerk bearer token in the `Authorization` header:
```
Authorization: Bearer
```
### `GET /api/v1/certifications/batch/{batch_id}`
Return the certification status for a batch, including blockchain anchor information.
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `batch_id` | `string` | The certification batch identifier. |
#### Response body
```json
{
"batch_id": "batch_01HZ...",
"catalog_id": "cat_01HZ...",
"merkle_root": "e7f8a9b0c1d2...64 hex characters",
"track_count": 142,
"golden_record_count": 138,
"status": "confirmed",
"certified_at": "2026-01-15T14:30:00Z",
"confirmed_at": "2026-01-15T15:42:00Z",
"certification_version": "1.0",
"anchors": [
{
"chain": "bitcoin",
"status": "confirmed",
"tx_id": "3a1b2c3d...",
"block_number": 879234,
"block_timestamp": "2026-01-15T15:42:00Z"
}
]
}
```
| Field | Type | Description |
|-------|------|-------------|
| `batch_id` | `string` | Batch identifier. |
| `catalog_id` | `string` | Catalogue the batch belongs to. |
| `merkle_root` | `string` | Merkle root hash (64 hex characters). |
| `track_count` | `integer` | Total tracks in the catalogue. |
| `golden_record_count` | `integer` | Tracks that qualified as Golden Records. |
| `status` | `string` | Batch status: `"certified"`, `"anchoring"`, `"confirmed"`. |
| `certified_at` | `string \| null` | When certification was issued. |
| `confirmed_at` | `string \| null` | When the blockchain anchor was confirmed. |
| `certification_version` | `string \| null` | Schema version. |
| `anchors` | `array` | Blockchain anchors (same schema as `/verify`). |
---
### `GET /api/v1/certifications/{catalog_id}/certificate/{isrc}`
Download a per-track certification document as a JSON file.
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
| `isrc` | `string` | ISRC of the track. |
#### Response
Returns a JSON file download (`Content-Disposition: attachment; filename="certificate_{isrc}.json"`). The certificate document contains the track's canonical JSON, record hash, Merkle proof, and certification metadata.
---
### `GET /api/v1/certifications/{catalog_id}/report`
Download the full catalogue certification report as a JSON file.
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
#### Response
Returns a JSON file download (`Content-Disposition: attachment; filename="catalog_report_{catalog_id}.json"`). The report includes all certified tracks, batch metadata, aggregate statistics, and blockchain anchor details.
---
### `GET /api/v1/certifications/{catalog_id}/chain-of-title`
Download the chain of title export for a catalogue.
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
#### Response
Returns a JSON file download (`Content-Disposition: attachment; filename="chain_of_title_{catalog_id}.json"`). Contains the rights chain evidence for all certified tracks in the catalogue.
---
### `GET /api/v1/certifications/{catalog_id}/proof-bundle`
Download the complete proof bundle as a self-contained ZIP archive. This archive contains everything needed for independent, offline verification.
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
#### Response
Returns a ZIP file download (`Content-Disposition: attachment; filename="proof_bundle_{catalog_id}.zip"`). See [Glossary: Proof Bundle](/glossary#proof-bundle) for contents.
---
### `GET /api/v1/certifications/{catalog_id}/{isrc}`
Return the current certification status for a specific track.
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
| `isrc` | `string` | ISRC of the track. |
#### Response body
```json
{
"isrc": "GBAYE0100538",
"record_hash": "a1b2c3d4e5f6...64 hex characters",
"canonical_json": "{...}",
"certification_version": "1.0",
"title": "The Wicker Man",
"artist": "Iron Maiden",
"iswc": "T-010.466.720-3",
"writer_count": 3,
"certified_at": "2026-01-15T14:30:00Z",
"merkle_root": "e7f8a9b0c1d2...64 hex characters",
"batch_status": "confirmed",
"anchors": [
{
"chain": "bitcoin",
"status": "confirmed",
"tx_id": "3a1b2c3d...",
"block_number": 879234,
"block_timestamp": "2026-01-15T15:42:00Z"
}
]
}
```
| Field | Type | Description |
|-------|------|-------------|
| `isrc` | `string` | The track's ISRC. |
| `record_hash` | `string` | SHA-256 hash of the canonical JSON (64 hex characters). |
| `canonical_json` | `string \| null` | The canonical JSON used for certification. |
| `certification_version` | `string \| null` | Schema version. |
| `title` | `string \| null` | Track title. |
| `artist` | `string \| null` | Primary artist name. |
| `iswc` | `string \| null` | Primary ISWC. |
| `writer_count` | `integer \| null` | Number of credited writers. |
| `certified_at` | `string \| null` | Certification timestamp (ISO 8601). |
| `merkle_root` | `string \| null` | Batch Merkle root. |
| `batch_status` | `string \| null` | Status of the parent batch. |
| `anchors` | `array` | Blockchain anchors. |
---
### `GET /api/v1/certifications/{catalog_id}`
Return a high-level certification summary for a catalogue.
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
#### Response body
```json
{
"catalog_id": "cat_01HZ...",
"latest_batch_id": "batch_01HZ...",
"latest_batch_status": "confirmed",
"merkle_root": "e7f8a9b0c1d2...64 hex characters",
"certified_track_count": 138,
"total_golden_records": 138,
"certified_at": "2026-01-15T14:30:00Z"
}
```
| Field | Type | Description |
|-------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
| `latest_batch_id` | `string \| null` | Most recent batch ID. `null` if never certified. |
| `latest_batch_status` | `string \| null` | Status of the latest batch. |
| `merkle_root` | `string \| null` | Merkle root of the latest batch. |
| `certified_track_count` | `integer` | Number of currently certified tracks. |
| `total_golden_records` | `integer` | Total Golden Records in the latest batch. |
| `certified_at` | `string \| null` | When the latest batch was certified. |
---
## Admin endpoint
### `POST /api/v1/certifications/{catalog_id}/certify`
Trigger the full certification workflow for a catalogue. This is an administrative operation that fetches Golden Records, canonicalises them, constructs the Merkle tree, stores certifications, and submits the Merkle root for blockchain anchoring.
**Authentication:** Admin-only (requires admin role via Clerk).
#### Path parameters
| Parameter | Type | Description |
|-----------|------|-------------|
| `catalog_id` | `string` | Catalogue identifier. |
#### Response body
```json
{
"batch_id": "batch_01HZ...",
"merkle_root": "e7f8a9b0c1d2...64 hex characters",
"track_count": 142,
"golden_record_count": 138,
"status": "certified",
"certifications": [
{
"isrc": "GBAYE0100538",
"record_hash": "a1b2c3d4..."
}
],
"anchor_status": {
"submitted": true,
"calendar_response": "..."
}
}
```
| Field | Type | Description |
|-------|------|-------------|
| `batch_id` | `string` | Newly created batch identifier. |
| `merkle_root` | `string` | Merkle root of the certification tree. |
| `track_count` | `integer` | Total tracks in the catalogue. |
| `golden_record_count` | `integer` | Tracks that qualified as Golden Records. |
| `status` | `string` | Initial batch status (typically `"certified"`). |
| `certifications` | `array` | List of individual track certifications created. |
| `anchor_status` | `object` | Status of the OpenTimestamps submission. |
#### Error responses
| Status | Condition |
|--------|-----------|
| `400` | No Golden Records found, or certification prerequisites not met. |
| `401` | Not authenticated. |
| `403` | User does not have admin role. |
| `404` | Catalogue not found. |
---
# Merkle Proof Format
TrackForge uses a binary Merkle tree to commit all certified tracks in a batch to a single root hash. This root hash is then anchored to the Bitcoin blockchain via [OpenTimestamps](./opentimestamps). Any individual track can prove its inclusion in the batch using a compact Merkle proof, without revealing any other track's data.
## Merkle proof JSON structure
Each track's inclusion proof is represented as a `MerkleProof` object:
```json
{
"leaf_hash": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
"proof_hashes": [
"b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3",
"c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4"
],
"proof_directions": ["right", "left"],
"root_hash": "d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5",
"leaf_index": 0,
"total_leaves": 4
}
```
| Field | Type | Description |
|-------|------|-------------|
| `leaf_hash` | `string` | SHA-256 hex digest of the track's [canonical JSON](./canonical-json-schema). 64 characters. |
| `proof_hashes` | `array[string]` | Sibling hashes from leaf to root. Each is a 64-character hex string. |
| `proof_directions` | `array[string]` | Direction of each sibling: `"left"` or `"right"`. Same length as `proof_hashes`. |
| `root_hash` | `string` | Merkle root hash. 64 characters. This is the value anchored to the blockchain. |
| `leaf_index` | `integer` | Zero-based position of this leaf in the sorted leaf array. |
| `total_leaves` | `integer` | Total number of leaves in the tree. |
## Tree construction rules
### 1. Leaf ordering
Before building the tree, all leaf hashes are **sorted lexicographically** (standard string sort on 64-character hex strings). This ensures that the tree structure is deterministic regardless of the order in which tracks were processed.
```python
leaves = sorted(leaf_hashes)
```
### 2. Odd-number duplication
If a layer has an odd number of nodes, the **last node is duplicated** to form a complete pair:
```python
for i in range(0, len(current_layer), 2):
left = current_layer[i]
right = current_layer[i + 1] if i + 1 < len(current_layer) else left
parent = combine_hashes(left, right)
```
### 3. Hash combination function
Two sibling hashes are combined by concatenating their hex string representations and hashing the result with SHA-256:
```python
import hashlib
def combine_hashes(left: str, right: str) -> str:
combined = (left + right).encode("utf-8")
return hashlib.sha256(combined).hexdigest()
```
The input to SHA-256 is the UTF-8 encoding of the concatenated hex strings (128 ASCII characters for two 64-character hashes), **not** raw binary. This is a deliberate design choice for simplicity and reproducibility across languages.
### 4. Bottom-up construction
The tree is built layer by layer from the leaves upward. Each layer is produced by pairing adjacent nodes and combining them. The process continues until a single root hash remains.
## Verification algorithm
To verify that a leaf belongs to a tree with a given root hash:
```
INPUT: leaf_hash, proof_hashes[], proof_directions[], root_hash
OUTPUT: boolean (valid or invalid)
1. Set current = leaf_hash
2. For each i from 0 to len(proof_hashes) - 1:
a. sibling = proof_hashes[i]
b. direction = proof_directions[i]
c. If direction == "right":
current = SHA-256(current + sibling)
Else (direction == "left"):
current = SHA-256(sibling + current)
3. Return current == root_hash
```
The `direction` indicates where the **sibling** sits relative to the current node. If the sibling is on the `"right"`, the current node is the left child, so we hash `current + sibling`. If the sibling is on the `"left"`, the current node is the right child, so we hash `sibling + current`.
### Python implementation
```python
import hashlib
def verify_merkle_proof(proof: dict) -> bool:
current = proof["leaf_hash"]
for sibling, direction in zip(proof["proof_hashes"], proof["proof_directions"]):
if direction == "right":
combined = (current + sibling).encode("utf-8")
else:
combined = (sibling + current).encode("utf-8")
current = hashlib.sha256(combined).hexdigest()
return current == proof["root_hash"]
```
### JavaScript implementation
```javascript
async function verifyMerkleProof(proof) {
let current = proof.leaf_hash;
for (let i = 0; i < proof.proof_hashes.length; i++) {
const sibling = proof.proof_hashes[i];
const direction = proof.proof_directions[i];
const combined = direction === "right"
? current + sibling
: sibling + current;
const encoded = new TextEncoder().encode(combined);
const hashBuffer = await crypto.subtle.digest("SHA-256", encoded);
const hashArray = Array.from(new Uint8Array(hashBuffer));
current = hashArray.map(b => b.toString(16).padStart(2, "0")).join("");
}
return current === proof.root_hash;
}
```
## Worked example: 4-leaf tree
Consider four tracks with the following record hashes (already sorted lexicographically):
```
Leaf 0: 1111111111111111111111111111111111111111111111111111111111111111
Leaf 1: 2222222222222222222222222222222222222222222222222222222222222222
Leaf 2: 3333333333333333333333333333333333333333333333333333333333333333
Leaf 3: 4444444444444444444444444444444444444444444444444444444444444444
```
### Tree structure
```
Root
/ \
H01 H23
/ \ / \
Leaf0 Leaf1 Leaf2 Leaf3
```
### Step-by-step construction
**Layer 0 (leaves):** `[Leaf0, Leaf1, Leaf2, Leaf3]`
**Layer 1 (parents):**
- `H01 = SHA-256("1111...1111" + "2222...2222")`
- `H23 = SHA-256("3333...3333" + "4444...4444")`
**Layer 2 (root):**
- `Root = SHA-256(H01 + H23)`
### Proof for Leaf 2
To prove that Leaf 2 is in the tree, the proof contains:
```json
{
"leaf_hash": "3333333333333333333333333333333333333333333333333333333333333333",
"proof_hashes": [
"4444444444444444444444444444444444444444444444444444444444444444",
""
],
"proof_directions": ["right", "left"],
"root_hash": "",
"leaf_index": 2,
"total_leaves": 4
}
```
**Verification steps:**
1. Start with `current = Leaf2` (`3333...3333`)
2. Sibling `Leaf3` is on the **right**: `current = SHA-256(current + "4444...4444")` = `H23`
3. Sibling `H01` is on the **left**: `current = SHA-256(H01 + current)` = `Root`
4. Compare `current` with `root_hash` — they match. The proof is valid.
## Proof size
For a tree with _n_ leaves, the proof contains `ceil(log2(n))` sibling hashes. For a catalogue of 1,000 tracks, each proof is only 10 hashes (640 hex characters). This logarithmic scaling means proof size remains practical even for very large catalogues.
| Catalogue size | Proof depth | Proof data |
|----------------|-------------|------------|
| 10 tracks | 4 hashes | 256 bytes |
| 100 tracks | 7 hashes | 448 bytes |
| 1,000 tracks | 10 hashes | 640 bytes |
| 10,000 tracks | 14 hashes | 896 bytes |
| 100,000 tracks | 17 hashes | 1,088 bytes |
---
# OpenTimestamps Integration
TrackForge uses the [OpenTimestamps](https://opentimestamps.org/) (OTS) protocol to anchor certification Merkle roots to the Bitcoin blockchain. This creates a permanent, independently verifiable timestamp proving that the certified metadata existed at a specific point in time.
## How OpenTimestamps works
OpenTimestamps is an open protocol for creating blockchain-backed timestamps. The core principle is straightforward: a SHA-256 digest is submitted to one or more calendar servers, which aggregate multiple timestamps into a single Bitcoin transaction. Once that transaction is confirmed in a block, the timestamp becomes permanent and immutable.
### The aggregation model
Rather than creating a separate Bitcoin transaction for every timestamp (which would be prohibitively expensive), OTS calendar servers collect many timestamp requests and combine them into a Merkle tree of their own. The root of this aggregation tree is committed to a single Bitcoin transaction. This means:
- **Cost**: Timestamping is effectively free. Calendar servers absorb the Bitcoin transaction fee.
- **Throughput**: Thousands of timestamps can share a single transaction.
- **Delay**: There is a delay between submission and Bitcoin confirmation (typically 1-12 hours, depending on the calendar server's aggregation schedule and Bitcoin block times).
### What goes on the blockchain
The Bitcoin transaction contains **only a hash** — a 32-byte commitment (the OTS calendar's Merkle root). No metadata, no personal data, no track information. The blockchain records nothing except the cryptographic commitment and the block timestamp.
## TrackForge's integration
### Direct HTTP (no Python library)
TrackForge interacts with OTS calendar servers via direct HTTP requests rather than importing the `opentimestamps-client` Python package. This architectural decision was made for several reasons:
1. **Minimal dependency surface** — The calendar server API is two endpoints. A full client library adds unnecessary complexity and dependency risk.
2. **Async compatibility** — TrackForge's backend is fully async (FastAPI + asyncpg). The official Python OTS client is synchronous.
3. **Deterministic behaviour** — Direct HTTP calls are easier to test, mock, and reason about.
### Submission flow
When a certification batch is created, the following sequence occurs:
```
1. Build Merkle tree from all track record hashes
2. Extract the 32-byte Merkle root (SHA-256 digest)
3. POST the raw digest to OTS calendar server(s)
4. Store the calendar server response (pending timestamp)
5. Poll for Bitcoin confirmation
6. Store confirmed anchor details (block, tx, proof)
```
### Calendar server interaction
#### Submitting a digest
```
POST https://a.pool.opentimestamps.org/digest
Content-Type: application/x-www-form-urlencoded
Body:
```
The calendar server responds with a binary OTS proof file (incomplete — not yet anchored to Bitcoin). This incomplete proof is stored and used to poll for confirmation.
Multiple calendar servers can be used in parallel for redundancy:
| Server | URL |
|--------|-----|
| Alice | `https://a.pool.opentimestamps.org` |
| Bob | `https://b.pool.opentimestamps.org` |
| Finney | `https://finney.calendar.eternitywall.com` |
#### Checking for confirmation
```
GET https://a.pool.opentimestamps.org/timestamp/
```
The server returns one of:
- **Pending**: The digest has been received but not yet included in a Bitcoin transaction. HTTP 200 with an incomplete proof.
- **Confirmed**: The digest has been anchored. HTTP 200 with a complete proof containing the Bitcoin block number, transaction ID, and Merkle path from the digest to the transaction's `OP_RETURN` output.
### Stored anchor data
Once confirmed, TrackForge stores the following anchor record:
| Field | Type | Description |
|-------|------|-------------|
| `chain` | `string` | Always `"bitcoin"`. |
| `status` | `string` | `"pending"`, `"submitted"`, or `"confirmed"`. |
| `tx_id` | `string` | Bitcoin transaction ID (64-character hex). |
| `block_number` | `integer` | Bitcoin block height. |
| `block_timestamp` | `string` | Block timestamp (ISO 8601). |
| `proof_data` | `binary` | The complete OTS proof file. |
## The OTS proof file
An OTS proof file (`.ots`) is a binary format that encodes the complete chain of operations from the original digest to the Bitcoin blockchain commitment. It contains:
1. **The original digest** — The SHA-256 hash that was timestamped.
2. **Intermediate operations** — A sequence of hash operations (append, prepend, SHA-256) that transform the original digest into the value committed to the Bitcoin transaction.
3. **Bitcoin attestation** — The block height and Merkle path within the Bitcoin block that proves inclusion.
The proof file is self-contained: given the original data and the proof file, anyone can verify the timestamp without contacting any server. This is critical for long-term verifiability — even if TrackForge and all calendar servers cease to exist, the proof remains valid as long as the Bitcoin blockchain is accessible.
### Proof bundle inclusion
The `.ots` proof file for each certification batch is included in the [proof bundle](./verification-api#get-apiv1certificationscatalog_idproof-bundle) ZIP archive. This ensures that catalogue owners have everything needed for fully offline, independent verification.
## Independent verification
### Using ots-cli
The reference OpenTimestamps client can verify any `.ots` proof file:
```bash
# Install the OTS client
pip install opentimestamps-client
# Verify a proof file against the original data
ots verify certificate_merkle_root.ots
```
The client will:
1. Parse the proof file.
2. Replay the hash operations from the original digest.
3. Check the resulting value against the Bitcoin blockchain.
4. Report whether the timestamp is valid and when it was confirmed.
### Using any OTS verifier
Because OpenTimestamps is an open protocol, any compliant verifier can check the proof. This includes:
- **Web verifier**: [opentimestamps.org](https://opentimestamps.org/) provides a browser-based verification tool.
- **Third-party libraries**: OTS libraries exist for JavaScript, Rust, Go, Java, and other languages.
- **Manual verification**: The proof format is documented and can be verified by replaying the hash operations against a Bitcoin full node.
### Verification without TrackForge
The complete verification chain is:
1. **Re-serialise** the track metadata into [canonical JSON](./canonical-json-schema) using the documented rules.
2. **Hash** the canonical JSON with SHA-256 to produce the record hash.
3. **Verify the Merkle proof** using the [inclusion proof](./merkle-proof-format) to confirm the record hash is committed to the Merkle root.
4. **Verify the OTS proof** using the `.ots` file to confirm the Merkle root was anchored to a specific Bitcoin block at a specific time.
No step in this chain requires contacting TrackForge. All data and proofs are included in the proof bundle.
## Timing and status
### Lifecycle of an anchor
| Status | Meaning | Typical duration |
|--------|---------|-----------------|
| `pending` | Certification created, not yet submitted to calendar server. | Seconds. |
| `submitted` | Digest sent to calendar server, awaiting Bitcoin inclusion. | 1-12 hours (depends on calendar server schedule and Bitcoin block times). |
| `confirmed` | Included in a Bitcoin block. Permanent and immutable. | Permanent. |
### Why confirmation takes hours
Calendar servers batch many timestamp requests into a single Bitcoin transaction. They typically submit a new transaction every few hours. After submission, the transaction must be mined into a block (average 10 minutes, but can vary). The total time from submission to confirmation is therefore a function of the calendar server's batching schedule plus Bitcoin's block time.
This delay has no impact on the certification's integrity. The certification is cryptographically complete the moment the Merkle tree is built and the canonical JSON is hashed. The blockchain anchor adds an independent, third-party timestamp — it does not alter the certified data.
---
# Data Security & Privacy
TrackForge's certification system is designed with a strict separation between cryptographic commitments (which are public) and the underlying metadata (which is private). This page documents the technical boundaries that enforce this separation.
## Public vs private data
### Data that is publicly visible
The following data points are inherently public or become public through the certification process:
| Data | Where visible | Why public |
|------|--------------|------------|
| ISRC | Certificate metadata, verification response | Industry-standard public identifier for sound recordings. |
| Certification date | Certificate metadata, verification response | The timestamp is the point of the certification. |
| Certification version | Certificate metadata, verification response | Required for verifiers to know which schema was used. |
| Record hash | Certificate metadata, verification response, Merkle tree | SHA-256 digest of the canonical JSON. Reveals nothing about the content. |
| Merkle root | Batch metadata, blockchain transaction | The single hash anchored to Bitcoin. Reveals nothing about individual tracks. |
| Bitcoin transaction ID | Anchor metadata | Publicly visible on the Bitcoin blockchain. Contains only the Merkle root hash. |
| Bitcoin block number | Anchor metadata | Public blockchain data. |
### Data that is never public
The following data is **never** exposed through public endpoints, blockchain transactions, or the verification page:
| Data | Protection | Reason |
|------|-----------|--------|
| Writer names | Authenticated API only | Personal data; rights-sensitive. |
| IPI numbers | Authenticated API only | Personal identifiers within PRO systems. |
| Writer shares | Authenticated API only | Commercially sensitive; often disputed. |
| Catalogue names | Authenticated API only | Client confidential. |
| Track titles | Authenticated API only | Client confidential (until public release). |
| Artist names | Authenticated API only | Client confidential (until public release). |
| Canonical JSON | Authenticated API only | Contains all of the above. |
| Operator audit trails | Authenticated API only | Internal process records. |
### What the blockchain contains
The Bitcoin blockchain contains **exactly one data point** per certification batch: the Merkle root hash. This is a 64-character hexadecimal string (256 bits) committed via an `OP_RETURN` output in a Bitcoin transaction.
It is computationally infeasible to derive any information about the certified tracks from the Merkle root. SHA-256 is a one-way function: given the hash, there is no known method to reconstruct the input data. The Merkle root is itself a hash of hashes, adding further layers of indirection.
Concretely, examining the Bitcoin transaction reveals:
```
OP_RETURN d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5
```
Nothing in this value indicates that it relates to music metadata, TrackForge, or any specific catalogue. Without the corresponding proof files and canonical JSON, the hash is meaningless.
## Verification page privacy
The public verification endpoint (`POST /api/v1/certifications/verify`) and any future web-based verification page are designed with the following privacy controls:
### No cookies
The verification page sets no cookies of any kind — no session cookies, no analytics cookies, no tracking cookies. There is no persistent state stored in the user's browser.
### No tracking
No analytics scripts, no third-party trackers, no fingerprinting. The page loads the minimum required assets and nothing else.
### Client-side hashing
When a web-based verification interface is provided, the SHA-256 hash of the canonical JSON is computed **client-side** using the Web Crypto API:
```javascript
const encoder = new TextEncoder();
const data = encoder.encode(canonicalJson);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);
```
This means the canonical JSON (which contains sensitive writer and rights data) **never leaves the user's browser**. Only the resulting hash is sent to the server for verification. The server cannot reconstruct the canonical JSON from the hash.
### Server-side verification flow
When the server receives a verification request:
1. It computes the SHA-256 hash of the submitted `canonical_json`.
2. It looks up the hash in the certification database.
3. It returns whether a match exists, along with public metadata (ISRC, certification date, anchor details).
The server does not log, store, or forward the submitted canonical JSON. The verification endpoint is stateless.
## Data handling boundaries
### Authentication boundary
| Endpoint | Auth required | Sensitive data returned |
|----------|--------------|----------------------|
| `POST /verify` | No | No. Returns only hash, ISRC, dates, anchor info. |
| `GET /batch/{batch_id}` | Yes | Batch-level aggregates only. |
| `GET /{catalog_id}` | Yes | Summary statistics only. |
| `GET /{catalog_id}/{isrc}` | Yes | Yes: canonical JSON, writer count. |
| `GET /{catalog_id}/certificate/{isrc}` | Yes | Yes: full certificate with canonical JSON. |
| `GET /{catalog_id}/report` | Yes | Yes: full catalogue report. |
| `GET /{catalog_id}/chain-of-title` | Yes | Yes: rights chain evidence. |
| `GET /{catalog_id}/proof-bundle` | Yes | Yes: complete proof archive. |
### Rate limiting
The public verification endpoint is rate-limited to **100 requests per minute per IP address**. This prevents enumeration attacks (attempting to discover certified ISRCs by brute-forcing the endpoint) while allowing legitimate verification use.
### Proof bundle security
The proof bundle ZIP archive contains all data needed for independent verification, including canonical JSON and Merkle proofs. It is available only to authenticated users with access to the catalogue. Once downloaded, the security of the proof bundle is the responsibility of the catalogue owner — TrackForge recommends treating it with the same care as other confidential business records.
## GDPR-relevant technical controls
### Personal data identification
Under GDPR, the following certified fields may constitute personal data:
| Field | Personal data? | Basis |
|-------|---------------|-------|
| Writer names | Yes | Directly identifies natural persons. |
| IPI numbers | Yes | Unique identifiers linked to natural persons. |
| Writer shares | Potentially | When combined with writer names, reveals financial arrangements. |
| Performer names | Yes | Directly identifies natural persons. |
| ISRC | No | Identifies a recording, not a person. |
| Track title | No | Not personal data in itself. |
### Technical measures
1. **No personal data on blockchain** — The blockchain contains only the Merkle root hash. No personal data is written to any public ledger.
2. **Hash irreversibility** — SHA-256 record hashes cannot be reversed to obtain the canonical JSON containing personal data.
3. **Access control** — All endpoints that return personal data (canonical JSON, certificates, reports) require authentication.
4. **No public enumeration** — The verification endpoint requires the full canonical JSON as input. An attacker cannot enumerate certified records without already possessing the data.
5. **Stateless verification** — The public verification endpoint does not log or store submitted canonical JSON.
6. **Data minimisation** — The canonical JSON includes only rights-determinative fields. Engagement metrics, internal workflow data, and other non-essential data are excluded.
### Right to erasure considerations
If a data subject exercises their right to erasure under GDPR Article 17:
- **Canonical JSON** and certification records stored in the TrackForge database can be deleted.
- **Record hashes** (SHA-256 digests) stored in the database can be deleted.
- **The Merkle root on the Bitcoin blockchain cannot be altered or deleted.** However, the Merkle root is a hash of hashes and cannot be linked to any individual without the corresponding proof chain. Deletion of the proof chain and canonical JSON renders the blockchain entry meaningless.
This approach aligns with GDPR Recital 26, which states that the principles of data protection should not apply to information that does not relate to an identified or identifiable natural person, or to personal data rendered anonymous in such a manner that the data subject is no longer identifiable.
---
---
# Glossary
# Glossary
### Blockchain Anchor
The permanent record of a Merkle root hash in a Bitcoin transaction. TrackForge submits the Merkle root to [OpenTimestamps](/technical/opentimestamps) calendar servers, which aggregate it into a Bitcoin transaction. Once confirmed in a block, the anchor is immutable — it cannot be altered or removed. The anchor proves that the Merkle root (and therefore all tracks committed to it) existed at or before the block's timestamp.
### Bronze Tier
Partially enriched metadata meeting minimum certification requirements (ISRC, duration, and at least one of ISWC or identified writer). Bronze tracks have core recording identifiers and at least some compositional data, but gaps remain. Those gaps are documented transparently in the certification. See [Certification Tiers](/methodology/golden-record-selection).
### Canonical JSON
The deterministic, normalised JSON representation of a track's certified metadata. Canonical JSON is produced using strict serialisation rules: sorted keys, no whitespace, ASCII-safe encoding, and removal of null/empty values. Given identical input data, the canonical JSON is always byte-exact, ensuring that the SHA-256 hash is reproducible. See the full specification at [Canonical JSON Schema](/technical/canonical-json-schema).
### Certification Batch
A set of tracks — typically one catalogue — that are certified together and share a single Merkle tree. All tracks in a batch are hashed, assembled into the tree, and anchored to the blockchain as a unit. The batch is the fundamental unit of blockchain anchoring: one batch produces one Merkle root, which is committed in one Bitcoin transaction.
### Certification Tier
The level of verification depth assigned to a certified track, ranging from Gold (highest) to Declared (user-submitted). The tier is determined by the completeness and corroboration of the track's metadata — how many required fields are present, how many independent sources have confirmed the data, and whether a human operator has reviewed the result. See [Certification Tiers](/methodology/golden-record-selection) for the full tier definitions and decision process.
### Declared Tier
User-submitted metadata that has been cryptographically timestamped but not independently verified by TrackForge. The only requirement is a valid ISRC. Declared certifications attest that the submitting party declared the metadata at a specific point in time — they do not attest to the accuracy of the declared data. See [Certification Tiers](/methodology/golden-record-selection).
### Golden Record
A track metadata record that meets TrackForge's data completeness requirements for certification. In Methodology Version 1.0, this was a binary qualification (pass/fail). In Methodology Version 2.0, the concept has been replaced by [Certification Tiers](#certification-tier), with the original Golden Record criteria approximately equivalent to the [Silver Tier](#silver-tier). The term "Golden Record" may still appear in legacy documentation and certifications produced under v1.0.
### Gold Tier
Highest certification level. Track has complete, multi-source-verified metadata with writer ownership shares summing to approximately 100%, corroboration from two or more independent authoritative sources, and documented human operator review and approval. Gold represents the strongest evidentiary standard TrackForge offers. See [Certification Tiers](/methodology/golden-record-selection).
### IPI
Interested Party Information number. A unique numeric identifier assigned to writers and publishers by collecting societies (PROs) worldwide, administered under the CISAC CIS-Net system. IPI numbers are used to unambiguously identify rights holders across territorial boundaries — a writer may be known by different names or spellings in different territories, but their IPI is globally unique.
### ISRC
International Standard Recording Code. A 12-character alphanumeric code (e.g. `GBAYE0100538`) that uniquely identifies a specific sound recording. ISRCs are assigned by national agencies and are the primary identifier used across streaming platforms, collecting societies, and rights databases. Each ISRC identifies a particular recording — not the underlying composition, which is identified by an [ISWC](#iswc).
### ISWC
International Standard Musical Work Code. A unique identifier for the underlying musical composition (the "work"), as distinct from any particular recording of it. An ISWC takes the form `T-NNN.NNN.NNN-C` (e.g. `T-010.466.720-3`). Multiple recordings (each with their own ISRC) may share the same ISWC if they are performances of the same composition.
### Merkle Proof (Inclusion Proof)
A compact set of sibling hashes that proves a specific leaf (track hash) belongs to a Merkle tree with a given root hash. The proof is logarithmic in size: for a tree of 1,000 leaves, only 10 hashes are needed. Verification involves replaying the hash chain from the leaf to the root and comparing the result. See the full specification at [Merkle Proof Format](/technical/merkle-proof-format).
### Merkle Root
The single hash at the top of a binary Merkle tree, representing all leaf values in the tree. In TrackForge's system, the Merkle root commits to every certified track in a batch. It is the value anchored to the Bitcoin blockchain via OpenTimestamps. Changing any single leaf (track hash) would produce a completely different root, making tampering detectable.
### Merkle Tree
A binary hash tree in which every leaf node is a hash of data (in TrackForge's case, the SHA-256 of a track's canonical JSON), and every non-leaf node is the hash of its two children. The tree reduces an arbitrary number of hashes to a single root hash, while allowing any individual leaf to prove its inclusion via a compact [Merkle proof](#merkle-proof-inclusion-proof). See [Merkle Proof Format](/technical/merkle-proof-format) for construction rules.
### OpenTimestamps
An open protocol for creating blockchain-backed timestamps without requiring direct interaction with the Bitcoin network. Timestamp requests are submitted to calendar servers, which aggregate many requests into a single Bitcoin transaction. The protocol produces self-contained proof files (`.ots`) that can be verified independently of any server. See [OpenTimestamps Integration](/technical/opentimestamps) for TrackForge's implementation.
### Process Fidelity
The principle that TrackForge certification attests to the rigour of the verification process, not to absolute legal truth. A certification confirms that a documented, repeatable, multi-source enrichment and validation process was followed and that the metadata was in the stated condition at the stated time. It does not guarantee that no competing claims, errors, or contradictions exist. The depth of the process varies by [certification tier](#certification-tier). This concept is analogous to title insurance in property law. See [Scope & Legal Positioning](/for-lawyers/certification-scope) for the full legal analysis.
### Proof Bundle
A self-contained ZIP archive containing all data and cryptographic proofs needed for independent, offline verification of a catalogue's certification. The bundle typically includes: per-track certificates (with canonical JSON, record hashes, and Merkle proofs), the batch metadata, the OpenTimestamps `.ots` proof file, and verification instructions. With this bundle, any third party can verify the certification without contacting TrackForge.
### Re-Certification
The process of issuing a new certification version when a track's metadata changes after initial certification. The new certification is cryptographically linked to its predecessor by including the previous record hash, forming a [version chain](#version-chain). Re-certification creates a new leaf in a new Merkle tree — it does not alter or invalidate the original certification, which remains a valid record of the metadata at that earlier point in time.
### SHA-256
Secure Hash Algorithm 256-bit. A cryptographic hash function that produces a fixed-size 256-bit (64 hexadecimal character) digest from arbitrary input data. SHA-256 is a one-way function: given a hash, it is computationally infeasible to determine the original input. TrackForge uses SHA-256 at every level of the certification system — hashing canonical JSON into record hashes, combining sibling hashes in the Merkle tree, and producing the Merkle root submitted to the blockchain.
### Silver Tier
Structurally complete metadata with verified writer identities (IPIs). Requires ISRC, ISWC, duration, and at least one writer with a verified name and IPI number. Equivalent to the original Golden Record standard from Methodology Version 1.0. Silver represents strong automated verification without dedicated human review. See [Certification Tiers](/methodology/golden-record-selection).
### Tier Promotion
The process of re-certifying a track at a higher tier after additional data or verification becomes available. For example, a Bronze track may be promoted to Silver when a missing ISWC or writer IPI is obtained, or a Silver track may be promoted to Gold after complete share data is provided and human review is performed. Promotion creates a new certification linked cryptographically to the previous one. See [Certification Tiers](/methodology/golden-record-selection#tier-promotion).
### Version Chain
The cryptographic linked list of certification versions for a track. When a track is re-certified, the new certification references the previous certification's record hash, creating an immutable chain of provenance. Each link in the chain is a separate, independently verifiable certification anchored to its own Merkle tree and blockchain timestamp. The version chain provides a complete audit history of how a track's certified metadata has evolved over time.
---