# TrackForge - Complete Public Documentation For LLM Context > Current public contract: methodology v1.1 AAA-D rating from run-scoped results-page leakage findings, original ingested catalogue population, UK/US direct scope, PRS/SearchWorks WACD agreement binding and ISWC coverage where in scope, and legacy medal fields only as compatibility. > Summary: https://trackforge.studio/llms.txt > Source: https://trackforge.studio # Public Site Markdown --- ## index.md # TrackForge > The Rights Rating Agency — cryptographically verifiable risk assessment for the music asset class. *Published by [TrackForge](https://trackforge.studio)* --- ## The Rights Rating Agency Cryptographically verifiable risk assessment for the music asset class. ### Services - **Track certification** — Independent verification of individual track metadata, registrations, and rights chains - **Portfolio grades AAA–D** — Standardised catalogue ratings using the Value Chain Maturity Model - **CWR Validator** — Free online tool for validating Common Works Registration files against CISAC specifications --- ## Essays and Research ### Why TrackForge Exists Music catalogues are one of the fastest-growing alternative asset classes in the world. Billions flow into acquisitions every year. Every one of these transactions shares the same structural weakness: there is no standardised way to verify what is being bought. [Read the full essay](/why) ### The Black Box IT upgrades and billions redirected. How the music industry's back-office infrastructure silently reshapes who gets paid — and how much goes missing in transit. [Read the full briefing](/black-box) ### The Unclaimed Economy 4.25 million musical works have unclaimed US mechanical royalties at the MLC. 67.5% are registered at ASCAP. 73% stream on Spotify. A structural registration gap that isn't closing. [Read the full research note](/research/unclaimed-economy) ### Free CWR Tools Generate, validate, inspect, and parse ACK responses for CWR files directly in your browser. The only free public CWR generator. Supports CWR 2.1 and 2.2 with full record-level validation, transaction grouping, and exportable reports. [Open CWR Tools](/cwr-tool) --- ## Sample Ratings Download a sample rating built from a real UK indie catalogue with anonymised data and real insights. - **Catalogue Health Assessment** — 9 pages, commercial focus. Results-page failure modes, registration coverage, and recovery roadmap. For rights holders. - **Due Diligence Rating** — 22 pages, institutional focus. Institutional-grade risk assessment, v1.1 leakage scoring, and valuation impact. For acquirers and investors. --- ## Contact - Email: [contact@trackforge.studio](mailto:contact@trackforge.studio) - Partner login: [ops.trackforge.studio/forge](https://ops.trackforge.studio/forge/) --- Source: [https://trackforge.studio/](https://trackforge.studio/) --- ## why.md # Why TrackForge Exists > The case for independent catalogue verification in the music asset class. *Published by [TrackForge](https://trackforge.studio)* --- Music catalogues are one of the fastest-growing alternative asset classes in the world. Billions flow into acquisitions every year. Every one of these transactions shares the same structural weakness: there is no standardised way to verify what is being bought. Bond markets have credit ratings. Real estate has standardised appraisals. Equities have audited financial statements. Music catalogues — assets that routinely trade at eight- to fifteen-times annual revenue — have none of these. --- ## A Market for Lemons In 1970, the economist George Akerlof described what happens in markets where buyers cannot distinguish quality from junk. Sellers of high-quality goods cannot prove their quality, so buyers discount everything. The best assets are priced out of the market. The market contracts. Everyone loses. Akerlof was awarded the Nobel Memorial Prize in Economics in 2001 "for their analyses of markets with asymmetric information." A label that has spent years maintaining clean metadata, registering works with every relevant collection society, and resolving writer identities cannot prove any of this to a prospective buyer — at least not without commissioning expensive, one-off consultant work that the buyer has no way to independently verify. Meanwhile, a catalogue with incomplete registrations, missing identifiers, and unresolved rights chains looks identical on paper. The result is predictable. Buyers assume the worst and discount accordingly. ### Case Study: Hipgnosis Songs Fund, 2024 - **$690M** — gap between two independent valuations of the same assets - **67/105** — acquisitions subsequently found to have been overvalued - **75%** — of the portfolio was missing growth forecasts entirely This was not fraud. It was the predictable outcome of a market where there is no standardised way to measure the quality of what is being bought. --- ## The Due Diligence Bottleneck Traditional catalogue due diligence is a manual, consultant-driven process. A specialist team reviews metadata, checks registrations, examines rights chains, and produces a bespoke report. This works — but only at scale. | Deal Size | Typical DD Cost | Cost as % of Deal | Practical Result | |-----------|----------------|-------------------|-----------------| | £500M+ | £75–250K | 0.02–0.05% | Standard | | £50–500M | £75–250K | 0.05–0.5% | Marginal | | £5–50M | £75–250K | 0.5–5% | Prohibitive | | £1–5M | £75–250K | 5–25% | Impossible | The mid-tier catalogues — the ones that represent the vast majority of the market by count — are effectively locked out of institutional capital. Not because they lack value, but because there is no affordable, standardised way to verify that value. --- ## The Infrastructure Gap > "Every platform in this space serves the catalogue owner. TrackForge serves the truth." The music industry has no shortage of sophisticated technology. Dozens of platforms handle royalty accounting, rights management, distribution, sync licensing, and metadata administration. Many of them are excellent at what they do. But every one of these platforms serves the catalogue owner — they tell the owner what they already know, with greater efficiency. The question a buyer asks is: *Is what the seller claims actually true?* No operational platform answers this — because answering it requires looking at the catalogue from the outside in, cross-referencing against independent, authoritative sources the catalogue owner does not control. ### The buyer's due diligence checklist - Are the works registered at every relevant collection society — not just the ones the label filed with? - Do the writer splits at PRS match the splits at ASCAP match the splits at GEMA? - Are there competing claims on any works from other publishers? - Is the ISRC-to-ISWC linkage correct across all platforms? - Are neighbouring rights registrations in place at PPL and SoundExchange? - How much revenue is leaking because of registration gaps the owner may not even know about? --- ## Why Operational Platforms Cannot Become Verification Platforms This is a structural constraint, not a capability gap. The business model prevents it. 1. **Royalty Accounting Platforms** — Process payments based on data the client provides. If metadata is wrong, the system faithfully processes wrong royalties. Essential — but not verification. Ingestion is not audit. 2. **Rights Management Platforms** — Organise metadata, manage rights chains. Often described as "single source of truth" — but in practice, a record of assertion. Whatever the label enters is what the system shows. 3. **Distribution Platforms** — Deliver music to DSPs and collect revenue. Confirm delivery — but don't confirm registrations are complete or that royalties are being collected everywhere they should be. 4. **Enterprise Publishing Systems** — Process hundreds of millions of transaction lines at scale. Staggeringly capable at processing. But capability at processing is not the same as capability at verification. ### The Arthur Andersen Principle When the firm that audits your books is also the firm that helps you keep your books, the audit is compromised — not by bad intent, but by incentive structure. An independent rating requires structural separation from the entity being rated. It requires a business model where the rater's reputation — not the client's satisfaction — is the primary asset. No operational platform in the music industry has this structure, because it is incompatible with their core business of serving the catalogue owner. --- ## What TrackForge Does Differently ### 01. Independent Data Sourcing 24+ authoritative external databases — CMO registrations (PRS, ASCAP, BMI, GEMA, SACEM, The MLC, JASRAC), streaming platforms, industry reference databases, neighbouring rights registries, and forensic analysis tools. When sources conflict, higher-tier sources take precedence. ### 02. Published, Deterministic Methodology The rating engine applies a fixed ruleset -- no per-client customisation, no discretion. The v1.1 methodology translates results-page failure modes, agreement binding, ISWC coverage, population integrity, evidence, materiality, and remediation signals into standardised grades from AAA to D. A BB-rated catalogue in UK indie rock means the same thing as a BB-rated catalogue in German electronic music. ### 03. Cryptographic Verification Each rated snapshot and proof bundle is SHA-256 fingerprinted. Track snapshots are assembled into a Merkle tree; the methodology hash, rating inputs, and root hash are independently timestamped through OpenTimestamps and Bitcoin proof state. If TrackForge ceased to exist tomorrow, every rating it ever issued would remain independently verifiable. ### 04. Governance and Independence The rating engine is architecturally separated from enrichment -- read-only, deterministic, and unable to be manually overridden. Rating criteria are immutable constants. Modelled on IOSCO's Code of Conduct for Credit Rating Agencies. --- ## The Result > "Without certainty, you cannot price risk. Without pricing risk, capital cannot flow efficiently. TrackForge brings certainty." ### For Catalogue Owners A rating provides independent evidence of catalogue quality and registration risk. Investment-grade catalogues can support stronger buyer confidence, cleaner warranties, and more efficient pricing; weaker grades expose the specific issues that need remediation before a sale or financing process. ### For Buyers and Lenders Independent verification with published methodology, cryptographic evidence, and governance architecture. The rating is reproducible. The evidence is tamper-evident. The methodology is published and version-controlled. For the first time, catalogue quality is independently verifiable without relying solely on TrackForge. ### For the Market Standardised ratings solve the information asymmetry that has suppressed transaction volume, penalised well-maintained catalogues, and locked mid-tier assets out of institutional capital. When buyers can distinguish quality from noise, capital flows to the best assets. The market expands. --- Music catalogues are the last major asset class to lack this infrastructure. **TrackForge fills the gap.** --- Source: [https://trackforge.studio/why](https://trackforge.studio/why) --- ## black-box.md # The Biggest Wealth Transfer in Music History Was an IT Upgrade > A forensic briefing on how three database migrations quietly redirected billions from independent creators to major label groups. *Published by [TrackForge](https://trackforge.studio) — Adaptive Intelligence · February 2026* --- How three database migrations quietly redirected billions from independent creators to major label groups — and why nobody was supposed to notice. --- ## The bank that forgot your account Imagine you have a savings account at a high street bank. You've had it for twenty years. Every month, money flows in — not a fortune, but it's yours. Royalties from a song you wrote in 1998. A mechanical licence fee from a track that still gets played on Spotify playlists and coffee shop radios. Then one day, your bank upgrades its IT system. New servers. New software. A shiny new Oracle Cloud database. The press release calls it "a major modernisation initiative to improve efficiency and accuracy." There's just one problem. During the migration, the system that linked your name to your account number broke. Not dramatically — no alarm went off, no error message appeared on your screen. The connection simply... dissolved. Your money still arrives at the bank every month. It just doesn't know it's yours anymore. So it sits in a holding account. Unclaimed. For three years. Then, under the bank's own rules, that unclaimed money is redistributed — not back to you, not split equally among all customers — but divided up among the bank's largest corporate clients, in proportion to how much money they already have. If this happened at Barclays, the Financial Conduct Authority would shut them down by lunchtime. Executives would face criminal prosecution. Parliament would hold emergency hearings. But this isn't a bank. It's the music industry's collecting society infrastructure. And it's been happening for twenty years. --- ## Three upgrades, one direction The UK's mechanical royalty collection system has undergone three major infrastructure changes since 2005. Each was presented as a necessary modernisation. Each broke the metadata connections that independent catalogues depended on to get paid. ### 2005 — Digital Ingestion MCPS began accepting digital distribution data. The matching process shifted from human-readable, manually processed registrations to automated systems requiring cleaner, more structured inputs. The system that once understood that "J. Smith" and "John Smith" were the same person now treated them as two different entities. - Failure rate: ~2% → ~18% ### 2011 — The ICE Hub PRS for Music pooled royalty processing with STIM and GEMA into ICE, a centralised European clearinghouse. Millions of records were ported into a new relational database architecture built around strict DDEX-compliant field requirements. Any record that didn't conform silently dropped out of the matching pipeline. No notification was sent to the rights holder. - Failure rate: ~18% → ~40% ### 2021 — Oracle OCI / Cube ICE migrated to Oracle Cloud Infrastructure. The matching algorithm was rebuilt from the ground up with the strictest tolerances yet. For reissued catalogues — where a modern distributor assigns a brand new ISRC to a recording whose underlying composition was registered decades earlier — the new system simply could not find the match. - Failure rate: ~40% → ~77% ### Forensic Sample — UK Independent Label A random sample of 270 ISRCs pulled from Spotify — tracks where a major UK independent publisher holds mechanical rights — showed that **77% of post-2018 reissues have no MCPS registration whatsoever.** The mechanical royalties generated by those tracks are flowing into the system, failing the match, and falling into what the industry calls the Black Box. *Established UK independent label · Catalogue spanning 40+ years · 270-track sample* --- ## Following the numbers > "That progression — 2% to 18% to 77% — is not entropy. It's the direct, measurable consequence of three infrastructure decisions." The forensic data tells the story more clearly than any argument. Failure rates track in precise lock-step with the infrastructure timeline — not with market conditions, not with label size, not with catalogue quality. ### Matching Failure Rates by Era | Era | Context | Failure Rate | |-----|---------|-------------| | Pre-2000 | Original MCPS mainframe era | ~2% | | 2000–2009 | First digital ingestion wave | ~18% | | 2018–2024 Reissues | Oracle Cloud era — new ISRCs on old compositions | ~77% | *Source: TrackForge forensic audit · UK independent label sample · 270 ISRCs · Jan 2026* That last number is not a theoretical estimate. It comes from a real audit. Every percentage point of failure translates directly into revenue — generated, collected, unmatched, held, and then liquidated to the major label groups by market share. --- ## The Black Box ### An accident that benefits the same people every time The term "Black Box" sounds dramatic. In practice, it's mundane. It's simply the pool of collected royalties that the matching algorithm couldn't assign to a specific rights holder. Money comes in, the database looks for an owner, the metadata doesn't match, and the funds are parked in escrow. After a statutory holding period — typically around three years — unmatched royalties are liquidated. But they're not returned to distributors. They're not held indefinitely pending resolution. They're not published on a searchable ledger so rights holders can find them. **They are distributed by market share.** ### The numbers - **£500M** — Estimated UK streaming Black Box annually (Source: Ivors Academy) - **$2.5–15B** — Global misallocated royalties per year (Source: Industry estimates) - **$424M** — US historical backlog handed to MLC on day one, 2021 (Source: MLC / US Copyright Office) ### Who receives the liquidated revenue Sony Music Group, Universal Music Group, and Warner Music Group control approximately 60–70% of the global recorded music market. Their affiliated publishing arms dominate the composition side in similar proportions. Every pound of independent royalty revenue that falls through the matching algorithm is, after a brief statutory pause, paid out as a dividend to the three largest music corporations on the planet. Not because they own the rights. Not because they filed a claim. Simply because they are the biggest. --- ## The accident that nobody wants to fix It would be easy to frame this as a conspiracy. It isn't — or at least, it didn't start as one. The early database migrations were genuine attempts to modernise creaking infrastructure for a digital age. The engineers who built ICE weren't trying to steal from independent songwriters. They were trying to process an explosion of streaming data that the old MCPS mainframes couldn't handle. But once the infrastructure was in place, and once the pattern of failure became visible, the incentive structure ensured that nobody with the power to fix it had any reason to do so. The matching algorithms inside ICE and the Oracle Cube infrastructure are built by technical committees operating under the DDEX and CISAC frameworks. Who sits on these committees? Representatives from the three major label groups and the largest technology platforms. The specifications they write — the tolerances that define what constitutes a "match" — are built to the precise technical standards that their own enterprise-tier systems can provide. The majors maintain dedicated floors of data analysts with direct, enterprise-level API pipelines wired into the society databases. Their match rate approaches 99%. For everyone else — the independent label with a catalogue of 5,000 tracks registered across three decades, the songwriter who doesn't know what an ISWC is, the small publisher still working from a spreadsheet — the reality is entirely different. They interact with PRS and MCPS through laggy, consumer-facing portals. They deal with CSV uploads, manual dispute claims, and support tickets that take months to resolve. The technology upgrade wasn't evil. But it was built to the specifications of the 5% who could afford perfect data hygiene. The failure to account for the other 95% isn't a bug. Once the money started flowing upward, it became a feature. --- ## The perfect defence: "It's your responsibility" > "If their Oracle migration broke the link between your ISRC and your composition, that's your fault for not logging into the portal and fixing it." The collecting societies have a legal shield that places the burden of metadata accuracy entirely on the member. The data supply chain is deliberately fragmented, and each link points the finger at the next. 1. **Spotify / Apple** — "We pass the streaming reports and the money to the collecting societies." *Not our problem.* 2. **Distributors** — "We deliver the audio and the ISRC to the DSPs." *Not our problem.* 3. **PRS / MCPS** — "We process what we receive against our database. It is the member's responsibility to ensure their repertoire is accurately registered." *Not our problem.* ### The circle is complete The entities that control the society boards sit on the technical committees that define the matching specifications. Their companies receive the liquidated Black Box revenue when the statutory clock runs out. The burden of proof is placed on the copyright owner. And if you didn't know it was broken — because no notification was sent, because no exception report was published, because the Black Box is completely opaque — well, that's your fault too. --- ## The biggest transfer of wealth in music history The recording industry has seen its share of financial injustices. Artists signed to exploitative contracts. Publishers acquiring catalogues at fractions of their true value. Streaming platforms paying fractions of a penny per play. But none of those mechanisms operate at the scale of the Black Box. If the global music rights industry generates approximately $40–50 billion annually, and if between $2.5 billion and $15 billion of that is misallocated each year through matching failures, the Black Box represents a systematic wealth transfer operating at somewhere between 5% and 30% of the total market. Every year. For over a decade. The money doesn't vanish. **It is generated by real streams, from real listeners, of real songs written by real people.** It flows into the collection infrastructure, hits an algorithmic wall built to specifications that most creators cannot meet, sits in opaque escrow, and is redistributed to the entities that built the wall. This isn't an accident anymore. It may have started as one. But when the pattern became clear — when the failure rates climbed and the Black Box swelled and the liquidation checks grew larger — the absence of any systemic fix stopped being an oversight and became a choice. --- ## The global cascade Everything described above is drawn from UK data — MCPS registrations, PRS distributions, ICE matching logs. But ISRCs are global identifiers. If the relationship between a recording and its underlying work is broken at MCPS, it is almost certainly broken everywhere else too. The same unregistered remaster that fails to match in the UK also fails to match at the MLC in the United States. At GEMA in Germany. At SACEM in France. At JASRAC in Japan. The identifier travels, and the failure travels with it. ### Share of global streaming mechanical revenue | Territory | Society | Share | Status | |-----------|---------|-------|--------| | United States | MLC | 33% | Failure presumed | | Europe (EU) | GEMA / SACEM / SIAE | 27% | Failure presumed | | Asia-Pacific | JASRAC / APRA | 18% | Failure presumed | | Rest of World | Various | 16% | Failure presumed | | United Kingdom | MCPS | 6% | Failure measured | UK mechanical royalties represent roughly 5–7% of global streaming revenue. The United States alone accounts for 30–35%. For every pound sitting in MCPS suspense, there are likely three to four more in equivalent pools worldwide — on the same recordings, failing for the same reason. This is not a UK problem. It is a global one. The UK is simply the territory where the data makes it visible. --- ## What comes next > "The system wasn't built to be evil. It was built to be efficient — for the people who could afford to comply with it." We are not building a replacement for the collecting society system. The infrastructure that processes royalties works — if your metadata is clean enough to survive it. The code wasn't written to be malicious. Misaligned incentives and three decades of technical debt created a system that structurally favours whoever can afford enterprise-grade data operations. Others are trying to fight this — blockchain-based alternatives, decentralised rights registries, parallel infrastructure. We think that's a fight nobody wins. The existing system processes billions in royalties every quarter. It isn't going anywhere. The real problem is simpler than it looks: **the barrier to entry for proper compliance is too high.** A mid-tier independent faces the same metadata standards as Universal, but with a fraction of the budget and none of the tooling. TrackForge changes that equation. We don't change the system — we massively change the economics of complying with it. ### What TrackForge identifies - **Registration gaps** — Recordings generating revenue on streaming platforms but missing from collecting society databases. Money that's being earned but never routed to the rights holder. - **Ownership conflicts** — Competing claims, ambiguous publisher assignments, territorial gaps in registration. The quiet disputes that cause royalties to sit in suspense until they expire. - **Invisible leakage** — Reissues, remasters, and live recordings that were never separately registered. Revenue attributed to the wrong version — or to nobody at all. - **Acoustic fingerprinting** — When metadata fails entirely, match recordings by their audio. A recording is its audio — not its ISRC. --- This analysis is based on forensic audits conducted by TrackForge, the music rights intelligence platform developed by Adaptive Intelligence. The sample data referenced is drawn from a random audit of 270 ISRCs identified on Spotify across an established UK independent catalogue. Full methodology and supporting data available on request. --- Source: [https://trackforge.studio/black-box](https://trackforge.studio/black-box) --- ## sample-report.md # Download a Sample Report > Sample reports demonstrating TrackForge's catalogue health assessment and due diligence rating outputs, built from a real anonymised UK indie catalogue. *Published by [TrackForge](https://trackforge.studio)* --- Download a sample report built from a real UK indie catalogue. Anonymised data, current v1.1 methodology. ## Available Reports ### Catalogue Health Assessment **For Rights Holders** Results-page failure modes, revenue leakage analysis, registration coverage, and a concrete recovery roadmap with financial projections. - 9 pages - Commercial focus ### Due Diligence Rating **For Acquirers & Investors** Institutional-grade risk assessment, published v1.1 methodology, leakage-taxonomy scoring, governance framework, and valuation impact. - 22 pages - Institutional focus ## How to Get a Sample Report To download a sample report, visit the [Sample Report page](https://trackforge.studio/sample-report) and provide your name and work email. Reports are delivered as PDF downloads. ## What's Inside Both reports are generated from TrackForge's forensic analysis pipeline, using real catalogue data (anonymised for confidentiality). They demonstrate the depth of analysis TrackForge provides, including: - Frozen ingested catalogue population scoring - Results-page failure modes translated into AAA-D rating risk - Revenue leakage identification and materiality weighting - PRS/SearchWorks WACD agreement-binding coverage - ISWC coverage and registration-risk assessment - Recovery roadmap with financial projections ## Want to See Your Own Catalogue? Contact us at contact@trackforge.studio to discuss a catalogue assessment for your own catalogue. --- *TrackForge -- The Rights Rating Agency* --- Source: [https://trackforge.studio/sample-report](https://trackforge.studio/sample-report) --- ## terms.md # Terms of Service > Terms of service for TrackForge, the music catalogue intelligence and rights rating platform. *Published by [TrackForge](https://trackforge.studio)* **TrackForge Certification -- Self-Service** Effective Date: To be confirmed | Last Updated: February 2026 --- These Terms of Service ("Terms") govern your use of the TrackForge certification platform (the "Service") provided by Adaptive Intelligence, a company incorporated in England and Wales, trading as **TrackForge** ("we", "us", "our"). By creating an account or using the Service, you agree to be bound by these Terms. If you do not agree, you must not use the Service. ## 1. The Service ### What TrackForge Does TrackForge is a **rights rating agency** for music catalogues. It provides a standardised, independent, and cryptographically verifiable measure of catalogue quality -- analogous to how Moody's or S&P rate bonds. Every rating is anchored to the Bitcoin blockchain via OpenTimestamps and can be independently verified by any third party without contacting or trusting TrackForge. TrackForge operates at two levels: - **Track-level rating evidence** -- Track-level rows can be derived from the current rating event so buyers can inspect which recordings are affected by agreement-binding, ISWC, registration, and leakage risks (see Section 5). - **Catalogue-level grade** -- Catalogue ratings are issued on the AAA-D scale from frozen evidence snapshots and leakage-taxonomy state (see Section 5). For self-service users, TrackForge is a timestamping and evidence-processing service. The current certificate-facing methodology is versioned and cryptographically pinned; legacy medal labels may appear only in historical records and compatibility APIs. ### What TrackForge Certifies Each certification attests to **process fidelity** -- that a defined, documented process was followed and that the metadata was in the stated condition at the stated time. Full scope details: [Certification Scope](https://trackforge.studio/certification/for-lawyers/certification-scope) ### What TrackForge Does NOT Certify Certification does not constitute: - Legal proof of copyright ownership, authorship, or royalty entitlement - An assertion that writer splits are settled or binding - A guarantee against future contradictory claims - A warranty that upstream source databases are error-free - Legal advice or a legal opinion of any kind - A substitute for formal title searches or independent legal counsel ## 2. Account Registration - You must provide accurate and complete registration information. - You must be at least 18 years old with legal capacity to enter a binding agreement. - If registering for an entity, you represent authority to bind that entity. - You are responsible for maintaining account credential confidentiality. ## 3. Your Warranties By submitting metadata for certification, you warrant that: - **Right to submit** -- you have the necessary rights, licences, or permissions - **Accuracy** -- the metadata is, to the best of your knowledge, accurate and complete - **No misrepresentation** -- you are not submitting data you know to be false - **No infringement** -- submission does not infringe third-party rights - **Lawful purpose** -- you will use certification for lawful purposes only ## 4. Certification is Permanent and Non-Refundable > **Important:** Once a certification is anchored to the Bitcoin blockchain, it is **permanent** and cannot be removed, altered, or revoked. The blockchain is a public, decentralised, immutable ledger. This permanence is a fundamental feature, not a deficiency. - Errors may be addressed via re-certification (new version linked to original), but the original remains. - Fees are non-refundable once the blockchain anchor is confirmed. - A confirmation screen is presented before each certification is submitted. ## 5. Rating Scale and Methodology ### AAA-D Rating Scale Current certificate-facing ratings use the `TRACKFORGE_AAA_D` scale under the published methodology version in force at certification time. The current M58 public methodology label is **v1.1**. | Grade | Meaning | |-------|---------| | AAA | Minimal active leakage risk under the declared workflow and scope | | AA / A | Low active leakage risk, with remaining issues documented | | BBB / BB / B | Mixed or material leakage risk requiring remediation or diligence review | | CCC / CC / C | Severe leakage risk across material parts of the population | | D | Critical leakage risk or very low deterministic coverage | ### Methodology Inputs Current M58 ratings are calculated from frozen evidence snapshots, not from mutable cleaned catalogue rows. Inputs include: - Leakage-taxonomy findings and revenue-pathway materiality - PRS/SearchWorks WACD agreement binding where PRS/MCPS scope is in play - ISWC coverage and conflicts where work identity affects registration resolution - Rating input hash, leakage-vector hash, Merkle root, methodology version/hash, workflow version, taxonomy version, and proof state Full methodology: [Rating Scale & Methodology](https://trackforge.studio/certification/methodology/golden-record-selection) ## 6. Rating Independence TrackForge may provide both enrichment services (modifying catalogue data for a fee) and rating services (independently assessing catalogue health) to the same catalogue. To prevent conflicts of interest, enrichment and rating are structurally separated at three levels: - **Application architecture** -- The rating engine is a pure function with zero imports from enrichment modules. It receives data and produces a deterministic verdict. There is no code path through which the rating can modify data. - **Database access control** -- The rating engine connects via a dedicated read-only PostgreSQL role. INSERT, UPDATE, and DELETE are denied at the database level. - **Immutable criteria** -- Rating criteria are global constants applied identically to all catalogues. There is no per-client configuration of thresholds or modifiers. Every rating output includes a mandatory conflict-of-interest disclosure. The methodology version is recorded on every rating, enabling independent re-verification. Full details: [Rating Independence](https://trackforge.studio/certification/for-lawyers/rating-independence) ## 7. Conflicting Certifications Two different users may hold certifications for the same ISRC with different metadata. - **Both stand.** Each is a valid record at its certification date. - **Conflicts are flagged.** Both parties are notified. - **TrackForge does not adjudicate.** Resolution is a matter for the parties or the courts. Full policy: [Conflicting Certifications Policy](https://trackforge.studio/certification/for-lawyers/conflicting-certifications) ## 8. Acceptable Use You agree not to: - Submit metadata in bad faith or for recordings you do not control - Submit data you know to be false or fabricated - Use certification as proof of copyright ownership or royalty entitlement - Misrepresent the rating, methodology version, proof state, or verification depth - Interfere with, disrupt, or circumvent the Service or blockchain anchoring - Use automated tools to abuse the Service beyond fair use - Reverse-engineer the Service - Use the Service for any unlawful purpose ## 9. Liability Limitations - **Cap:** Total liability shall not exceed fees paid in the preceding 12 months, or GBP 100, whichever is greater. - **Excluded:** Indirect, consequential, or special losses; loss of profits, revenue, business, or anticipated savings; loss of goodwill or reputation. - **Upstream errors:** We are not liable for errors in data from upstream sources (Spotify, MusicBrainz, PRS, MLC, etc.). - **Reliance:** We are not liable where any person relies on a certification without independent legal advice. - **Blockchain immutability:** We are not liable for inability to alter or revoke an anchored certification. Full details: [Liability & Risk Framework](https://trackforge.studio/certification/for-lawyers/liability-risk) ## 10. No Legal Advice TrackForge does not provide legal advice. The Service is a rights rating agency and certification platform, not a law firm. Nothing in the Service or these Terms constitutes legal advice. You should not rely on a certification or portfolio grade as a substitute for independent legal advice, formal title searches, or legal due diligence. ## 11. Privacy Your use of the Service is subject to our [Privacy Policy](https://trackforge.studio/privacy). The Bitcoin blockchain anchor contains only the Merkle Root hash -- a 64-character hexadecimal cryptographic digest. No personal data is written to the blockchain. The public verification page operates without cookies, tracking, or analytics. Certification privacy details: [Data Handling & GDPR](https://trackforge.studio/certification/for-lawyers/data-handling-gdpr) ## 12. Intellectual Property - **Your data:** You retain all rights to metadata you submit. - **Our licence:** You grant us a non-exclusive, royalty-free licence to process your metadata solely for the Service. - **Our IP:** We retain all rights to the TrackForge platform, algorithms, and methodology. - **Certifications:** You may use, reproduce, and rely on your certifications for any lawful purpose. The embedded disclaimer may not be removed. ## 13. Termination - You may close your account at any time. Existing certifications remain valid. - We may suspend or terminate for acceptable use violations or fraud. - Post-termination: certifications persist and remain verifiable via the blockchain. You retain download access for 90 days. ## 14. Governing Law These Terms are governed by the law of England and Wales. The courts of England and Wales have exclusive jurisdiction. UK consumer residents retain statutory rights to bring proceedings in their country of residence. ## 15. General - These Terms, with the Privacy Policy, constitute the entire agreement. - Invalid provisions do not affect remaining Terms. - We may modify these Terms with 30 days' notice. Changes do not affect prior certifications. - No third-party rights under the Contracts (Rights of Third Parties) Act 1999. ## Contact Adaptive Intelligence (trading as TrackForge) Email: legal@trackforge.studio --- *This document is a draft prepared for legal review. It does not constitute legal advice. See the full [legal framework documentation](https://trackforge.studio/certification/for-lawyers) for detailed certification scope, methodology, and risk analysis.* *Copyright Adaptive Intelligence. All rights reserved.* --- Source: [https://trackforge.studio/terms](https://trackforge.studio/terms) --- ## privacy.md # Privacy Policy > How TrackForge handles your data, cookies, and music catalogue information. *Published by [TrackForge](https://trackforge.studio)* Effective Date: To be confirmed | Last Updated: February 2026 --- Adaptive Intelligence, trading as **TrackForge**, is committed to protecting your privacy. This Privacy Policy explains how we collect, use, store, and share your personal data when you use the TrackForge platform (the "Service"). We are the data controller. Our registered office is in England and Wales. For questions about this policy, contact us at privacy@trackforge.studio. ## 1. Data We Collect ### Account Data - Name and email address (provided at registration) - Organisation name (if applicable) - Authentication credentials (managed by our authentication provider, Zitadel) ### Catalogue Metadata - Track metadata: ISRCs, titles, artists, durations, album information - Rights metadata: writer names, IPI numbers, publisher names, splits - Registration data: PRO registrations, MLC status, territory coverage ### Usage Data - Service usage patterns (pages visited, features used) - Device and browser information - IP address (for security and rate limiting) ## 2. How We Use Your Data | Purpose | Legal Basis | |---------|------------| | Provide and operate the Service | Contract performance | | Enrich metadata via external sources | Contract performance | | Generate and anchor certifications | Contract performance | | Process writer/IPI data for certification | Legitimate interest | | Security, fraud prevention, rate limiting | Legitimate interest | | Service communications | Legitimate interest | ## 3. Certification & Blockchain Privacy > **Privacy by Design:** No personal data is ever written to the Bitcoin blockchain. The blockchain anchor contains only a Merkle Root hash -- a 64-character hexadecimal cryptographic digest from which no personal data can be derived. ### Personal Data in Certifications | Data | Classification | Basis | |------|---------------|-------| | Writer names | Personal data | Legitimate interest | | IPI numbers | Professional identifier | Legitimate interest | | Writer splits | Commercial data | Contractual | | SHA-256 hash | Not personal data | N/A | ### Public Verification Page The verification page at [trackforge.studio/verify](https://trackforge.studio/verify) displays only: - ISRC, certification date, hash, Merkle Root - Blockchain transaction ID, certification tier, methodology version Never displayed: writer names, IPI numbers, splits, track titles, or any commercially sensitive data. The page operates without cookies, tracking, or analytics. ## 4. Data Sharing We share data with: - **Enrichment sources** -- ISRCs are sent to external APIs (Spotify, MusicBrainz, Discogs, Last.fm, PRS, MLC) to retrieve and verify metadata. Only ISRCs and track identifiers are shared, not your account data. - **Authentication provider** -- Zitadel processes your authentication data under their privacy policy. - **Bitcoin blockchain** -- Only the Merkle Root hash is published. No personal data. - **OpenTimestamps calendars** -- Hash submitted for timestamping. No personal data. We do not sell your personal data. We do not share it with advertisers or marketing platforms. ## 5. Data Retention | Data Type | Retention | |-----------|-----------| | Certification records | Indefinite (the product) | | Blockchain anchors | Permanent (immutable) | | Audit trail | 6 years (regulatory) | | Account data | Duration of account + 90 days | | Working enrichment data | Per retention schedule | ## 6. Your Rights Under UK GDPR and the Data Protection Act 2018, you have the right to: - **Access** -- request a copy of data we hold about you - **Rectification** -- correct inaccurate data - **Erasure** -- request deletion of your data, subject to legal obligations and the blockchain exception below - **Restriction** -- limit how we process your data - **Portability** -- receive your data in a structured format - **Objection** -- object to processing based on legitimate interest > **Blockchain Exception:** The SHA-256 hash on the Bitcoin blockchain cannot be deleted or modified. However, this hash is a cryptographic digest and is not personal data. Underlying personal data (writer names, IPIs) in our databases can be deleted on request -- the hash will remain but will no longer be linkable to personal data. To exercise any right, contact privacy@trackforge.studio. We will respond within 30 days. ## 7. Data Security - Encryption in transit (TLS) and at rest - Role-based access controls - Operator audit logging on all data access - Regular security reviews ## 8. International Transfers Your data is primarily stored in the EU/EEA (Neon PostgreSQL). Some enrichment queries are sent to international APIs (e.g., Spotify, MusicBrainz). These transfers rely on standard contractual clauses or adequacy decisions as appropriate. ## 9. Cookies The TrackForge application uses essential cookies for authentication and session management only. We do not use advertising, analytics, or tracking cookies. The public verification page at /verify uses no cookies at all. ## 10. Changes to This Policy We may update this policy from time to time. Material changes will be notified via email or prominent notice on the Service at least 30 days before taking effect. ## 11. Contact & Complaints Adaptive Intelligence (trading as TrackForge) Email: privacy@trackforge.studio You have the right to lodge a complaint with the Information Commissioner's Office (ICO) at [ico.org.uk](https://ico.org.uk) if you believe your data protection rights have been violated. --- *This document is a draft prepared for legal review. See the full [data handling documentation](https://trackforge.studio/certification/for-lawyers/data-handling-gdpr) for certification-specific GDPR details.* *Copyright Adaptive Intelligence. All rights reserved.* --- Source: [https://trackforge.studio/privacy](https://trackforge.studio/privacy) --- ## cwr-tool.md # Free CWR Tools — Generate, Validate & Inspect CWR 2.1 Files > Free online CWR tools — generate, validate, inspect CWR 2.1 files and parse ACK responses before submitting to collecting societies. The only free public CWR generator. *Published by [TrackForge](https://trackforge.studio)* --- Validate Common Works Registration files against the CISAC 2.1 and 2.2 specifications before submitting to collecting societies. Instant structural analysis, field-level validation, cross-record consistency checks, and human-readable error reports — free, no account required. Built by the team behind TrackForge's catalogue verification engine. The same validation logic we use for our own ICE, PRS, and MCPS submissions. CWR (Common Works Registration) is the CISAC standard for registering musical works with collecting societies worldwide. Getting it right the first time saves weeks of back-and-forth with society technical teams. **Supported versions:** CWR 2.1 and CWR 2.2 (auto-detected from file header) --- ## What Is CWR? Common Works Registration (CWR) is the international standard developed by [CISAC](https://www.cisac.org) for registering musical works with performing rights organisations (PROs) and mechanical rights organisations (MROs) around the world. It is the primary mechanism through which publishers notify societies like PRS, ASCAP, BMI, GEMA, SACEM, and JASRAC about new works, ownership shares, and writer information. A CWR file is a fixed-width ASCII text file with strict formatting requirements: 101-character headers, 197-character work records, precisely formatted share percentages, and mandatory CRLF line endings. A single misplaced character or incorrect field length will cause the entire file to be rejected by the receiving society. **Why this tool exists.** Most publishers discover CWR formatting errors only after submission — when a society's technical team sends back a rejection days or weeks later. This validator catches those errors instantly, before submission, saving publishers significant time and avoiding delayed registrations that can affect royalty collection. The current specification is CWR 2.2 (incremental update over 2.1), though most societies still accept 2.1. This validator supports both versions and auto-detects the spec from the file header. --- ## What We Check ### File Structure Validates the HDR > GRH > Transactions > GRT > TRL record sequence, CRLF line endings, and ASCII encoding. ### Record Validation Checks every record type (NWR, SPU, SPT, SWR, SWT, PWR) for correct field lengths, data types, and required values. ### Cross-Record Consistency Verifies that publisher and writer shares total 100%, sequence numbers are contiguous, and writer references are valid. ### Filename Convention Validates filenames against CISAC section 3.1 (CWyynnnnsss_rrr.Vxx) — a common rejection reason at societies. **Human-readable errors.** CWR is a notoriously opaque fixed-width format. Our validator translates raw field offsets into plain-language explanations: what went wrong, which line, and how to fix it. Where possible, we link to the relevant CISAC specification section. --- ## How to Use 1. Upload a .V21 or .V22 file (up to 10 MB, approximately 10,000 works) 2. Select the specification version (CWR 2.1 or 2.2, auto-detected from file extension) 3. Click "Validate File" 4. Review the detailed validation report with errors, warnings, and statistics Your file is processed in memory and never stored. Only the structured validation report is retained for 30 days to support shareable result links. --- ## Features - **Instant validation** — results in seconds, not days - **PDF reports** — downloadable, branded validation reports - **Email delivery** — reports sent directly to your inbox via Resend - **Shareable links** — result URLs valid for 30 days - **No account required** — upload and validate immediately - **Free to use** — up to 20 validations per hour --- ## Documentation - [What Is CWR?](/certification/cwr/what-is-cwr) — An overview of Common Works Registration for publishers and administrators - [Record Types](/certification/cwr/record-types) — HDR, NWR, SPU, SWR, PWR — every record type explained with field maps - [Common Errors](/certification/cwr/common-errors) — The most frequent CWR rejection reasons and how to fix them --- ## Tools ### CWR Generator (Live) Generate spec-compliant CWR 2.1 NWR and REV files from structured metadata. The only free public CWR generator. Upload a spreadsheet or use the workbench form to produce registration-ready output for any society. ### CWR Validator (Live) Validate CWR 2.1 and 2.2 files against the CISAC specification. Instant structural analysis, field-level validation, cross-record consistency checks, and human-readable error reports. ### ACK Parser (Live) Parse society acknowledgement files to see which works were accepted, rejected, or need correction. ### CWR Inspector (Live) Decode any CWR file into a human-readable view — record-by-record breakdown with field explanations. ### CWR Help & Error Reference Complete error code reference with plain-English explanations, glossary of CWR terms (NWR, REV, IPI, ISWC, society codes), and troubleshooting guides. Available at [/cwr-tool/help](https://trackforge.studio/cwr-tool/help). ### REST API (Planned) Integrate CWR validation into your pipeline. Validate files programmatically with detailed JSON responses, webhook callbacks, and batch support. --- ## Privacy and Disclaimer **Privacy.** Your CWR file is processed in memory and never stored. Only the structured validation report (errors, warnings, statistics) is retained for 30 days to support shareable result links, then automatically deleted. No publisher names, writer names, or IPI numbers from your file are retained beyond the validation session. **Disclaimer.** This tool checks CWR file structure and field validity against the CISAC specification. It does not guarantee acceptance by any specific society. Each collecting society may impose additional requirements beyond the base specification. --- Need higher rate limits, bulk validation, or a custom integration? Contact us at [contact@trackforge.studio](mailto:contact@trackforge.studio). --- Source: [https://trackforge.studio/cwr-tool](https://trackforge.studio/cwr-tool) --- ## isrc-lookup.md # ISRC Lookup Tool — Free Cross-Reference for Spotify, MusicBrainz & The MLC > Free ISRC lookup tool. Cross-reference any 12-character ISRC across Spotify, MusicBrainz, and The MLC in seconds to surface metadata conflicts, missing registrations, and trapped mechanical royalties. No account required. *Published by [TrackForge](https://trackforge.studio) — The Rights Rating Agency* **Tool URL:** https://trackforge.studio/isrc-lookup **Last updated:** 2026-04-11 --- ## What Is an ISRC Lookup? An ISRC lookup is a cross-reference of a 12-character **International Standard Recording Code** against one or more authoritative music metadata sources. The TrackForge ISRC Lookup tool queries three sources in parallel: 1. **Spotify Web API** — commercial availability, canonical artist/title/album, label, markets, release date, and duration. 2. **MusicBrainz** — the open editorial music database, used for independent verification of title/artist/album metadata. 3. **The MLC (Mechanical Licensing Collective) Public API** — US mechanical rights, ISWC resolution, writer splits, publisher splits, and MLC song codes. If any of the three sources disagrees about a field (artist name, release date, duration, etc.), the tool flags it as a conflict. If The MLC returns no match, the tool flags a registration gap — one of the most common causes of trapped mechanical royalties. --- ## Who Uses This Tool - **Record labels** verifying that their catalogue is correctly registered across platforms before a royalty cycle. - **Music publishers** checking that every ISRC is linked to a registered ISWC at The MLC. - **Catalogue buyers** running due diligence on a target catalogue before acquisition. - **Distributors** debugging why a specific track is not paying out as expected. - **Independent artists** confirming that their releases exist correctly in Spotify and MusicBrainz. --- ## How to Use 1. Open [trackforge.studio/isrc-lookup](https://trackforge.studio/isrc-lookup). 2. Choose **Single** mode for one ISRC or **Batch** mode for many. 3. Paste your ISRC(s). ISRCs are 12 characters: 2-letter country code, 3-character registrant code, 2-digit year, 5-digit designation. Example: `GBAYE0601498`. 4. Click **SCAN**. The tool queries Spotify, MusicBrainz, and The MLC in parallel. 5. Review the results: metadata from each source, any flagged conflicts, and writer/publisher splits where available. 6. Export results to CSV (for spreadsheet analysis) or PDF (branded report) if needed. No account is required. ISRCs are processed in real-time and never stored. --- ## What the Tool Returns For each ISRC you submit, the tool returns: ### Spotify block - Canonical track title, artist, and album - Label - Release date - Duration (seconds) - Number of available markets ### MusicBrainz block - Track title, artist, and release - Release date - Independent cross-reference against Spotify ### The MLC block - MLC song code - ISWC (if linked) - Canonical work title and primary artist - All labels linked to the recording - Writer names and writer share percentages - Publisher names and publisher share percentages (summing to 100%) ### Conflicts Any field where sources disagree (e.g., Spotify says artist "Tyler, The Creator" but MusicBrainz says "Tyler The Creator") is flagged with source values and a plain-language note. ### Health status Each ISRC is classified as: - **Clean** — metadata consistent across all sources, MLC registration present. - **Warning** — one or more metadata conflicts detected. - **Critical** — missing from The MLC or missing from one or more sources entirely. --- ## Features - Single and batch ISRC lookup (up to several hundred per batch) - Parallel queries across Spotify, MusicBrainz, The MLC - Automatic conflict detection between sources - MLC registration gap flagging - Writer and publisher share breakdown - ISWC resolution from ISRC - CSV export for spreadsheet analysis - Branded PDF report export - No account required - No data stored — real-time lookups only - Free to use --- ## Frequently Asked Questions ### What is an ISRC code? An ISRC (International Standard Recording Code) is a 12-character unique identifier assigned to a specific sound recording. Every time you stream a song on Spotify, Apple Music, or YouTube, the ISRC is the code that identifies which exact master recording was played. It is the foundation of how recorded-music royalties are tracked and paid. ### How do I look up an ISRC code for free? Paste any 12-character ISRC into the TrackForge ISRC Lookup tool at [trackforge.studio/isrc-lookup](https://trackforge.studio/isrc-lookup). The tool queries Spotify, MusicBrainz, and The MLC in parallel and returns metadata, writer/publisher splits, and any conflicts between sources. No account is required and the tool is free to use. ### What is the difference between ISRC and ISWC? An ISRC identifies a specific **sound recording** (the master). An ISWC identifies the underlying **musical work** (the composition). One song written by Lennon & McCartney can have dozens of ISRCs — one for every cover recording — but only one ISWC. ISRCs route performance and master royalties; ISWCs route songwriter and publishing royalties. ### Why would an ISRC not be registered with The MLC? The MLC only tracks US mechanical rights for musical works. If a recording is unreleased in the US, if the songwriter has not filed a work registration (CWR), or if the publisher has not linked the sound recording to the work, the ISRC will return no MLC match. This is one of the most common causes of trapped mechanical royalties. ### Can I look up many ISRCs at once? Yes. Switch the tool into Batch mode and paste up to several hundred ISRCs, one per line or comma-separated. Results can be exported to CSV for spreadsheet analysis or to a branded PDF report. For full-catalogue cross-referencing across 7+ sources (including ASCAP, PRS, SoundExchange, and more), [request a TrackForge Assay](mailto:contact@trackforge.studio?subject=TrackForge%20Assay%20Request). ### Is my ISRC data stored when I use this tool? No. ISRCs submitted to the TrackForge ISRC Lookup tool are processed in real-time and never stored. No personal data is collected or retained. Each lookup queries Spotify, MusicBrainz, and The MLC public APIs live. ### What does "MLC song code" mean? The MLC song code is the unique identifier The MLC assigns to a musical work in its database. It is the key into MLC's writer and publisher share data, and it is how US mechanical royalties are routed to rights-holders. A missing MLC song code typically means the work is not yet registered with The MLC. ### How accurate are the conflict flags? The tool flags differences between sources; it does not judge which source is correct. A conflict simply means "the sources disagree — investigate." In practice, Spotify tends to hold label-provided commercial metadata, MusicBrainz holds community-maintained editorial metadata, and The MLC holds publisher-filed work registrations. Each has its own provenance, so genuine conflicts are common and meaningful. --- ## From Lookup to Assay The free ISRC Lookup tool is a sample of what TrackForge's full **Assay** reveals. The Assay cross-references your entire catalogue across 7+ sources — including MLC ownership chains, SoundExchange, ASCAP, PRS, and Spotify — to quantify trapped royalties, flag duplicate registrations, and produce a cryptographically verifiable evidence bundle. To request an Assay, email [contact@trackforge.studio](mailto:contact@trackforge.studio?subject=TrackForge%20Assay%20Request). --- ## Related Reading - [ISRC Registration Gaps](https://trackforge.studio/research/isrc-registration-gaps) — The 45-point gap between Spotify coverage and MLC work registration, where $569.9M in mechanical royalties disappear. - [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy) — 4.25M works with unclaimed US mechanical royalties at the MLC, cross-referenced against 12 data sources. - [Where the Money Goes: Royalty Leakage Map](https://trackforge.studio/research/royalty-leakage-map) — 12 lifecycle stages where music royalties disappear, 160+ failure modes across 15 data sources. - [CWR Workbench](https://trackforge.studio/cwr-tool) — Validate, inspect, and generate Common Works Registration files. The only free public CWR generator. - [Why TrackForge](https://trackforge.studio/why) — The case for independent catalogue verification. --- ## Privacy and Disclaimer **Privacy.** Your ISRCs are processed in real-time and never stored. No personal data is collected or retained. **Disclaimer.** This tool queries public APIs (Spotify, MusicBrainz, The MLC) and may return incomplete data. Always verify results independently before making business decisions. By using this tool you agree to our [Terms of Service](https://trackforge.studio/terms) and [Privacy Policy](https://trackforge.studio/privacy). --- Source: [https://trackforge.studio/isrc-lookup](https://trackforge.studio/isrc-lookup) --- ## research/unclaimed-economy.md # The Unclaimed Economy > 4.25 million musical works have unclaimed US mechanical royalties at the MLC. 67.5% are registered at ASCAP. 73% stream on Spotify. A structural registration gap that isn't closing. *Published by [TrackForge](https://trackforge.studio) -- 7 March 2026* *3.2 billion records analysed across 12 cross-referenced data sources* --- The Music Modernization Act of 2018 established the Mechanical Licensing Collective to resolve the "black box" of unmatched mechanical royalties in the United States. Seven years on, our analysis of the MLC's public data -- cross-referenced against 3.2 billion records from 12 independent sources -- reveals that **4.25 million musical works** still have partially or fully unclaimed royalties. The central finding is structural, not operational. **67.5% of unclaimed works are registered for performance royalties at ASCAP** -- their writers registered with a PRO, but nobody registered the mechanical share at the MLC. 73% of the associated recordings are actively streaming on Spotify. This is not dormant catalogue. These are works generating revenue today, where a portion of the mechanical royalty has no registered claimant. The MMA created a system to *collect* mechanical royalties. It did not solve the upstream problem: *who registers them*. The result is a structural gap between performance and mechanical registration that affects all publisher types equally, compounds when creators die, and is invisible to any single dataset in isolation. --- ## Finding 01: The Scale of the Unclaimed Economy Of 53.4 million works registered with the MLC, 4.25 million have royalties that no one is collecting. The system is overwhelmingly under-claimed, not over-claimed. The distribution of unclaimed shares is not uniform. Nearly half of all unclaimed works (46.8%) fall in the 50-74% unclaimed band, with the single largest cluster at **exactly 50%** -- comprising 1,546,295 works. This is not random; it is a structural signature explored in Finding 3. At the extremes: **660,600 works are 100% orphaned** -- no publisher, no writer, no rights holder has registered any claim. Yet 52.2% of these orphans possess an ISWC, meaning they are identifiable compositions that simply have no claimant in the US mechanical system. Every one of these works that is actively streaming (Finding 4) is generating mechanical royalties that will be redistributed to registered publishers -- predominantly the majors -- if no claim is filed within the MMA's statutory window. ### Distribution of Unclaimed Royalty Shares (4.25M works) | Unclaimed Band | Works | |----------------|-----------| | 1-24% | 359,327 | | 25-49% | 680,592 | | 50-74% | 1,990,048 | | 75-99% | 559,994 | | 100% | 660,600 | ### The mirror image: over-claiming If 4.25M works are under-claimed, how many are over-claimed? Only **41,444 works** (0.1% of 43M with mechanical rights entries) have publisher shares summing above 100%, and the maximum observed is 134%. The system is overwhelmingly asymmetric: under-registration dwarfs over-registration by a factor of 100:1. This asymmetry itself is a finding -- it suggests the problem is not competing claims but *absent* claims. ### Summary by Unclaimed Category | Category | Works | Detail | |-----------------------------|-----------|---------------------------------------------------------------------| | True Orphans (100%) | 660,600 | Zero rights holders. 52.2% have an ISWC -- identifiable but unclaimed. | | Majority Unclaimed (50-99%) | 2,550,042 | One or more parties registered, but the majority of shares remain open. | | Minority Unclaimed (1-49%) | 1,039,919 | Most rights registered, but a fractional share is missing. | | Over-claimed (>100%) | 41,444 | 0.1% of works. Max 134%. The system barely over-claims at all. | --- ## Finding 02: The Registration Gap: Performance vs Mechanical 2.85 million works with unclaimed mechanical royalties are registered for performance royalties at ASCAP. The writers showed up. The mechanical registration didn't follow. This is the central finding of this analysis. By cross-referencing the MLC's unclaimed works against ASCAP's 13.1 million registered titles, we find that **67.5% of unclaimed MLC works have a title match in ASCAP's performance rights database**. These 2,854,874 works are not unregistered because the creators are unknown or disengaged. The writers registered with ASCAP for their performance royalties. But the corresponding mechanical share at the MLC was never registered -- typically the publisher's responsibility, or in the case of self-published writers, a step that was simply never taken. ### Unclaimed MLC Works: ASCAP Registration Status | Status | Works | Percentage | |------------------------|-----------|------------| | Registered at ASCAP | 2,854,874 | 67.6% | | Not found in ASCAP | 1,372,402 | 32.4% | *Note: Denominator is 4,227,276 (works with non-empty titles suitable for matching), not the full 4,250,626 unclaimed total. The 23,350-work difference (0.5%) comprises works with blank or null titles that cannot participate in title-based cross-referencing.* > The Music Modernization Act solved the collection problem. It did not solve the registration problem. Two-thirds of unclaimed works have writers who registered elsewhere -- the mechanical claim simply never followed. This finding has a direct implication for the MLC's statutory distribution mechanism. Under the MMA, unclaimed royalties are held for a period and then distributed on a **market-share basis** to existing registered publishers. The structural beneficiaries of this redistribution are necessarily the largest registered publishers -- Universal Music Publishing, Sony Music Publishing, Warner Chappell -- because market-share distribution is proportional to existing registrations. This is not an accusation of wrongdoing; it is a mathematical consequence of the mechanism. The works generating these royalties have identifiable creators (they are registered at ASCAP), but because no mechanical claim exists, the royalties flow to the largest incumbents by default. The MMA created a system that assumes registration will happen and provides no mechanism to ensure it does. **Methodological caveat:** The ASCAP cross-reference uses normalised title matching, not writer-level verification. Title collisions (different works with identical titles) will produce some false positives. However, at 67.5% match rate across 4.25M works, even significant false-positive noise would not change the directional finding. ASCAP is one of three major US PROs; BMI and SESAC data would likely increase the match rate further. --- ## Finding 03: The 50% Problem The unclaimed economy is not concentrated in any one publisher segment. It is a structural gap in how the writer/publisher split is registered -- and it affects everyone equally. A natural hypothesis is that certain publisher types -- DIY platforms, indie labels, or foreign CMOs -- would show higher unclaimed rates than the majors. **The data does not support this.** We categorised the top 50 publishers by volume into four segments: Major (Warner Chappell, Sony/ATV, Universal, BMG), Indie (Kobalt, Concord, Downtown), DIY (TuneCore, CD Baby, Songtrust, Sentric, BeatStars), and CMO/Administrator (SIAE, GEMA, MCPS, SUISA, NCB). The average unclaimed percentage ranges from 45.7% to 55.6%, with a **median of 50.0% everywhere**. The structural evidence: of the 1.55 million works at exactly 50% unclaimed, the vast majority have **one publisher registered at a 50% share**. The other half -- typically the writer's share or a co-publisher -- is absent from the MLC. Combined with Finding 2 (the ASCAP cross-reference), this builds a clear causal chain: **the writer registers with their PRO for performance royalties, the publisher registers their 50% mechanical share at the MLC, but nobody registers the writer's 50% mechanical share.** ### The 0% share anomaly **1,010,772 unclaimed works** have a publisher registered at 0% economic share -- an administrator-only registration claiming no money. (This figure covers all unclaimed works; a narrower scope of majority-unclaimed works yields ~505K, roughly half.) The top entities: BeatStars Publishing (85,598 works), IPRS India (80,584), SGAE Spain (24,758). These are typically foreign CMOs or beat marketplace platforms registering administrative presence in the US system without taking an economic position. The actual ownership remains unregistered. ### Average Unclaimed % by Publisher Segment | Segment | Works | Avg Unclaimed | Median | P25 | P75 | |----------------------|---------|---------------|--------|-------|-------| | DIY: Soundreef | 24,295 | 55.6% | 50.0% | 50.0% | 75.0% | | Indie: Downtown | 63,905 | 53.7% | 50.0% | 50.0% | 66.7% | | DIY: BeatStars | 97,009 | 53.4% | 50.0% | 50.0% | 50.0% | | DIY: TuneCore | 151,006 | 50.4% | 50.0% | 50.0% | 50.0% | | DIY: Songtrust | 122,212 | 50.3% | 50.0% | 50.0% | 50.0% | | Major: BMG | 127,359 | 50.2% | 50.0% | 42.5% | 60.0% | | Major: Sony/ATV | 142,717 | 50.0% | 50.0% | 37.5% | 66.7% | | DIY: Sentric | 62,067 | 49.8% | 50.0% | 50.0% | 50.0% | | Indie: Concord | 38,238 | 49.2% | 50.0% | 33.3% | 66.7% | | CMO / Admin | 462,669 | 48.3% | 50.0% | 33.3% | 62.5% | | Major: Warner Chappell | 211,087 | 48.2% | 50.0% | 33.3% | 65.0% | | Major: Universal | 225,861 | 47.8% | 50.0% | 33.3% | 61.7% | | DIY: CD Baby | 169,915 | 47.0% | 50.0% | 33.0% | 65.0% | | Indie: Kobalt | 95,690 | 45.7% | 50.0% | 25.0% | 60.0% | --- ## Finding 04: These Works Are Not Dormant 97% of unclaimed works have a recording. 73.4% of those recordings are on Spotify. This is active catalogue generating revenue with no mechanical claimant. A reasonable assumption might be that unclaimed works are obscure, inactive, or historical. The data contradicts this. ### Unclaimed Works: From Composition to Active Stream | Stage | Value | |----------------|-----------| | Unclaimed works | 4,250,626 | | With ISRC | 97.2% | | Unique ISRCs | 7,153,204 | | On Spotify | 73.4% | **97.2%** of unclaimed works have at least one associated ISRC -- meaning a recording exists and has been distributed. Using the full MLC ISRC-Work mapping (7.15M ISRCs from 3.35M unclaimed works), we matched these against 256 million Spotify tracks and found **5,249,731 ISRCs** (73.4%) present on the platform. A 100,000-ISRC stratified sample returned a higher match rate of 83%, likely because sampling over-represents works with more ISRC variants; the full-join figure is the more conservative and reliable measure. These works are actively generating streams. Under the MMA's statutory framework, the MLC collects mechanical royalties on these streams. For the unclaimed portion of each work, those royalties accumulate in escrow before eventual market-share distribution to registered publishers -- predominantly the majors. The creators who registered with ASCAP (Finding 2) are receiving their performance royalties via their PRO. The mechanical share sits uncollected. ### What we cannot measure We have ISRCs on Spotify but not per-track streaming counts. Spotify's public popularity score (0-100) is ordinal, not a play count, and the Spotify Charts dataset covers only the top 200 tracks per market. We therefore make no revenue estimate. The finding is binary: these works are streaming or they are not. 73.4% are. What *is* measurable is the destination of the royalties: under the MMA's statutory framework, unclaimed mechanical royalties held past the prescribed period are distributed on a market-share basis. For the 5.25 million ISRCs actively streaming on Spotify with no mechanical claimant, the default beneficiary is not the creator. --- > Findings 1-4 establish the thesis: unclaimed mechanical royalties are structural, universal, and active. Findings 5-6 examine two compounding factors -- missing identifiers and creator death -- that make the gap harder to close. --- ## Finding 05: The ISWC Desert 42.5% of works in the US mechanical licensing system lack the global identifier that enables cross-border royalty collection. The International Standard Musical Work Code (ISWC) is the only globally accepted identifier for musical compositions. It connects a work registered at the MLC to the same work at PRS (UK), GEMA (Germany), or SACEM (France). Without it, cross-border matching relies on title and writer name fuzzy matching -- a process that fails routinely. ### ISWC Coverage Across MLC Works | Category | Works | ISWC Coverage | |--------------|-------|---------------| | All MLC Works | 53.4M | -- | | With ISWC | 30.7M | 57.5% | | Without ISWC | 22.7M | 42.5% | The gap is correlated with unclaimed status. Among unclaimed works, only **45.6%** have an ISWC, compared to **58.5%** for claimed works -- a 12.9 percentage-point gap. The causal direction is ambiguous: works without ISWCs may be harder to match, or works that nobody claims may never get assigned one. Either way, missing identifiers and missing claims compound each other. ### ISWC Coverage: Claimed vs Unclaimed Works | Status | With ISWC | Without ISWC | |-----------------|-----------|--------------| | Claimed Works | 58.5% | 41.5% | | Unclaimed Works | 45.6% | 54.4% | For context, the open-source MusicBrainz database contains only **343,303 unique ISWCs** -- approximately 1.1% of the MLC's ISWC space. The gap between proprietary and open identifier coverage is vast, and represents a significant barrier to independent verification of rights data. --- ## Finding 06: The Succession Gap When creators die, their mechanical royalties often die with them. 84% of deceased music creators lack the identifier needed to collect. Cross-referencing the MLC with Wikidata's structured data on 506,564 deceased individuals with music industry roles reveals a measurable failure in rights succession. ### Deceased Music Creators: Identifier Coverage | Identifier | Value | Coverage | |---------------|---------|----------| | Total deceased | 506,564 | -- | | MusicBrainz ID | -- | 61.2% | | Discogs ID | -- | 55.6% | | With IPI | -- | 16.0% | | Spotify ID | -- | 15.5% | | No IDs at all | 173,605 | 34.3% | Only **81,069** (16%) of deceased music creators have an IPI number. The remaining 425,495 are invisible to the royalty system, even though 54% have MusicBrainz IDs and 47% have Discogs IDs. They exist in the metadata ecosystem; they aren't connected to the payment infrastructure. Where we can match -- using those 81,069 IPIs -- we find **19,431 works** with unclaimed royalties linked to a deceased writer. These works average **62% unclaimed**, meaningfully higher than the 57.3% overall average. Death accelerates the unclaimed rate, consistent with the hypothesis that estates fail to maintain registrations. ### Deceased IPI Holders by Decade of Death | Decade | Deceased IPI Holders | |--------|---------------------| | 1950s | 4,708 | | 1960s | 2,427 | | 1970s | 4,813 | | 1980s | 6,834 | | 1990s | 11,868 | | 2000s | 14,063 | | 2010s | 18,940 | | 2020s | 14,197 | The visible dip in the 1960s is not demographic -- it reflects the founding of the IPI system. CISAC established the IPI (Interested Parties Information) identifier in 1965; creators who died before widespread IPI adoption are less likely to appear in this dataset. The problem is worsening. The 2010s saw 18,940 IPI-holding creators die -- the highest decade on record -- and the 2020s are on track to match that pace (14,197 through early 2026). Each death creates a window where mechanical registrations may lapse if estates are unaware of their obligations. > 425,000 deceased music creators have metadata identities across open databases but no connection to the mechanical royalty payment system. The bridge exists; it simply hasn't been built. --- ## Conclusion: The Registration Problem Is Solvable The data points to a specific, bounded failure -- not a diffuse, intractable one. That distinction matters. Six findings, one structural thesis: the Music Modernization Act built a collection system and assumed registration would follow. It didn't. Seven years later, 4.25 million works sit in a gap between performance and mechanical rights systems -- registered at one, absent from the other -- while generating active streaming revenue that accrues to the largest incumbents by default. But the shape of the problem also reveals why it is solvable. These are not unknown works by unknown creators. **67.5% are registered at ASCAP.** The writers are identified. **73% are on Spotify.** The recordings are active. **97% have ISRCs.** The distribution chain is intact. The only thing missing is a mechanical registration -- a form filing, not a discovery problem. Three interventions follow directly from the data: ### 1. Cross-Reference at Scale The ASCAP-MLC gap (Finding 2) is addressable by systematic cross-referencing of performance and mechanical registrations. A writer registered at a PRO whose publisher hasn't filed at the MLC is a *known* missing registration, not a mystery. The infrastructure to identify these gaps exists; the institutional incentive to act on them does not. ### 2. Fix the Succession Chain 425,000 deceased creators have metadata identities (MusicBrainz, Discogs) but no IPI -- the key to royalty collection. Bridging open identifiers to the payment system would reconnect estates to revenue streams that currently lapse at death. The data linkage is deterministic, not probabilistic. ### 3. Assign the Missing ISWCs 42.5% of MLC works lack the global identifier that enables cross-border collection. Without ISWCs, a work registered at the MLC is invisible to PRS, GEMA, SACEM, and every other territorial society. Closing this gap is a prerequisite for any international resolution of unclaimed royalties. None of these interventions require new legislation, new infrastructure, or new technology. They require **someone to do the work** -- to cross-reference the datasets that already exist, to file the registrations that were never made, to connect the identifiers that were never linked. The problem is administrative, not conceptual. The data to solve it is sitting in public and licensed databases. The question is whether the incentive structure of the current system -- which redistributes unclaimed royalties to incumbents on a market-share basis -- will ever produce the motivation to close the gap it profits from. > The unclaimed economy is not a mystery. It is a filing problem at scale -- and it will persist for exactly as long as the parties who benefit from redistribution are the same parties expected to close the registration gap. --- ## What This Means for Your Catalogue Every finding in this research has a direct analogue at the individual catalogue level. If 67.5% of unclaimed works are registered at a PRO, the first question any publisher should ask is: *are my works among them?* ### The Lifecycle of an Unclaimed Royalty What happens when a work generates streaming revenue but has no mechanical registration at the MLC: 1. **Work Streamed** -- Recording plays on Spotify, Apple Music, etc. 2. **Mechanical Royalty Generated** -- DSP owes royalty on the underlying composition. 3. **MLC Collects** -- Statutory body receives the mechanical royalty. 4. **Claimant Search** -- MLC checks: is a publisher or writer registered? 5. **No Claimant Found** -- Writer registered at ASCAP -- but not at the MLC. 6. **Royalty Enters Escrow** -- Held for the statutory period. Clock starts ticking. 7. **Statutory Period Expires** -- No claim filed. Royalty becomes distributable. 8. **Market-Share Redistribution** -- Royalty paid to largest registered publishers by default. **The outcome:** The creator's work generates the royalty. A major publisher -- who has no connection to the work -- receives it. Not through a claim, but through the MMA's default redistribution mechanism. **Revenue that is leaking, not lost.** The distinction matters. "Lost" implies the money has disappeared. It hasn't. Mechanical royalties on unclaimed works are being collected by the MLC -- they are sitting in escrow, accruing on a statutory countdown. When the holding period expires, those royalties are redistributed on a market-share basis to the largest registered publishers. The money isn't missing from the system. It is being collected, held, and given to someone else. **Yield erosion you can measure.** Catalogue owners increasingly think in yield terms -- annual revenue as a proportion of catalogue value. Every unregistered mechanical share is a direct drag on that yield. Unlike streaming market dynamics, which no individual publisher controls, registration gaps are entirely within the owner's power to close. An unclaimed mechanical share on an actively streaming work is not a market risk. It is an administrative failure with a calculable cost -- and it is the single highest-ROI fix available to any catalogue owner, because the revenue already exists. It simply needs to be claimed. **Asset value compression.** Music catalogue transactions now routinely price at 15-20x net publisher share. Buyers -- Hipgnosis, Round Hill, Primary Wave, Concord, and the institutional capital behind them -- conduct extensive due diligence before acquisition. A catalogue with significant unregistered mechanical shares is, by definition, under-earning relative to its potential. The gap between what a catalogue demonstrably earns and what it *should* earn is exactly where valuation discounts are applied. Incomplete registrations signal an unmanaged asset, and unmanaged assets compress the multiple. For any publisher considering a future sale, liquidity event, or catalogue valuation, unclaimed mechanicals are not just lost income -- they are lost enterprise value at a double-digit multiple. ### The Valuation Gap (Illustrative) Identical 500-work catalogue. One fully registered, one with typical registration gaps. The same music -- different enterprise value. | Metric | Fully Registered | 50% Unclaimed | |--------------------------|------------------------|----------------------------| | Annual Revenue | £120,000 | £84,000 | | Performance royalties | Collecting | Collecting | | Mechanical royalties | Collecting | 50% in escrow | | ISWC assigned | Yes | No | | Cross-border collection | Active | Impaired | | **Catalogue Valuation** | **£2.16M** (at 18x) | **£1.18-1.34M** (at 14-16x) | **Enterprise value lost to registration gaps: £820K-£980K** *Illustrative example using hypothetical figures. Actual multiples vary by catalogue age, genre, streaming trajectory, and buyer. Revenue reduction reflects lost mechanical share only; multiple compression reflects buyer due diligence discount for incomplete registrations. Both effects compound.* **A fiduciary obligation, not just a commercial one.** Publishers exist, contractually, to administer rights on behalf of their writers. If you hold publishing on a work and have not registered its mechanical share at the MLC, you are not only forgoing your own revenue -- you are failing to collect on behalf of the writers whose royalties you are contracted to administer. For self-published writers, the gap is simpler but no less consequential: you registered with your PRO, your performance royalties flow correctly, but your mechanical share has been accumulating in escrow since January 2021 -- destined for redistribution to the majors unless you file the claim. **The cost of inaction compounds.** This is not a one-time loss. Every month that a work remains unregistered is another month of mechanical royalties entering the redistribution pipeline. Every statutory distribution cycle that passes converts recoverable royalties into permanently redistributed ones. The problem is not static; it is accumulative. The longer the gap persists, the more value transfers irreversibly from the rightful owner to the default beneficiary. The audit is straightforward in principle: match your catalogue against the MLC's public unclaimed index, cross-reference your PRO registrations, and identify works where you hold publishing but never filed the mechanical claim. Check your ISWC coverage (Finding 5) -- works without ISWCs are invisible to every collection society outside the US. If you've inherited or acquired catalogue from a deceased creator (Finding 6), verify that mechanical registrations survived the transfer. These are not abstract problems. They are line items on a balance sheet that should be showing revenue and aren't. Consider a songwriter who registered with ASCAP in 2015 and released through a distributor. Their performance royalties flow correctly through their PRO. But if neither they nor their publisher registered the mechanical share at the MLC, every stream since January 2021 has generated a mechanical royalty that sits in escrow. After the statutory holding period, that royalty is redistributed proportionally to Universal, Sony, and Warner Chappell -- not because they claimed the work, but because the MMA's default mechanism allocates unclaimed funds by market share. The songwriter's ASCAP registration proves they exist. The MLC's unclaimed index proves the money is waiting. The only missing piece is a registration. This pattern repeats across millions of works. The audit to identify them is deterministic -- the same cross-referencing methodology behind this research. TrackForge built the cross-referencing infrastructure described in this research -- 3.2 billion records across 12 sources, deterministic matching, no probabilistic guesswork -- because we believe the registration gap is the defining inefficiency in music rights. We use it commercially to recover unclaimed royalties for our clients. We publish this research because the scale of the problem exceeds any single company's client base, and because structural problems require structural transparency to solve. --- ## Appendix: Data Sources & Methodology All findings derive from deterministic SQL queries against structured datasets. No machine learning models, no probabilistic matching, no revenue estimation. ### Data Sources | Source | Records | |---------------------|---------| | MLC Unclaimed Index | 4.25M | | MLC Work Metadata | 53.4M | | MLC Rights Index | 45.4M | | MLC All Rights | 145.6M | | MLC ISRC-Work | 37M | | ASCAP Works | 13.1M | | Spotify Tracks | 256M | | Wikidata Deceased | 506K | | MusicBrainz ISWCs | 343K | ### Analysis Pipeline 1. **Data Acquisition** -- All datasets stored as Parquet on Cloudflare R2. 1,835 files, 3.2 billion+ rows across 12 sources. Queried via DuckDB with httpfs extension. 2. **MLC Internal Joins** -- Unclaimed works joined to rights, metadata, and ISRC tables via MLC work_id. Share analysis uses all_rights with role and rights_type filters. 3. **ASCAP Cross-Reference** -- Normalised title matching (UPPER + TRIM) between MLC unclaimed titles and ASCAP works. Title collisions acknowledged as a source of false positives. 4. **Spotify Match** -- Unclaimed ISRCs matched against 256M Spotify tracks (Hive-partitioned by ISRC prefix). Both sample-based (100K) and full-join (7.15M) rates reported. 5. **Succession Analysis** -- Deceased rights holders matched via exact IPI join. No fuzzy matching. Only deterministic matches reported. 6. **Publisher Classification** -- Top 50 publishers by unclaimed volume manually classified as Major, Indie, DIY, or CMO/Admin by the research team. ### Limitations This analysis is limited to the US mechanical licensing system. A work "unclaimed" at the MLC may be fully claimed at PRS, GEMA, SACEM, or other territorial societies. We do not estimate revenue impact, as per-work streaming counts are unavailable. The ASCAP cross-reference uses title matching, which introduces false positives from title collisions; BMI and SESAC data are not included, which likely undercounts the performance/mechanical gap. The deceased analysis is bounded by Wikidata's coverage of notable artists. Publisher classifications use entity name matching and may contain minor errors from variant names. The over-claiming analysis counts mechanical publisher shares only; including writer shares may yield different totals depending on how the MLC allocates share types. **Temporal limitation:** All findings represent a single point-in-time snapshot. The MLC does not publish historical snapshots of its data, so we cannot show whether the unclaimed rate is improving, stable, or worsening since the MLC's launch in January 2021. A longitudinal study would require periodic data captures over multiple years -- a significant gap in the available evidence base. --- ## Disclosure TrackForge is a catalogue management and rights intelligence platform. We provide rights audit, enrichment, and recovery services to music publishers and rights holders. This research note uses public and licensed data sources to analyse structural patterns in the US mechanical licensing system. The analysis was not commissioned by any third party. TrackForge's commercial services include identifying unclaimed royalties for clients -- readers should consider this when evaluating our findings. For methodology questions or data access requests, contact **research@trackforge.studio** --- *Source: [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy)* --- ## research/isrc-registration-gaps.md # How ISRC Registration Gaps Cost Labels Money > A recording can be streaming on Spotify while having no mechanical work registered at the MLC. That gap — measurable, systemic, and worth hundreds of millions annually — is where royalties disappear. *Published by [TrackForge](https://trackforge.studio) — 2026-03-10* --- ## The Gap Nobody Measures TrackForge recently ran a full enrichment pipeline across a mid-size independent label catalog — 1,581 unique ISRCs, mostly punk, post-punk, and electronic releases spanning 1978 to 2024. We cross-referenced every recording against eleven data sources: streaming platforms, rights registries, community databases, and unclaimed royalty pools. The results were not subtle. Of 1,581 recordings, 680 appeared in the MCPS unclaimed pool — potential UK mechanical royalty gaps on 43% of the catalog. From the same label group, we traced a pattern of broken ISRC-to-work linkage across 17 products that accounted for **£48,456 in recoverable mechanical royalties**. The money had been collected by the CMO. It simply could not be routed to the correct rightsholder because the registration chain was incomplete. And 84 recordings — 5.3% of the catalog — returned zero matches across all eleven layers. No Spotify metadata, no MLC entry, no PRO registration, no community database listing. Valid ISRCs, commercially released music, completely invisible to every rights database we checked. Ghost recordings. An ISRC registration gap is the difference between a recording's commercial availability and its rights registration across collection societies. It is not a rounding error. It is the structural condition of music rights infrastructure, and until you measure it, you cannot know how much of your catalog is leaking revenue. --- ## The Layer Cake: One Catalog, Eleven Data Sources The full enrichment results form a layer cake of declining coverage. Each row represents the same 1,581 ISRCs checked against a different data source: | Data Source | ISRCs Matched | Match Rate | |---|---|---| | Spotify | 1,497 | 94.7% | | MLC Sound Recording | 1,419 | 89.8% | | MLC Release | 1,416 | 89.6% | | ASCAP (US Performance) | 861 | 54.5% | | MLC Musical Work | 791 | 50.0% | | MCPS Unclaimed Pool | 680 | 43.0% | | MusicBrainz | 569 | 36.0% | | AcoustID Fingerprint | 543 | 34.3% | | Discogs | 497 | 31.4% | | MLC ISWC Linkage | 374 | 23.7% | | PRS Unclaimed Pool | 326 | 20.6% | | MLC Unclaimed Shares | 177 | 11.2% | The drop from Spotify (94.7%) to MLC Musical Work (50.0%) is the core registration gap — a 45-point chasm. These recordings are commercially available and generating streams. Spotify has the metadata. The MLC has the sound recording resource. But for half the catalog, no registered mechanical work is linked, meaning royalties from those streams have no verified destination. The ASCAP column reveals a second fracture. 54.5% of the catalog matched to US performance rights registrations — but only 50.0% had corresponding MLC mechanical work registrations. The same compositions are partially registered for performance royalties but missing from the mechanical system. In the US, performance and mechanical rights are administered by entirely separate organisations, and registration in one does not propagate to the other. Perhaps the most revealing finding: **33% of the catalog's ISRCs were missing from the label's own registry.** They were only discovered by cross-referencing PRS tunecode bridge tables and other external sources. The label did not know these recordings existed in their catalog — and without external cross-referencing, those tracks would have remained unlinked to their rights registrations permanently. --- ## What ISO 3901 Says (and Doesn't Say) The International Standard Recording Code is governed by ISO 3901, administered by the IFPI. It provides, in the IFPI's own language, "unique and permanent identification of sound recordings across formats and distribution channels." The standard defines *who can assign* ISRCs — national agencies issue registrant codes to labels, distributors, and producers. What the standard does not define is *who must register them with collection societies*. There is no enforcement mechanism requiring a label to link an ISRC to a musical work at the MLC, MCPS, ASCAP, or any other organisation that needs the linkage to route royalties. The IFPI publishes 15 guidance documents covering assignment rules, ownership, and best practices. DDEX "strongly encourages including ISRCs whenever available" in revenue reports. But encouragement is not infrastructure. The result is a gap by design. An ISRC can exist in Spotify's catalogue, in DDEX delivery messages, and in a label's internal database — and simultaneously be absent from every collection society that pays royalties on the underlying composition. The identifier exists. The cross-registration does not. --- ## The Mechanical Black Hole The catalog-level findings are not anomalous. They reflect a systemic condition visible in the MLC's own aggregate data. The MLC's Bulk Work-Resource Matching (BWARM) dataset — 3.78 billion rows, publicly available — contains 954 million sound recording resources. Of those, **691.7 million (72.5%) have no matched mechanical work.** These are recordings with ISRCs, appearing on streaming platforms, generating royalty obligations. But no registered musical work is linked to them in the US mechanical licensing system. The MLC also holds 57.3 million unclaimed musical work right share records — ownership stakes in compositions where the work is identified, often with an ISWC and writer information, but no rightsholder has claimed the mechanical share. The work is known. The money is waiting. Nobody has filed the paperwork. The financial consequence is published in the MLC's annual reports: | Usage Year | Total Held | Unmatched | Unclaimed | |---|---|---|---| | 2021 | $90.9M | $44.4M | $44.9M | | 2022 | $106.5M | $53.7M | $49.1M | | 2023 | $174.5M | $92.0M | $73.1M | | 2024 | $197.0M | $110.3M | $76.7M | | **Total** | **$569.9M** | **$300.3M** | **$243.9M** | The held balance has more than doubled in three years — from $90.9 million to $197.0 million. The MLC has made progress through reprocessing: for 2021 usage, reprocessing matched an additional $63.6 million that was initially unmatched. For 2023, the figure was $54.9 million. But new unmatched royalties accrue faster than reprocessing can clear the backlog. The Music Modernization Act, signed in 2018 and effective January 2021, was designed to solve this. The MMA replaced song-by-song mechanical licensing with a blanket licence administered by the MLC. Five years in, the MLC's own outreach has located "hundreds of previously unregistered rightsholders" and distributed "close to $1 million" in accrued royalties to them. One million dollars against a $569.9 million held balance is 0.18%. The problem is not that rightsholders are hard to find. The problem is that the infrastructure for linking ISRCs to works to rightsholders does not exist as a unified system. --- ## What It Actually Costs Return to the 1,581-ISRC catalog. The £48,456 MCPS recovery is instructive not for its size but for its cause. In every case, the ISRCs existed on the recordings. The works were registered with PRS for performance rights. But the mechanical registrations at MCPS were either missing, incomplete, or linked to the wrong entity. The money was collected. It could not be routed. This is not a one-catalog problem. Consider the arithmetic: A 1,581-ISRC catalog yielded 84 ghost recordings (5.3%), a 33% internal registry gap, and a 43% MCPS unclaimed signal rate. The rate will vary by catalog age, genre, and territory — a major-label pop catalog with recent releases will likely fare better than a back-catalog-heavy independent. But the IFPI's International ISRC Database contains over 100 million registrations, and the MLC's own data shows 72.5% of 954 million sound recording resources unmatched to any mechanical work. The pattern observed in one catalog is independently confirmed at aggregate scale. Even a conservative estimate suggests tens of millions of ISRCs are inadequately cross-referenced — present in some systems, absent from others, generating royalties that cannot be routed. At the MLC alone, $569.9 million in royalties sat in holding accounts across four usage years — approximately **$142.5 million per year** collected but not distributed. The MLC is a single organisation, in a single territory, covering a single right. Now multiply. MCPS handles UK mechanical royalties. GEMA covers Germany. SACEM covers France. JASRAC covers Japan. APRA AMCOS covers Australia. Each maintains its own registry, its own matching logic, and its own unmatched pool. There are over 230 collection societies worldwide. The 45-point gap between Spotify coverage and MLC work registration observed in one catalog is not an artefact of catalog size or genre. The MLC's own aggregate data independently confirms it: 72.5% of 954 million resources unmatched across the entire US mechanical system. The structural cause — assignment without cross-registration — applies universally. The global cost of ISRC registration gaps does not run into the hundreds of millions. It runs into the billions. --- ## Closing the Gap: What Labels Should Do The registration gap is not a technology problem. The identifiers exist. The databases exist. The collection societies exist. What is missing is cross-referencing — systematic verification that a recording registered in one system is also registered in every other system that needs to know about it. **1. Don't trust your own registry.** The case study found 33% of a catalog's ISRCs missing from the label's internal records — discovered only through PRS tunecode bridge tables, MusicBrainz community data, and MLC bulk feeds. Cross-reference every ISRC against a minimum of three independent sources. No single source is complete. Coverage requires triangulation. **2. Register mechanical rights separately from performance rights.** The 54.5% ASCAP vs. 50.0% MLC work match rate proves the point: performance and mechanical rights are different systems with different administrators. Registration at PRS does not register you at MCPS. Registration at ASCAP does not register you at the MLC. Treat them as separate obligations, because they are. **3. Audit ISRC-to-ISWC linkage annually.** Only 23.7% of the case study catalog had ISWC linkage in the MLC's data. Without that link, mechanical royalties for streamed recordings cannot be matched to the underlying composition — regardless of whether both identifiers exist in their respective registries. The identifiers are not the problem. The linkage between them is. **4. Check unclaimed pools before they expire.** 43% of the catalog appeared in the MCPS unclaimed pool. 20.6% appeared in PRS unclaimed. These are published datasets — not secrets. But unclaimed pools have holding periods, and after expiration, funds are distributed to other members on a market-share basis. The £48,456 MCPS recovery existed because someone checked. The money that nobody checks for goes to someone else. TrackForge's enrichment pipeline automates this cross-referencing across eleven data sources, identifying registration gaps before royalties enter unclaimed pools. The analysis in this article runs automatically for every catalog onboarded to the platform. The registration gap exists because the music industry's rights infrastructure was built as a collection of independent silos. Closing it requires looking across all of them at once. --- ### Sources and Methodology | Source | Dataset | Access | |---|---|---| | MLC | BWARM bulk data feed (2025-02-23 snapshot) | Public dataset, 3.78B rows | | MLC | 2024 Annual Report | Published March 2025 | | IFPI | ISO 3901 / ISRC Standard Documentation | 15 published guidance documents | | ASCAP | ACE repertory search | Public search interface | | PRS for Music | Unclaimed works registry | Licensed data | | MCPS | Unclaimed mechanical royalties | Licensed data | | MusicBrainz | Community recording database | Open data (CC0) | | AcoustID | Audio fingerprint database | Open data | | Discogs | Release and label metadata | API access | | Spotify | Track and artist metadata | API access | | DDEX | Communication standards (ISRC formatting) | Published specifications | | CISAC | CWR v2.1/v2.2 specifications | Published standards | | US Federal Register | MMA implementation rules (2020-29190) | Public record | *Catalog data anonymised. All match rates are from a single enrichment run across 1,581 unique ISRCs. Individual catalog results will vary based on genre, territory, and release era.* *This analysis uses TrackForge's enrichment pipeline, which cross-references recordings against commercial metadata, rights registrations, and unclaimed royalty pools. The methodology is described in [The Black Box Problem](/black-box).* --- *Source: [How ISRC Registration Gaps Cost Labels Money](https://trackforge.studio/research/isrc-registration-gaps)* --- ## research/royalty-leakage-map.md # Where the Money Goes: A Map of Royalty Leakage > Music royalties disappear at 12 distinct stages between creation and collection. 160+ failure modes mapped across 15 data sources. The first systematic taxonomy. *Published by [TrackForge](https://trackforge.studio) — 2026-04-03* --- Every year, billions in music royalties are collected but never reach the rights holders who earned them. The industry calls this "leakage" and treats it as an inevitable cost of complexity. It isn't. It's a series of specific, mappable failures — and this is that map. A taxonomy of 12 lifecycle stages through which royalties disappear, identified through cross-reference analysis of 3.2 billion records from 15 independent data sources. More than 160 distinct failure modes. Every one observed in real catalogue data. --- The music rights ecosystem is a relay race run in the dark. A song is created, recorded, registered, verified, linked, exploited, and — eventually — paid for. At each handoff, data must pass correctly from one system to the next. When it doesn't, royalties disappear. Not dramatically. Not visibly. They simply stop flowing to the people who earned them. Rights holders discover the gaps retroactively — years after the fact, one work at a time, usually by accident. This paper proposes a different approach: a taxonomy of royalty leakage organised by lifecycle stage. Drawing on programmatic comparison of identifier fields, registration records, and exploitation signals across 3.2 billion records from 15 independent data sources, we identify 12 distinct points in the lifecycle of a musical work where royalties can be lost, delayed, or misdirected. Each stage has its own causes, its own symptoms, and its own detection methods. Together, they form the first systematic map of where the money goes. The infrastructure that processes music royalties is itself a source of silent failure. As we explored in [The Black Box Problem](https://trackforge.studio/black-box), IT migrations, system changes, and back-office transitions routinely redirect revenue without anyone noticing. What follows maps not just the data failures, but the structural ones — the points at which the chain of custody between exploitation and payment quietly breaks. --- ## Twelve Stages, One Lifecycle A musical work passes through 12 stages between creation and collection. At each stage, specific failure modes cause royalties to leak from the system. Two stages dominate: **Verification** (Stage 4) and **Revenue Leakage** (Stage 9). But the earlier stages — Creation, Recording, and Registration — are where root causes originate. A verification failure at Stage 4 almost always traces back to a data quality issue at Stage 1 or a registration gap at Stage 3. | Stage | Name | Failure Modes | |-------|------|:---:| | 01 | Creation | 6 | | 02 | Recording | 7 | | 03 | Registration | 11 | | 04 | Verification | 25 | | 05 | Linkage | 4 | | 06 | Data Quality | 7 | | 07 | Sync | 4 | | 08 | Exploitation | Under development | | 09 | Revenue Leakage | 27 | | 10 | Distribution | 1 | | 11 | Structural | 3 | | 12 | Time | 1 | These figures cover publishing and mechanical rights. An additional 55 failure modes address neighbouring rights (PPL, SoundExchange, MLC mechanical), and 16 more handle cross-source validation and cross-domain detection. The complete taxonomy encompasses more than 160 distinct failure modes across the full spectrum of music rights. --- ## Stage 01 — Creation: Where the Data Should Begin Before a song is registered anywhere, its ownership is determined. This is where the data that governs every downstream royalty payment is supposed to originate. Before a song has an ISRC, a tunecode, or an IPI match, writers agree on splits. Samples are cleared — or not. Contributors are credited — or forgotten. Metadata standards at the point of creation are minimal to nonexistent. Split agreements are often verbal. Co-writers may not have society affiliations. Sample clearances lag behind release dates. What makes creation-stage failures particularly damaging is their **invisibility to downstream systems**. A collecting society can only verify what has been registered. If the underlying splits are wrong — or never recorded at all — every registration built on top of them carries the error forward. A 5% split discrepancy at creation becomes a 5% revenue misdirection at every subsequent stage, in every territory, for every right type, for the life of the work. --- ## Stage 02 — Recording: Identity Fragmentation A single composition can generate dozens of recordings. When their identifiers collide, are reused, or aren't assigned, recordings can't be linked to their underlying compositions. The original studio version. A radio edit. An explicit version. A clean version. An acoustic session. A live recording. Remixes. Each recording needs its own **ISRC** (International Standard Recording Code, ISO 3901). When ISRCs collide, are reused across labels, or simply aren't assigned, the recording can't be linked to its underlying composition — and the royalties it generates have nowhere to go. Our analysis of 256 million Spotify tracks cross-referenced against MLC and PRS data reveals persistent identity fragmentation. The same composition appears under variant titles, different artist credits, and sometimes different ISRCs across platforms. As we documented in [How ISRC Registration Gaps Cost Labels Money](https://trackforge.studio/research/isrc-registration-gaps), an 11-layer coverage analysis of a mid-size label catalogue showed 94.7% Spotify coverage against just 50% MLC work registration — a 45-point gap where mechanical royalties disappear into holding pools. --- ## Stage 03 — Registration: The Publisher Gap The single largest category of royalty leakage. Works that are commercially exploited but never registered for the relevant right type in the relevant territory. A work can be commercially released, actively streaming on every major platform, generating royalty obligations in multiple territories — and never be registered with the relevant collecting society for the relevant right type. The structural cause is straightforward: **performance rights and mechanical rights have separate registration pathways**. A writer who registers with ASCAP for US performance royalties has not registered for US mechanical rights at the MLC. A UK publisher who registers with PRS for performance has not necessarily registered with MCPS for mechanical. Each society, each territory, and each right type requires its own registration. The scale of this gap is staggering. Our analysis of the MLC's Bulk Work Audio-Visual Registration Matching (BWARM) database found that **954 million sound recording resources had no matched musical work** — a 72.5% unmatched rate. Of the works that were unclaimed at the MLC, 67.5% were registered for performance rights at ASCAP. The writers were known. The compositions were registered. But nobody had registered the mechanical right. - **72.5%** of MLC sound recordings with no matched musical work - **67.5%** of unclaimed works registered at ASCAP for performance - **954M** sound recording resources in the MLC BWARM database This is not an edge case. It is the default state for a majority of musical works in the United States mechanical licensing system. As we detailed in [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy), 4.25 million works have partially or fully unclaimed mechanical royalties at the MLC — 73% of them actively streaming on Spotify. The US is not unique. The same structural gap exists wherever performance and mechanical rights are administered separately. --- ## Stage 04 — Verification: When the Numbers Don't Add Up A registered work is not necessarily a correctly registered work. Shares that don't sum to 100%. Expired identifiers. Missing cross-references. Writer and publisher shares should sum to 100% for each right type in each territory. In practice, they often don't. Shares are over-claimed, under-claimed, or left at placeholder values. **IPI numbers** — the unique identifiers assigned to rights holders by their collecting societies — may be expired, reassigned, or simply wrong. We flag these as "artifact IPIs": identifiers that persist in society databases long after the entity they represent has changed or ceased to exist. The **International Standard Musical Work Code (ISWC)** was designed to solve cross-society identification. But ISWC adoption remains partial. Many registered works lack one, and when ISWCs are assigned, they sometimes link works that shouldn't be linked — or fail to link works that should be. Dispute processes at collecting societies can take years to resolve, during which royalties are held rather than distributed. Of the 12 stages in this taxonomy, verification has the **highest density of distinct failure modes** — more than twice as many as any individual earlier stage. This reflects the combinatorial complexity: for each work, there are multiple writers, multiple publishers, multiple territories, and multiple right types, each with its own share allocation that must be independently correct. --- ## Stage 05 — Linkage: Same Song, Different Database A work can be registered at every society and still not get paid — because the systems don't know they're referring to the same composition. PRS identifies a work by its tunecode. ASCAP uses a different work ID. BMI uses another. The MLC, yet another. Spotify knows recordings by ISRC. MusicBrainz assigns its own identifiers. Unless these are linked, a work can be registered everywhere and still not get paid — because the databases don't know they're talking about the same song. The challenge is not just identifier mapping. It's **title normalisation** (is it "Don't Stop Believin'" or "Dont Stop Believin" or "Don't Stop Believing"?), **writer name matching** (is "Diane Eve Warren" the same person as "D. Warren"?), and **version disambiguation** (is the recording on Spotify the same one registered at PRS?). CISAC's CIS-Net system provides a global work identifier network, but participation and data quality vary significantly across its 230+ member societies. --- ## Stage 06 — Data Quality: The Metadata Tax Every piece of incorrect or missing metadata becomes a matching failure somewhere downstream. These are quiet, systemic erosions that compound across millions of records. Duration fields that read 0:00. Territory codes that don't map to any CISAC standard. Works attributed to labels instead of publishers. Rights type fields left blank. These are not dramatic failures. They are the everyday noise of imperfect data that, multiplied across millions of records and dozens of databases, creates a persistent tax on royalty accuracy. Our cross-reference analysis systematically flags data quality anomalies: comparing the same field across multiple sources and identifying records where values conflict. The most common anomalies are not errors in any single database — they are **inconsistencies between databases** that prevent automatic reconciliation. --- > "The industry does not have a leakage problem. It has twelve leakage problems, occurring simultaneously, at different stages of the same lifecycle, with different root causes and different solutions." --- ## Stage 07 — Sync: The Unregistered Placement Sync licensing is one of the fastest-growing revenue streams in the industry. It is also one of the least consistently reported to collection societies. When music is placed in a film, television programme, advertisement, or video game, it generates both **performance royalties** (from broadcast and public performance) and **mechanical royalties** (from reproduction). Sync deals are negotiated directly between licensees and rights holders. The resulting placements are supposed to be reported to the relevant collecting societies so that royalties can be collected. In practice, reporting is often delayed, incomplete, or missed entirely. --- ## Stage 08 — Exploitation: Usage Without Tracking Music is exploited in more ways than ever. Not all of that usage is tracked, sampled, or reported to collection societies. Streaming platforms, broadcast radio, satellite radio, live venues, retail spaces, fitness classes, podcasts, user-generated content, AI training datasets. The ways music is exploited have multiplied. Broadcast monitoring systems sample a fraction of total airplay. UGC platforms operate under blanket licences that may not produce per-work reporting. As we described in [The Black Box Problem](https://trackforge.studio/black-box), the infrastructure that processes this data is itself a source of failure. --- ## Stage 09 — Revenue Leakage: The Growing Pools This is where the cumulative effect of every upstream failure becomes visible. Money has been collected. It can't find its owner. And the clock is ticking. The **MLC alone held $569.9 million** in royalties across usage years 2021 to 2024 — approximately $142.5 million per year, collected but not distributed. The MLC is one organisation, covering one territory and one right type. With over 230 collection societies worldwide, each managing their own holding pools for their own right types and territories, the global scale of unclaimed royalties is measured in billions. In the UK, the MCPS holds significant sums in unmatched mechanical royalties. PRS maintains a separate pool for unclaimed performance royalties. Our analysis identifies **14.1 million PRS unclaimed performance records** spanning 2021 to 2025. ### The Drain Clock Societies hold unclaimed royalties for a defined period — typically three to seven years — before **redistributing them to existing members based on market share**. Once redistributed, the original rights holder's claim is extinguished. Not because they weren't entitled to the money, but because nobody connected the dots in time. This creates a structural transfer from smaller, less well-administered catalogues to larger, better-administered ones. --- ## Stages 10-12 — The Long Tail **Distribution (Stage 10)** — Many societies set minimum payment thresholds, typically £1 to £10 per accounting period. For catalogues with thousands of low-earning tracks, these micro-payments accumulate into material sums that may never be paid out. **Structural (Stage 11)** — When a link in the publishing administration chain breaks — a company is dissolved, an administrator changes, a catalogue is sold without proper society notification — royalties accumulate against an entity that can no longer receive them. Our analysis cross-references Companies House dissolution records against active society registrations. **Time (Stage 12)** — Most retrospective claims are subject to limitation periods. By the time a registration gap is discovered, years of royalties may already be beyond recovery. Early, systematic detection is the only effective defence. --- ## Why Leakage Multiplies These 12 stages do not operate in isolation. A work with a creation-stage split error (Stage 1) that also has a registration gap (Stage 3) and a linkage failure (Stage 5) is not three times as hard to recover. It is **exponentially harder** — because each fix reveals the next problem, and each problem exists in a different system administered by a different organisation. Manual auditing — the industry's traditional approach — can catch individual failures. But it cannot systematically detect patterns across all 12 stages simultaneously. As we argued in [Why TrackForge Exists](https://trackforge.studio/why), the information asymmetry in catalogue transactions is a structural problem. --- ## The Neighbouring Rights Gap A parallel set of failures affects the rights of performers and record producers. In the UK, PPL collects neighbouring rights. In the US, SoundExchange handles statutory digital performance royalties. Neither system talks to the other. The neighbouring rights dimension adds 55 additional failure modes to the taxonomy. | Rights Domain | Failure Modes | |--------------|:---:| | Publishing | 96 | | Neighbouring Rights | 55 | | Cross-Source | 16 | --- ## What Systematic Detection Looks Like By organising leakage into discrete, detectable stages, the problem becomes tractable: 1. **Registration Check** — Is this work registered for this right type in this territory? 2. **Share Verification** — Do the registered shares sum to 100%? Do they match across societies? 3. **Linkage Validation** — Is the registration linked to exploitation data? 4. **Chain Integrity** — Is every entity in the administration chain active and solvent? 5. **Recovery Window** — Is there a retrospective claim window still open? Each question can be tested programmatically against real data. The combination of results across all stages produces a complete picture of a work's royalty health — or reveals exactly where the chain is broken. --- This research builds on: [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy) (March 2026), [How ISRC Registration Gaps Cost Labels Money](https://trackforge.studio/research/isrc-registration-gaps) (March 2026), and [The Black Box Problem](https://trackforge.studio/black-box). > The industry treats royalty leakage as an inevitable cost of doing business. It isn't. It's a series of specific, identifiable failures at specific, identifiable points in the lifecycle — and every one of them can be detected, measured, and systematically addressed. --- ## Frequently Asked Questions **What is royalty leakage in the music industry?** Royalty leakage is the systematic loss of music royalties between the point of exploitation (when a song is played, streamed, or broadcast) and the point of payment (when the rights holder receives money). It occurs at 12 distinct stages in the lifecycle of a musical work. TrackForge's analysis of 3.2 billion records across 15 data sources identifies more than 160 distinct failure modes across these stages. **How much money is lost to royalty leakage?** The MLC alone held $569.9 million in unclaimed mechanical royalties across usage years 2021 to 2024. The MLC covers one territory (US) and one right type (mechanical). With over 230 collection societies worldwide, the global scale of unclaimed royalties runs into the billions annually. **What are the main causes of royalty leakage?** The three largest causes are: (1) Registration gaps — works that are commercially exploited but never registered with the relevant collecting society. Our analysis found 72.5% of MLC sound recording resources have no matched musical work. (2) Verification failures — registered works with incorrect shares, expired identifiers, or missing cross-references. (3) Revenue pool drainage — collected royalties that sit in holding accounts until redistribution deadlines expire, typically 3-7 years. --- ## Related Research - [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy) — 4.25 million works with unclaimed US mechanical royalties at the MLC - [How ISRC Registration Gaps Cost Labels Money](https://trackforge.studio/research/isrc-registration-gaps) — 94.7% Spotify match vs 50% MLC work registration - [The Black Box Problem](https://trackforge.studio/black-box) — IT infrastructure failures that silently reshape who gets paid --- *Source: [Where the Money Goes: A Map of Royalty Leakage](https://trackforge.studio/research/royalty-leakage-map)* --- ## certification/cwr/what-is-cwr.md # What is CWR? Common Works Registration Explained > CWR (Common Works Registration) is the CISAC standard format for registering musical works with collecting societies worldwide. *Published by [TrackForge](https://trackforge.studio) -- 9 March 2026* --- Common Works Registration is the global standard for exchanging music rights data between publishers and collecting societies. Every royalty payment starts with a registration -- and almost every registration travels as a CWR file. If you work in music publishing, administer rights, or collect royalties across territories, CWR is the format that carries your data from your system to theirs. - CISAC Standard - Fixed-Width ASCII - Used by 200+ Societies --- ## The Format CWR is a flat-file data format maintained by CISAC (the International Confederation of Societies of Authors and Composers). It exists for one purpose: to let publishers register musical works with collecting societies in a standardised, machine-readable way. A CWR file is a **fixed-width ASCII text file** with strict formatting rules. Every line is exactly 80 characters in CWR 2.1 (or variable-length in 2.2), and every character position has a defined meaning. There are no delimiters, no XML tags, no JSON brackets. It is a positional format -- column 1 to column 3 is always the record type, column 4 to column 22 is always the transaction sequence number, and so on. Inside a CWR file you will find everything that defines a musical work from a rights perspective: ### Identifiers (ID) ISWC (International Standard Musical Work Code), society work numbers, publisher-assigned internal identifiers. The keys that link a work across systems worldwide. ### Interested Parties (IP) Every contributor to the work: writers, composers, arrangers, sub-arrangers, translators. Each identified by IPI number (Interested Parties Information) and society affiliation. ### Publishers (PU) Original publishers, sub-publishers, administrators, income participants. The full chain of entities with a commercial interest in the work. ### Ownership Shares (SH) Performance, mechanical, and synchronisation shares for each interested party. Expressed as percentages that must sum correctly within the file. ### Territory (TR) Which territories (countries or regions) each share applies to. A single work can have different ownership structures in different territories -- CWR handles this natively. ### Recordings (RC) Links to specific sound recordings via ISRC codes, connecting the abstract musical work to its physical or digital embodiments. --- ## Why It Matters: The Backbone of Music Rights Data Exchange Before CWR, every collecting society had its own proprietary format for receiving work registrations. A publisher operating across 20 territories needed 20 different data pipelines. Mismatches were inevitable. Royalties were delayed, misallocated, or lost entirely. CWR standardised this. A single format that any publisher can use to register works with any participating society. Today it is used by **publishers, sub-publishers, administrators, and CMOs** (Collective Management Organisations) across more than 200 territories. The practical impact is significant. When a song is played on radio in Germany, streamed in Japan, and performed live in Brazil, the royalties generated in each territory need to flow back to the correct rights holders. That flow depends on accurate registration data -- and that data almost always travels as CWR. > **Key Point:** CWR does not determine who owns a work. It **communicates** ownership information between systems. The legal reality of who wrote, published, and controls a work exists independently. CWR is the transport layer that ensures every society has the same information. If you are a publisher and your CWR registrations are incomplete, late, or contain errors, the consequence is direct: **societies cannot match your works to usage, and royalties accumulate as unidentified or unclaimed income.** Getting CWR right is not administrative overhead -- it is the mechanism by which you get paid. --- ## The Workflow: How CWR Files Move Between Systems CWR is a two-way exchange. Publishers send registrations, societies send acknowledgements. Understanding this round-trip is essential to working with CWR effectively. ### Step 1: Publisher sends NWR The publisher creates a CWR file containing NWR (New Work Registration) transactions for works being registered for the first time, or REV (Revised Registration) for updates to existing works. The file is transmitted to the receiving society, typically via FTP or a web portal. ### Step 2: Society validates The society's system parses the file, checks formatting rules, validates share totals, cross-references IPIs against its own database, and looks for potential duplicate registrations. This can take hours or weeks depending on the society. ### Step 3: Society returns ACK The society sends back an acknowledgement file (ACK) containing accept or reject decisions for each transaction. Accepted works receive official identifiers: the society's internal work number and, if assigned, an ISWC. Rejected works include error codes explaining what went wrong. ### Step 4: Publisher enriches catalog The publisher processes the ACK file, updates their catalog with society-assigned identifiers, and fixes any rejected registrations for resubmission. The catalog grows richer with each round-trip. > **Common Misconception:** CWR is not a one-time submission. Catalogs change constantly -- new works are created, shares are revised, sub-publishing deals change territory allocations, writers switch societies. A healthy publishing operation sends CWR files regularly and processes every ACK that comes back. --- ## Ownership vs. Collection Every CWR file encodes two distinct concepts that are often confused: who *owns* a share of a work, and who has the *mandate to collect* royalties for that share in a given territory. **Ownership shares** reflect the legal reality of who created and controls the work. A songwriter who wrote 50% of the lyrics owns a 50% writer share. Their publisher controls a corresponding publisher share. These percentages are facts about the work itself -- they do not change based on who you are registering with. **Collection shares** reflect administrative arrangements. A UK publisher might collect 100% of mechanical royalties in the UK through MCPS, but only 25% in Germany through a sub-publisher registered with GEMA. The same work, the same ownership -- but different collection mandates in different territories. | Dimension | What It Represents | Changes When | Scope | |---|---|---|---| | **Ownership** | Legal entitlement to a share of the work | Work is re-assigned, share is sold, reversion clause triggers | Global (same everywhere) | | **Collection** | Administrative mandate to collect royalties | Sub-publishing deal signed, administrator changed, territory added/removed | Per-territory | What you include in a CWR file depends on context. When registering with your home society, you typically declare both ownership and collection shares. When sending data to a sub-publisher for registration in their territory, you may only include the shares relevant to their mandate. When exchanging between societies (CRD -- Common Royalty Distribution), the focus shifts to collection entitlements. > **Practical Consequence:** If your CWR file declares ownership shares but omits the collection mandate for the receiving society's territory, the society knows who owns the work but has no instruction to pay anyone. If it declares collection shares that exceed the actual ownership, the society will reject the registration. Getting both dimensions right -- and keeping them in sync -- is where most CWR problems originate. --- ## CWR 2.1 vs. 2.2 Two versions of CWR are in active use. Understanding the differences -- and knowing which to use when -- matters more than you might expect. **CWR 2.1** has been the workhorse of music publishing data exchange for over a decade. It is universally supported, well-understood by every major society, and handles the vast majority of registration scenarios. Its fixed 80-character line length and rigid structure make it predictable and reliable. **CWR 2.2** extends the format with capabilities that address real limitations in 2.1. Variable-length records allow more metadata. Multiple identifier support means a work can carry its ISWC, multiple society work numbers, and publisher internal codes simultaneously. Complex rights chains with multiple levels of sub-publishing are better represented. | Feature | CWR 2.1 | CWR 2.2 | |---|---|---| | Record length | Fixed 80 chars | Variable length | | Work identifiers | One per work | Multiple per work | | Society support | Universal | Partial (growing) | | Rights chain depth | Basic (OP + sub-publisher) | Extended (multi-level chains) | | Additional metadata | Limited | Extended (AVI, additional titles, etc.) | | Character encoding | ASCII only | ASCII (UTF-8 discussed, not standard) | | Backward compatibility | N/A | 2.1 files are valid 2.2 | | Recommended for | Maximum compatibility | Complex catalogs, multi-territory chains | > **Practical Advice:** Always check with the receiving society before choosing a version. If the society accepts 2.2 and you need its features, use 2.2. If you are unsure, or the society has not confirmed 2.2 support, use 2.1. A valid 2.1 file that arrives and is processed correctly is always better than a 2.2 file that is rejected or partially parsed. The industry is gradually moving toward 2.2, but "gradually" in music publishing standards means years, not months. Many societies still run 2.1-only pipelines. Some accept 2.2 files but silently ignore the new fields. The safe default remains 2.1 unless you have a specific reason to use 2.2 and have confirmed support with your receiving society. --- ## Anatomy of a CWR File A CWR file is organised into a strict hierarchy: header, groups, transactions, records, and trailer. Every valid file follows this structure without exception. ### HDR -- Transmission Header One per file. Identifies the sender (publisher), receiver (society), creation date, and CWR version. Always the first record. ### GRH -- Group Header Marks the start of a group of transactions. Groups organise works by transaction type (NWR, REV, etc.). A file can contain multiple groups. ### TXN -- Transactions Each transaction represents one work. Contains the NWR/REV record followed by all its detail records: SPU (publisher), SWR (writer), SPT/SWT (territory shares), REC (recording), and more. ### GRT -- Group Trailer Closes a group. Contains the count of transactions and records in the group, used for validation. ### TRL -- Transmission Trailer One per file, always the last record. Contains total counts for the entire file: groups, transactions, and records. If the counts do not match, the file is invalid. The record counts in GRT and TRL are not optional niceties -- they are validation checksums. If your file claims 150 transactions in the trailer but contains 148, the receiving society will reject the entire file. This rigid structure is deliberate: it catches truncation, corruption, and incomplete generation before bad data enters the society's system. --- > "Every misregistered work is a royalty payment that goes to the wrong place -- or nowhere at all. CWR is not glamorous infrastructure. It is essential infrastructure." --- ## Validate Your CWR Files The TrackForge CWR Validator checks your files against the CWR 2.1 and 2.2 specifications. It catches formatting errors, share calculation problems, missing identifiers, and structural issues before you submit to a society. Upload a file. Get results in seconds. No account required. - [Validate a CWR File](https://trackforge.studio/cwr-tool) - [CWR Record Types Reference](https://trackforge.studio/certification/cwr/record-types) --- ## Related Documentation - **[CWR Record Types](https://trackforge.studio/certification/cwr/record-types)** -- Complete reference for every record type in CWR 2.1 and 2.2. NWR, REV, SPU, SWR, SPT, SWT, REC, ACK -- what each contains and when to use it. - **[Common CWR Errors](https://trackforge.studio/certification/cwr/common-errors)** -- The most frequent CWR validation failures and how to fix them. Share calculation mismatches, missing IPIs, malformed identifiers, and structural problems. - **[CWR Validator Tool](https://trackforge.studio/cwr-tool)** -- Upload your CWR file and get instant validation against the official specification. Free, no account required. --- ## Frequently Asked Questions **What is CWR (Common Works Registration)?** CWR is a flat-file data format maintained by CISAC for registering musical works with collecting societies worldwide. It is a fixed-width ASCII text file containing work identifiers (ISWC), interested parties (writers, composers), publishers, ownership shares, territory allocations, and recording links (ISRC). **What is the difference between CWR 2.1 and CWR 2.2?** CWR 2.1 uses fixed 80-character lines and is universally supported. CWR 2.2 adds variable-length records, multiple identifier support, and better multi-level sub-publishing chains. Most societies still run 2.1-only pipelines, so always check with the receiving society before using 2.2. **How does the CWR workflow work?** CWR is a two-way exchange: (1) Publisher sends NWR or REV transactions, (2) Society validates and cross-references, (3) Society returns an ACK file with accept/reject decisions and assigned identifiers, (4) Publisher processes the ACK and updates their catalogue. **What is the difference between ownership and collection shares in CWR?** Ownership shares reflect legal entitlement and are global. Collection shares reflect administrative mandates to collect royalties and vary per territory. Both must be correctly declared in CWR files. **How can I validate a CWR file before submitting to a society?** Use the free [TrackForge CWR Validator](https://trackforge.studio/cwr-tool). Upload your .V21 or .V22 file and get instant validation against the CISAC specification. No account required. --- *Source: [https://trackforge.studio/certification/cwr/what-is-cwr](https://trackforge.studio/certification/cwr/what-is-cwr)* --- ## certification/cwr/record-types.md # CWR Record Types -- A Complete Reference > A reference guide to every record type in a CWR file, covering file structure, work registration, party records, share arithmetic, and version type codes. *Published by [TrackForge](https://trackforge.studio) -- 9 March 2026* --- CWR -- Common Works Registration -- is the CISAC standard for exchanging musical work data between publishers, sub-publishers, and collection societies worldwide. A CWR file is a flat text file where every line is a record, and every record begins with a three-character type code that determines its structure and purpose. Records are not standalone. They are grouped into **transactions** -- a new work registration, for example, is a single transaction comprising an NWR record followed by SPU, SPT, SWR, SWT, and PWR records that define its rights holders. Transactions are wrapped in **groups** (GRH/GRT), and the entire file is wrapped in a **header/trailer** pair (HDR/TRL). This nesting structure allows receiving societies to validate file integrity before processing any content. This reference covers the record types you will encounter most frequently. It is not a substitute for the full CISAC CWR specification, but it is sufficient to read a CWR file, understand its structure, and diagnose common validation errors. --- ## File Structure: Header, Group, and Trailer Records Every CWR file follows the same envelope structure: one file header, one or more groups, and one file trailer. These records carry no musical work data -- they exist for routing and integrity validation. ### HDR -- Header First record in every CWR file. Identifies the sender (publisher or administrator), the creation date, the character set (typically ASCII), and the CWR version (2.1 or 2.2). The sender is identified by their society-assigned code and IPI number. If the sender ID is wrong, the entire file may be rejected by the receiving society without further processing. ### GRH -- Group Header Marks the start of a transaction group. Contains the transaction type for every transaction in the group (NWR, REV, etc.) and a sequential group ID. A single CWR file may contain multiple groups, each holding a different transaction type. ### GRT -- Group Trailer Closes a group. Contains the record count and transaction count for the group. Receiving societies use these counts for integrity validation -- if the actual counts do not match the declared counts, the group is rejected. ### TRL -- Trailer Last record in the file. Contains the total record count, group count, and transaction count for the entire file. This is the final integrity check: if the TRL totals do not match the sum of all GRT totals plus the HDR and TRL records themselves, the file is invalid. ### File Structure Example ``` HDR Sender identification, date, CWR version GRH Group 1 begins (transaction type: NWR) NWR New work registration (transaction 1) SPU Publisher record SPT Publisher territory SWR Writer record SWT Writer territory PWR Publisher-writer link GRT Group 1 trailer (counts) TRL File trailer (totals) ``` --- ## Work Registration: NWR and REV The two transaction-level record types that register or update a musical work. ### NWR -- New Work Registration Registers a musical work for the first time. The NWR record is the anchor of the transaction -- all subsequent party and territory records belong to this work until the next NWR or REV. **Key fields:** Work title, Language code, Duration, Version type, Music arrangement code, Lyric adaptation code, Submitter work ID. ### REV -- Revised Registration Updates an existing registration. The REV record has the same structure as NWR but replaces the previous data held by the receiving society. Use REV when correcting errors, adding parties, or updating share splits on an already-registered work. **Key fields:** Same structure as NWR. References the original registration. The **submitter work ID** is the publisher's internal identifier for the work. It must be unique within the sender's catalogue and consistent across submissions -- societies use it to match REV transactions to their original NWR. If you change the submitter work ID between NWR and REV, the society will treat the REV as a new registration and reject it. --- ## Party Records: Publishers, Writers, and Their Territories The records that define who owns what, where, and in what proportions. These records follow the NWR or REV record they belong to. ### Publisher Records #### SPU -- Publisher Identifies a publisher in the ownership chain. Contains the publisher name, IPI name number, and publisher type. The publisher type field is critical -- it distinguishes between the original publisher (who signed the songwriter), the sub-publisher (who administers in a specific territory), and the administrator (who handles registration on behalf of another publisher). #### SPT -- Publisher Territory Specifies the territories where a publisher controls rights and the percentage shares for each right type: performance (PR), mechanical (MR), and synchronisation (SR). A single SPU record may be followed by multiple SPT records if the publisher's shares vary by territory. Territory codes follow the CISAC TIS standard: - `2136` = World - `840` = US - `826` = UK ### Writer Records #### SWR -- Writer Identifies a songwriter, composer, or arranger. Contains the writer's last name and first name (separate fields), their IPI name number, and a writer designation code that defines their role on the work. | Code | Designation | |---|---| | `CA` | Composer/Author (wrote both music and lyrics) | | `C` | Composer (music only) | | `A` | Author (lyrics only) | | `AR` | Arranger | | `AD` | Adaptor (lyric adaptation) | | `SA` | Sub-Arranger | | `SE` | Sub-Author | #### SWT -- Writer Territory Territory-specific share information for writers. Follows the same pattern as SPT: specifies the writer's PR, MR, and SR shares for a given territory. Writers who are members of a society typically assign their performance share to the society, so the PR share in SWT often reflects the society's allocation rules rather than a freely negotiated split. ### Publisher-Writer Link #### PWR -- Publisher for Writer Links a specific publisher (SPU) to a specific writer (SWR) within a work. This record answers the question: "Which publisher administers this writer's share?" A work with two co-writers signed to different publishers will have two PWR records, each connecting one writer to their respective publisher. --- ## Share Arithmetic The single most common source of CWR validation errors is incorrect share totals. Understanding the arithmetic is essential. CWR tracks three independent share types. For each type, the shares across all parties must total exactly **100.00%**. Not 99.99%. Not 100.01%. Exactly 100.00%. ### PR -- Performance (100.00%) Who gets paid when the work is performed publicly -- radio, live, streaming, broadcast. ### MR -- Mechanical (100.00%) Who gets paid when the work is reproduced -- physical copies, downloads, interactive streams. ### SR -- Synchronisation (100.00%) Who gets paid when the work is synchronised to visual media -- film, television, advertising, games. ### Common Errors **Shares summing to 200%.** A frequent mistake with co-published works: each publisher enters 100% for their writer, forgetting that all parties must sum to 100% collectively -- not individually. **Missing writer shares.** The writer's SWT shares plus the publisher's SPT shares for the same right type must together total 100%. If a publisher claims 50% MR but the writer's SWT shows 0% MR, the total is only 50% and the file will be rejected. **Rounding errors.** Shares are expressed to two decimal places. Splitting 100% three ways gives 33.33 + 33.33 + 33.34, not 33.33 + 33.33 + 33.33. The last party absorbs the rounding remainder. The share arithmetic applies independently per territory. A work may have different share splits in different territories (for example, when a sub-publisher administers the work outside the original territory), but in every territory, each right type must still total 100%. --- ## Version Type Codes The version type field in NWR and REV records identifies the nature of the work. This affects how societies process and match the registration. | Code | Version Type | Description | |---|---|---| | `ORI` | Original Work | The first version of a musical work. No prior registration exists. | | `MOD` | Modified Version | A derivative of an existing work -- for example, a remix or adaptation that creates new copyright. | | `ARR` | Arrangement | A new arrangement of a public domain or copyrighted work. Requires music arrangement code. | | `ORI/MOD` | Original + Modified | A work that is both original in its composition and a modification of existing material (rare). | | `UNS` | Unspecified | Version type not determined. Some societies will reject registrations with this code. | The version type has downstream consequences. An **ORI** work can stand alone. A **MOD** or **ARR** work should reference its source -- the original work it derives from -- and must include the appropriate music arrangement code (ORI, ARR, UNS) and lyric adaptation code (ORI, MOD, UNS) to describe what was changed. Societies use these fields to ensure the original rights holders are properly credited and compensated when derivative works generate royalties. --- ## All Record Types at a Glance | Code | Record Type | Category | Purpose | |---|---|---|---| | `HDR` | Header | File structure | File identification and routing | | `GRH` | Group Header | File structure | Transaction group start marker | | `GRT` | Group Trailer | File structure | Group integrity counts | | `TRL` | Trailer | File structure | File integrity totals | | `NWR` | New Work Registration | Work | Register a new musical work | | `REV` | Revised Registration | Work | Update an existing registration | | `SPU` | Publisher | Party | Publisher identification and type | | `SPT` | Publisher Territory | Party | Publisher shares by territory | | `SWR` | Writer | Party | Writer identification and designation | | `SWT` | Writer Territory | Party | Writer shares by territory | | `PWR` | Publisher for Writer | Party | Links publisher to writer | --- ## Validate Your CWR Files TrackForge's CWR Validator checks your files against the CISAC specification -- share arithmetic, record structure, field formatting, and cross-record consistency. Upload a file and get a detailed validation report in seconds. - [Open CWR Validator](https://trackforge.studio/cwr-tool) --- ## Related Documentation - **[CWR Validator Tool](https://trackforge.studio/cwr-tool)** -- Upload and validate CWR files against the CISAC specification. - **[The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy)** -- 4.25 million works with unclaimed US mechanical royalties at the MLC. - **[The Problem](https://trackforge.studio/certification/overview/the-problem)** -- Why music rights data is broken and what TrackForge does about it. - **[What is CWR?](https://trackforge.studio/certification/cwr/what-is-cwr)** -- A complete guide to CWR structure, workflow, and versions. - **[Common CWR Errors](https://trackforge.studio/certification/cwr/common-errors)** -- The most frequent validation failures and how to fix them. --- *Source: [https://trackforge.studio/certification/cwr/record-types](https://trackforge.studio/certification/cwr/record-types)* --- ## certification/cwr/common-errors.md # Common CWR Errors -- How to Fix Validation Issues > The most frequent CWR validation errors, why they happen, and how to fix them before submitting to a society. *Published by [TrackForge](https://trackforge.studio) -- 9 March 2026* --- CWR files are rejected more often than they are accepted on first submission. Most rejections come from a small number of recurring issues. This guide covers each one with examples and fixes. Understanding why CWR files get rejected saves days of back-and-forth with societies. Most rejections stem from a handful of recurring issues -- share arithmetic that doesn't add up, blank fields that should never be blank, and structural mismatches between headers and content. The [TrackForge CWR Validator](https://trackforge.studio/cwr-tool) checks for all of the issues described below before you submit to a society. Catching these errors locally means fewer rejections, faster registrations, and less time spent debugging file formats. This guide covers both CWR 2.1 and 2.2. Where behaviour differs between versions or between receiving societies, we note it explicitly. --- ## 1. Share Arithmetic Errors **Most common rejection reason** Every work in a CWR file carries ownership shares for performance rights (PR), mechanical rights (MR), and synchronisation rights (SR). Each right type must total exactly **100.00%** across all interested parties. If the shares don't add up, the file is rejected. The most frequent variant: two co-writers each claiming 50% performance share, but the publisher shares push the total above 100%. Or a three-way split where the fractions don't land cleanly -- `33.33 + 33.33 + 33.33 = 99.99` -- and the society rejects it for being one hundredth of a percent short. ``` // Two writers, each claiming 60% performance share SPU: Publisher A -- PR: 60.00 MR: 50.00 SR: 50.00 SPU: Publisher B -- PR: 60.00 MR: 50.00 SR: 50.00 // Total PR = 120.00% -> REJECTED ``` **Fix:** Verify that PR, MR, and SR shares each sum to exactly **100.00%** for every work. For three-way splits, use `33.33 + 33.33 + 33.34` to reach 100.00. Some societies are strict about decimal precision to two places -- others accept whole numbers. When in doubt, use two decimal places and ensure arithmetic precision. > **Watch for partial claims:** If a work has territories where not all rights holders are known, the shares for the *known* parties should still reflect correct proportions. A common mistake is leaving MR or SR at 0.00 for a party that does hold those rights, causing the total to fall short of 100%. --- ## 2. Header Record Errors The HDR (header) record is the first line of every CWR file. It identifies who sent the file, what version it conforms to, and when it was created. Errors here cause immediate rejection before the society even looks at your works. **Blank or invalid sender ID.** The sender code in the HDR record must match the code assigned to you by the receiving society. A blank field, a placeholder like `000000000`, or a sender code from a different society will cause rejection. **CWR version mismatch.** The HDR record declares the CWR version (e.g., `02.10` for CWR 2.1, `02.20` for CWR 2.2). If you declare version 2.2 but the file structure uses 2.1 record layouts, the parser will fail on records it doesn't recognise or expects in a different format. **Creation date format.** The creation date must be `YYYYMMDD`. Using `DD/MM/YYYY`, `YYYY-MM-DD`, or any other format causes a parse failure. ``` HDRPB000000000 01 2026-03-09 ... // Sender ID all zeros, date has hyphens -> REJECTED HDRPB123456789 01 20260309 ... // Valid sender ID, correct date format -> OK ``` **Fix:** Confirm your sender ID with each society you submit to -- it is society-specific. Ensure the CWR version in the header matches the actual record format used throughout the file. Use `YYYYMMDD` for all date fields without separators. --- ## 3. Missing or Invalid Identifiers CWR relies on several identifier systems to link works, writers, and publishers across societies. Invalid or missing identifiers are a frequent source of rejections and, worse, silent mismatches where a work gets registered against the wrong entity. | Identifier | Issue | Impact | |---|---|---| | Writer IPI | All zeros or blank | Some societies accept (ASCAP), others reject (PRS, GEMA). Inconsistent behaviour across territories. | | Publisher IPI | Missing or non-numeric | Almost universally rejected. Publishers must have a valid IPI. | | ISWC | Invalid format or check digit | Must match pattern `T-000000000-0`. Invalid check digit = rejected. | | Submitter Work ID | Blank | Rejected. Every work needs your internal reference number. | **Fix:** Look up writer and publisher IPIs via the [CISAC IPI Database](https://ipidb.cisac.org) before generating your CWR file. For ISWCs, validate the check digit algorithmically -- it uses the ISO 7064 Mod 10 algorithm. Never leave the submitter work ID blank; use your internal catalogue reference. > **Writer IPI: the grey area.** If a writer genuinely has no IPI (e.g., a non-society writer on a co-write), some societies accept `00000000000` as a placeholder. Others reject it outright. If you're submitting to multiple societies, get the writer registered for an IPI first. It avoids ambiguity and prevents silent mismatches where two different writers share the same zero-IPI placeholder. --- ## 4. Work Title Issues **Blank work title.** An NWR or REV record with an empty title field is an instant rejection at every society. This usually happens when a CWR generator pulls from a database with null or empty title fields. **Non-ASCII characters.** CWR is a fixed-width text format originally designed for ASCII. Characters like accented vowels (e, u), em-dashes, or smart quotes may cause problems. Some societies handle these gracefully; others reject the entire file. CWR 2.2 is more tolerant than 2.1, but behaviour varies. **Title exceeding field length.** The work title field in CWR has a fixed maximum length (60 characters in CWR 2.1). Titles that exceed this are either truncated silently or cause a parse error, depending on the receiving system. Truncation can create duplicate-detection problems downstream. **Fix:** Validate that every work has a non-empty title. Transliterate or strip non-ASCII characters for CWR 2.1 submissions. For CWR 2.2, confirm the receiving society's character encoding support. Truncate long titles intentionally rather than letting the parser do it -- and include the full title as an alternate title (ALT record) where possible. --- ## 5. Record Count Mismatches CWR files have integrity checks built into their structure. The GRT (group trailer) record states how many records are in the group. The TRL (transmission trailer) states the total record count for the entire file. If these counts don't match the actual number of records, the file is considered structurally corrupt. ``` // Group contains 47 records, but GRT says 45 GRT00001004500000022 <- record count says 45 // Actual records in group: 47 -> REJECTED ``` This error almost always indicates a bug in the CWR generator, not a manual editing mistake. It happens when records are added or removed after the trailer counts were calculated, or when a generator doesn't count header/trailer records consistently. **Fix:** Recount the records programmatically. The GRT record count should include every record in the group (from GRH to GRT inclusive). The TRL total should equal the sum of all records in the file (HDR + all groups + TRL). If you're editing a CWR file by hand, always regenerate the trailer records after making changes. > **Do not hand-edit trailer records.** If your GRT/TRL counts are wrong, do not manually adjust the numbers. Regenerate the entire file from your source data. Manual count adjustments are error-prone and can mask other structural issues (missing records, duplicate sequence numbers) that the miscount was actually signalling. --- ## 6. Writer and Publisher Linkage Issues CWR requires explicit linkage between writers and their publishers via PWR (Publisher for Writer) records. Missing or incorrect linkage is one of the subtler error categories -- the file may pass basic validation but get rejected during processing, or worse, the work gets registered with incomplete ownership data. **Writer last name blank.** The SWR (writer) record requires at minimum a last name. An empty last name field causes rejection even if the IPI is present. **Missing PWR record.** Every controlled writer needs a corresponding PWR record linking them to their publisher. If the PWR is missing, the society cannot determine who administers that writer's share. **Invalid writer role code.** The writer designation code must be one of the CISAC-defined values: `CA` (Composer/Author), `C` (Composer), `A` (Author/Lyricist), `AR` (Arranger), `AD` (Adaptor), `SA` (Sub-Arranger), `SE` (Sub-Author). Using non-standard codes or leaving the field blank causes rejection. **Invalid publisher type.** The SPU (publisher) record requires a valid publisher type code: `E` (Original Publisher), `ES` (Substitute Publisher), `AM` (Administrator), `SE` (Sub-Publisher). An empty or non-standard type code is rejected. **Fix:** For every SWR record with a controlled writer, ensure a corresponding PWR record exists. Populate writer last names from your metadata -- never leave them blank. Use only the CISAC-defined writer designation codes. Validate publisher type codes against the CWR specification for your target version. --- ## 7. Territory and Rights Errors Territory assignments tell societies where your ownership claims apply. Errors in territory records don't always cause outright rejection, but they can result in works being registered for the wrong territories or with incomplete territorial coverage. **Invalid territory code.** CWR uses CISAC TIS territory codes (e.g., `2136` for the United Kingdom, `840` for the United States). Using ISO country codes, ISRC country prefixes, or arbitrary values will cause rejection. **Overlapping territory claims.** If two SPT (publisher territory) records claim the same territory for the same right type, the society will flag a conflict. This often happens when a global claim (`2WL` = worldwide) is followed by specific territory overrides without proper exclusion logic. **Missing SPT/SWT records.** Publisher and writer shares are defined in SPU/SWR records, but territorial applicability requires SPT/SWT records. If you define shares but no territory assignments, the society doesn't know where those shares apply. Some societies default to worldwide; others reject the work entirely. **Fix:** Use CISAC TIS territory codes exclusively. When using a worldwide claim with exclusions, use the inclusion/exclusion indicator (`I` for include, `E` for exclude). Always include at least one SPT record for each publisher and one SWT record for each writer. Validate territory codes against the [CISAC TIS database](https://www.cisac.org). --- ## Best Practices: Clean Submissions Checklist Eight practices that significantly reduce rejection rates. ### 1. Validate locally first Always run your CWR file through a validator before submitting to a society. Catching errors before submission avoids rejection delays and keeps your submission track record clean. ### 2. Start with a test file When working with a new society, submit a single-work test file first. Confirm it is accepted before sending your full catalogue. Each society has quirks not covered by the spec. ### 3. Check the society's CWR version Some societies only accept CWR 2.1. Others support 2.2. A few accept both but process them differently. Confirm before generating your file. Sending a 2.2 file to a 2.1-only society will be rejected. ### 4. Use consistent IPIs Use the same IPI number for a writer or publisher across every submission. Inconsistent IPIs create duplicate entities in society databases, which cause royalty allocation errors that take months to resolve. ### 5. Keep ACK files When a society accepts your submission, they return an ACK (acknowledgment) file. Keep these. They are your proof of registration and contain the society's assigned work ID, which you need for future amendments. ### 6. Use REV for amendments To update a previously registered work, use a REV (revision) transaction, not a new NWR (new work registration). Submitting an NWR for an existing work creates a duplicate that must be manually reconciled. ### 7. Automate share arithmetic Never calculate share totals manually. Build validation into your CWR generation pipeline that rejects any work where PR, MR, or SR shares do not sum to exactly 100.00% before the file is written. ### 8. Document society-specific rules Maintain a reference sheet for each society you submit to: accepted CWR version, character encoding rules, IPI requirements, and any non-standard validation they apply. This saves troubleshooting time on every submission. --- ## Error Summary Table | Error Category | Record Type | Severity | Detection | |---|---|---|---| | Share arithmetic | `SPU / SWR` | Rejection | Automated | | Invalid sender ID | `HDR` | Rejection | Automated | | Version mismatch | `HDR` | Rejection | Automated | | Date format | `HDR` | Rejection | Automated | | Writer IPI zeros | `SWR` | Society-dependent | Automated | | Publisher IPI missing | `SPU` | Rejection | Automated | | Invalid ISWC | `NWR / REV` | Rejection | Automated | | Blank work title | `NWR / REV` | Rejection | Automated | | Non-ASCII characters | `NWR / REV` | Society-dependent | Automated | | Record count mismatch | `GRT / TRL` | Rejection | Automated | | Writer last name blank | `SWR` | Rejection | Automated | | Missing PWR linkage | `PWR` | Rejection | Automated | | Invalid writer role | `SWR` | Rejection | Automated | | Invalid territory code | `SPT / SWT` | Rejection | Automated | | Overlapping territories | `SPT` | Society-dependent | Manual review | | Missing territory records | `SPT / SWT` | Society-dependent | Automated | --- ## Validate Before You Submit The TrackForge CWR Validator checks for every error described on this page -- plus dozens more -- before you submit to any society. Upload your file and get a detailed report in seconds. - [Validate Your CWR File](https://trackforge.studio/cwr-tool) - [Learn About TrackForge](https://trackforge.studio) --- ## Related Documentation - **[CWR Validator Tool](https://trackforge.studio/cwr-tool)** -- Upload and validate your CWR files against the CISAC specification. Free, instant results. - **[CWR Record Types](https://trackforge.studio/certification/cwr/record-types)** -- A complete reference to every record type in CWR 2.1 and 2.2. - **[What is CWR?](https://trackforge.studio/certification/cwr/what-is-cwr)** -- A complete guide to CWR structure, workflow, and versions. --- *Source: [https://trackforge.studio/certification/cwr/common-errors](https://trackforge.studio/certification/cwr/common-errors)* # Certification Documentation --- ## certification/for-catalogue-owners/deliverables.md --- sidebar_position: 1 title: Deliverables description: What catalogue owners receive from TrackForge rating and remediation work. keywords: - deliverables - proof bundle - CWR - evidence packet --- # Deliverables TrackForge deliverables are designed to recover money or prevent specific non-hypothetical harm. ## Rating Deliverables - AAA-D rating event summary. - Leakage summary by taxonomy family and revenue pathway. - Methodology version and methodology hash. - Taxonomy version, workflow version, and jurisdictional scope. - Evidence packet hashes and Merkle root. - OpenTimestamps proof status and proof files where available. - M58 proof bundle: `README.md`, `manifest.json`, `methodology/methodology.json`, and `proof/` JSON files for the rating event, leakage vector, proof wrapper, and snapshot links. ## Remediation Deliverables - CWR files and supporting registration packages. - CSV or Excel worklists. - Evidence briefs for societies and counterparties. - Operator audit notes and provenance references. - Follow-up packages for unresolved or disputed claims. ## Legacy Compatibility Older bundles may include legacy completeness-tier counts or richer chain-of-title files. These are historical diagnostics or enhanced certification artefacts and should not be read as the current certificate-facing rating scale. --- ## certification/for-catalogue-owners/proof-bundle.md --- sidebar_position: 4 title: The Proof Bundle description: A guide to the self-contained certification archive — what it contains, how to use it, and why it matters. keywords: - proof bundle - certification archive - self-contained verification - cryptographic proof package --- # The Proof Bundle The M58 Proof Bundle is a ZIP archive designed to be a **compact, self-contained evidence package** for the current AAA-D rating event. It includes the files needed to verify the rating event, leakage-vector state, snapshot links, and proof manifest. ## What the bundle contains | File / Directory | Description | |-----------------|-------------| | `README.md` | Human-readable verification notes for the bundle. | | `manifest.json` | File inventory with hashes and bundle metadata. | | `proof/rating_event_proof.json` | Proof wrapper for the rating event, including methodology, scope, root/proof state, and hash references. | | `proof/rating_event.json` | Canonical rating event payload: AAA-D rating, methodology version/hash, workflow/taxonomy versions, scope, snapshot reference, agreement-binding summary, ISWC coverage summary, leakage-vector hash, Merkle root, and proof state. | | `proof/leakage_vector.json` | Deterministic leakage-vector projection used by the current M58 rating model. | | `proof/snapshot_links.json` | References from the rating event back to the frozen evidence snapshot and source records. | | `methodology/methodology.json` | Machine-readable methodology artefact and hash pointer for the rating event. Use it with the public [Rating Input & Scoring Schedule](/methodology/rating-input-scoring-schedule) when recomputing the grade. | Older or enhanced certification bundles may also include `chain_of_title.json`, `tracks/`, `merkle_tree.json`, OpenTimestamps `.ots` files, or operator audit trails. Treat those as legacy/enhanced chain-of-title certification artefacts unless the bundle manifest names them as part of the current M58 proof contract. ## Why self-containment matters The Proof Bundle is deliberately designed so that the current rating event can be checked without relying on an informal TrackForge explanation. This matters in several scenarios: - **Catalogue acquisitions** — A buyer's due diligence team can verify the rating certificate without contacting TrackForge or relying on any third-party API. - **Legal disputes** — In litigation, evidence that depends on a third party remaining operational is weaker than evidence that is self-verifying. - **Long-term archival** — Music catalogues are long-lived assets. A proof bundle created today should be verifiable in 20 years, regardless of whether TrackForge is still in business. - **Regulatory compliance** — Some jurisdictions and insurance policies require evidence packages that are independently auditable. ## How to use the bundle ### For catalogue acquisitions When a potential buyer is conducting due diligence on your catalogue, provide the Proof Bundle alongside your standard data room materials. The buyer's team can: 1. Open `proof/rating_event.json` to review the AAA-D rating, methodology version, workflow version, taxonomy version, and declared scope. 2. Open `methodology/methodology.json` to verify the methodology hash tied to that event. 3. Check the agreement-binding and ISWC coverage summaries for PRS/MCPS-scoped works. 4. Open `proof/leakage_vector.json` to see which leakage conditions were active, inactive, or not applicable, and to review the row materiality inputs used by the scoring schedule. 5. Use `manifest.json` to verify the hashes of the proof files. 6. Use `proof/snapshot_links.json` to trace the rating back to the frozen evidence snapshot. 7. Review any enhanced chain-of-title files separately if the bundle includes them. :::tip[Positioning the bundle in a data room] The Proof Bundle is most effective when presented as a supplement to your existing catalogue documentation, not a replacement. Frame it as: "Independent, third-party verification of the metadata, with cryptographic proof of the state at the time of certification." ::: ### For sync licensing clearance When licensing a track for synchronisation (film, TV, advertising), the licensee's clearance team needs confidence in the rights chain. The M58 bundle provides the rating event, leakage vector, PRS/WACD agreement-binding summary where in scope, ISWC coverage summary, and snapshot links. If a richer `chain_of_title.json` is present, use it as the enhanced Business Affairs artefact for writer, IPI, share, and work-registration review. This can significantly speed up clearance by providing an evidence base that the clearance team can independently verify. ### For dispute resolution In a metadata or rights dispute, the Proof Bundle serves as evidence of the metadata state at a specific point in time: - The **blockchain anchor** proves the certification existed at or before the anchored time — it cannot be backdated. - The **rating event JSON** shows exactly what AAA-D rating was issued, under which methodology, scope, workflow, taxonomy, and snapshot. - The **leakage vector** shows which risk conditions drove the rating. - The **snapshot links** show which frozen evidence records supported the event. - The **manifest** shows whether bundle files match their expected hashes. ### For PRO registration The M58 proof bundle is not a PRO registration package. It can show whether PRS/WACD agreement binding and ISWC coverage affected the rating. If the ZIP also includes an enhanced chain-of-title bundle, use that richer artefact as the reference for writer information, IPIs, roles, shares, and registration updates. ## Verification procedure This is the same procedure included in the bundle's `README.md`. It allows independent verification using standard tools. **Step 1.** Open `manifest.json` and confirm the expected files are present. **Step 2.** Hash each bundled file listed in the manifest and compare the result with the manifest hash. **Step 3.** Open `methodology/methodology.json` and confirm the methodology hash/version match the rating event. **Step 4.** Open `proof/rating_event.json` and confirm the rating scale is `TRACKFORGE_AAA_D`, with the expected methodology version, workflow version, taxonomy version, and jurisdictional scope. **Step 5.** Check `agreement_binding_summary` and `iswc_coverage_summary`. For the current M58 model, PRS/SearchWorks WACD agreement binding and ISWC coverage are rating inputs where they are in scope. **Step 6.** Open `proof/leakage_vector.json` and verify that its hash matches the `leakage_vector_hash` referenced by the rating event. **Step 7.** Recompute row scores, catalogue caps, and the final AAA-D rating using the [Rating Input & Scoring Schedule](/methodology/rating-input-scoring-schedule), then compare the result with `proof/rating_event.json`. **Step 8.** Open `proof/rating_event_proof.json` and confirm that the proof wrapper references the same rating event, Merkle root/current root, proof state, and snapshot links. **Step 9.** If OpenTimestamps files or transaction references are present, verify them using the `ots` command-line tool, the OpenTimestamps website, or any blockchain node. :::tip[You do not need to verify everything] For most practical purposes, Steps 1-5 confirm the delivered M58 proof files are internally consistent. OpenTimestamps and enhanced chain-of-title verification add stronger evidence for legal or adversarial contexts when those artefacts are present. ::: ## What's next - **[How to Verify Independently](./verification)** — More detail on each verification method. - **[Re-Certification](./recertification)** — What happens when metadata changes after certification. [^1]: TrackForge currently uses the Bitcoin blockchain via the [OpenTimestamps](https://opentimestamps.org/) protocol. See [Blockchain Anchoring](/methodology/blockchain-anchoring) for implementation details. --- ## certification/for-catalogue-owners/reading-your-certificate.md --- sidebar_position: 2 title: Reading Your Certificate description: How catalogue owners should read a TrackForge AAA-D rating certificate and proof bundle. keywords: - reading certificate - AAA-D rating - proof bundle - methodology hash - jurisdictional scope --- # Reading Your Certificate A TrackForge certificate is a point-in-time rating event. It should tell you what was rated, under which methodology, using which evidence snapshot, and whether the cryptographic proof chain is pending, confirmed, failed, or local-only. ## The Headline Rating The certificate-facing rating is AAA-D. | Rating | How to read it | |---|---| | **AAA-AA** | Clean or near-clean under the declared workflow and scope. | | **A-BBB** | Low to moderate leakage exposure; review active conditions before relying on operational cleanliness. | | **BB-B** | Elevated to high leakage exposure; remediation is material. | | **CCC-C** | Severe to critical leakage exposure; collection pathways are compromised. | | **D** | Failing state under the current methodology. | The rating is scoped. A UK/US certificate should not be read as direct proof that every non-UK/US society record was checked. ## Fields To Check First | Field | Why it matters | |---|---| | Rating scale | Should state `TRACKFORGE_AAA_D` for current certificates. | | Methodology version/hash | Pins the rules used. | | Taxonomy version | Pins the leakage taxonomy used. | | Workflow version | Pins the operational checks performed. | | Jurisdictional scope | States the direct certification scope. | | Snapshot run ID/time | Identifies the frozen run that was rated. | | Agreement-binding summary | Shows whether PRS/MCPS-scoped works are explicitly tied to client WACD agreements or only inferred/assumed. | | ISWC coverage summary | Shows missing or conflicting work identifiers that can affect registration resolution. | | Merkle root | Commits the evidence packet set. | | OTS status | Tells you whether anchoring is pending, confirmed, failed, or local-only. | ## Leakage Summary The leakage summary is the certificate-facing compression of the Results page. The Results page shows the run-scoped findings produced from the ingested catalogue: failure modes, affected assets, evidence, valuation tier, owner entity, and provenance. The rating event translates that detected leakage state into row scores, catalogue caps, and an AAA-D grade. The leakage summary shows which taxonomy families are active and which revenue pathways they affect. It is separate from remediation status. A fixed issue should appear in a later rating event, not silently disappear from the original event. For PRS/MCPS-scoped catalogues, agreement binding deserves special attention. A work can still generate income when it is not explicitly tied to a specific WACD agreement, but that income route may be inferred or assumed rather than agreement-determined. That is a stronger transaction-risk signal than an ordinary metadata gap. ## Legacy Fields You may see legacy completeness-tier fields in historical bundles or compatibility exports. They are retained to preserve old records and API consumers. They are not the current rating scale unless the certificate is explicitly historical and tied to that older methodology. ## Proof State Read proof status literally: - **Pending** means proof has not yet confirmed. - **Confirmed** means the proof is confirmed. - **Failed** means anchoring failed. - **Local-only** means TrackForge recorded a local witness, not an external public timestamp. Do not rely on a pending proof as a confirmed blockchain anchor. ## If You Remediate Remediation does not rewrite the certificate you already have. Once fixes are complete, TrackForge should produce a later rating event with its own snapshot time, hashes, Merkle root, and proof state. --- ## certification/for-catalogue-owners/recertification.md --- sidebar_position: 5 title: "Re-Certification: When & Why" description: What triggers re-certification, how the version chain works, and why previous certifications remain valid. keywords: - re-certification triggers - certification versioning - metadata change handling - certification renewal --- # 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, this track had the stated rating event under the named methodology and evidence snapshot." - **Version 2** certifies: "On 3 March 2026, after a PRO correction, the track had the new stated rating event under its own methodology and evidence snapshot." 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. --- ## certification/for-catalogue-owners/verification.md --- sidebar_position: 3 title: How to Verify Independently description: Three methods for verifying a TrackForge certification — online, from the proof bundle, or from scratch. keywords: - verify certification - independent verification methods - proof bundle verification - self-verification music metadata --- # How to Verify Independently A TrackForge certification is designed to be verifiable by anyone, at any time, without needing to contact or trust TrackForge. This page describes three methods, from simplest to most thorough. ## Method 1: Online verification The quickest way to verify a certificate or rating proof. 1. Go to [trackforge.studio/certification/for-catalogue-owners/verification](https://trackforge.studio/certification/for-catalogue-owners/verification). 2. Paste the `canonical_json` field from your certificate into the input box. 3. The page computes the SHA-256 hash in your browser and checks it against the certification records. For current M58 rating events, Forge also exposes a grade proof endpoint that returns the AAA-D rating proof for the current certification root. Use that when the artefact you need to verify is a catalogue or track grade rather than a legacy canonical track record. :::tip[Your data stays private] The hash is computed entirely in your browser using the Web Crypto API. The canonical JSON is **never transmitted** to TrackForge's servers — only the resulting hash is checked. You can verify this by inspecting the network traffic in your browser's developer tools. ::: **Limitations:** This method relies on TrackForge's verification service being available. For verification that works regardless of TrackForge's operational status, use Method 2 or 3. ## Method 2: From the Proof Bundle The Proof Bundle is a self-contained ZIP archive that includes everything needed for independent verification. This method requires no internet connection and no reliance on TrackForge. ### What you need - The Proof Bundle ZIP file - A SHA-256 tool (built into macOS, Linux, and Windows; also available online) - An OpenTimestamps verifier (optional, for blockchain confirmation) ### Step-by-step **Step 1 — Extract the bundle** Unzip the M58 Proof Bundle. The current compact bundle contains `README.md`, `manifest.json`, `methodology/methodology.json`, `proof/rating_event_proof.json`, `proof/rating_event.json`, `proof/leakage_vector.json`, and `proof/snapshot_links.json`. Older or enhanced certification bundles may also include `catalog_report.json`, `chain_of_title.json`, a `tracks/` directory, `merkle_tree.json`, and a `proofs/` directory. Treat those as legacy/enhanced chain-of-title artefacts unless the manifest says they are part of the current proof contract. **Step 2 — Verify the manifest** Hash each file listed in `manifest.json` and confirm the computed hashes match the manifest. **Step 3 — Open the methodology artefact** Open `methodology/methodology.json` and confirm the methodology version/hash match the rating event and published methodology label. **Step 4 — Open the rating event** Open `proof/rating_event.json`. Confirm the rating scale is `TRACKFORGE_AAA_D`, and check the methodology version/hash, workflow version, taxonomy version, jurisdictional scope, snapshot reference, agreement-binding summary, ISWC coverage summary, leakage-vector hash, Merkle root/current root, and proof state. **Step 5 — Verify the leakage vector** Hash `proof/leakage_vector.json` using the canonicalisation rules for the methodology version and compare the result with the rating event's `leakage_vector_hash`. For current M58 events, the leakage vector also carries the public row materiality inputs used to calculate the grade. Use the [Rating Input & Scoring Schedule](/methodology/rating-input-scoring-schedule) to recompute row risk points, row scores, catalogue caps, and the final AAA-D rating. **Step 6 — Verify the proof wrapper** Open `proof/rating_event_proof.json` and confirm it references the same rating event, root, proof state, and snapshot links as `proof/rating_event.json`. **Step 7 — Follow the snapshot links** Open `proof/snapshot_links.json` to trace the proof back to the frozen evidence snapshot used by the rating workflow. **Step 8 — Verify optional blockchain anchor** If the bundle includes `.ots` files or transaction references, use an OpenTimestamps verifier to confirm that the root is anchored in the blockchain: ```bash # Using the ots command-line tool ots verify proofs/batch_.ots # Or use the online verifier at opentimestamps.org ``` This confirms that the root existed at or before the time recorded in the blockchain block.[^1] ## Method 3: From scratch This method uses no TrackForge tools or files at all. It is the most independent form of verification, suitable for adversarial contexts such as legal disputes. ### What you need - The rating event JSON or legacy `canonical_json` for the subject - The claimed evidence, leakage-vector, and rating-event hashes - The claimed Merkle root/current root and any transaction ID - Any SHA-256 implementation - Access to a blockchain explorer (e.g. blockstream.info, mempool.space) ### Step-by-step 1. **Hash the supplied JSON artefacts** using the canonicalisation rules for the methodology version. Verify the results match the claimed hashes. 2. **If you have the Merkle proof**, walk the proof tree from leaf to root and verify the result matches the claimed `merkle_root`. 3. **Look up the blockchain transaction** using the transaction ID on any blockchain explorer. The transaction's `OP_RETURN` data (via the OpenTimestamps protocol) commits to the Merkle root. 4. **Verify the timestamp.** The blockchain block timestamp proves the data existed at or before that time. Blockchain blocks cannot be backdated. :::tip[Why this matters] This method demonstrates that the certification is not dependent on TrackForge in any way. The cryptographic proofs are based on open standards (SHA-256, Merkle trees, public blockchains, OpenTimestamps). Any competent technical expert can verify them using publicly available tools and a public blockchain — a public ledger that no single party controls. ::: ## Summary of verification methods | Method | Requires TrackForge? | Requires internet? | Technical skill needed | Best for | |--------|---------------------|--------------------|-----------------------|----------| | **Online** | Yes (verification page) | Yes | None | Quick checks | | **From Proof Bundle** | No | No (except blockchain step) | Basic command line | Due diligence, archival | | **From scratch** | No | Yes (blockchain explorer) | Moderate | Legal disputes, adversarial verification | All three methods verify the same underlying cryptographic proof. The difference is in convenience versus independence. ## What's next - **[The Proof Bundle](./proof-bundle)** — Detailed guide to the self-contained verification archive. - **[Rating Input & Scoring Schedule](/methodology/rating-input-scoring-schedule)** — Detailed guide to recomputing the AAA-D grade from rating inputs. - **[Re-Certification](./recertification)** — What happens when certified metadata changes. [^1]: TrackForge currently uses the Bitcoin blockchain via the [OpenTimestamps](https://opentimestamps.org/) protocol. See [Blockchain Anchoring](/methodology/blockchain-anchoring) for implementation details. --- ## certification/for-lawyers/certificate-wording.md --- sidebar_position: 4 title: Certificate Wording & Disclaimer description: Standard wording for TrackForge AAA-D rating certificates and legacy compatibility disclaimers. keywords: - certificate wording - rating disclaimer - AAA-D - methodology hash - process fidelity --- # Certificate Wording & Disclaimer TrackForge certificate wording must describe the current methodology accurately: AAA-D ratings, deterministic leakage state, UK/US direct scope, methodology hashing, Merkle proofs, and OpenTimestamps proof state. ## Standard Rating Disclaimer The following wording is the baseline for current production rating certificates: > This certificate records a TrackForge rating event for the subject identified above. The rating was produced under the stated methodology version, taxonomy version, workflow version, and jurisdictional scope, using the evidence snapshot and rating inputs identified by the hashes shown on this certificate. > > TrackForge certifies process fidelity: that the stated methodology was applied to the stated evidence snapshot at the stated time, and that the resulting rating event is reproducible from those inputs. TrackForge does not certify absolute legal ownership, authorship, entitlement to royalties, or the absence of future corrections, transfers, disputes, or contradictory evidence. > > The current direct certification scope is United Kingdom and United States registration, repertoire, and revenue pathways unless this certificate states otherwise. The certificate does not directly certify non-UK/US society registration state. > > The rating, methodology hash, evidence packet hash, Merkle root, and OpenTimestamps proof state are provided for independent verification. Pending anchoring status should be read as pending, not confirmed. ## Scope-Specific Statement Every certificate should include an explicit scope line: ```text Jurisdictional scope: UK, US ``` If a future methodology version expands direct society coverage, the certificate must name that scope and pin the workflow version that performed it. ## Proof-State Statement The certificate must distinguish: | State | Certificate wording | |---|---| | `pending` | Submitted or awaiting confirmation; not yet confirmed on-chain. | | `confirmed` | OpenTimestamps proof has confirmed blockchain attestation. | | `failed` | Anchoring attempt failed; certificate must not imply blockchain confirmation. | | `not_submitted` | No external timestamp was submitted. | | `local_only` | Local witness only; not a confirmed public blockchain anchor. | ## Legacy Medal Language Historical certificates and compatibility exports may contain Gold/Silver/Bronze/Declared fields. Current certificate wording must label those fields as legacy if they are shown. Acceptable compatibility wording: > Legacy completeness tier: Bronze. This field is retained for historical compatibility and is not the current certificate-facing rating scale. Unacceptable wording: > Bronze-rated certificate under the current methodology. ## Verification Page Statement The public verification page should show: - Rating value and rating scale. - Methodology version and methodology hash. - Taxonomy version and workflow version. - Jurisdictional scope. - Snapshot run ID and snapshot time. - Evidence hash, leakage-vector hash, and Merkle root where available. - OpenTimestamps proof status. - Legacy medal fields only when clearly labelled as legacy diagnostics. ## Do Not Rewrite Historical Certificates Historical certificates should not be rewritten. They should remain attached to their original methodology and wording. If a catalogue is re-rated under the current methodology, TrackForge should issue a new methodology-versioned rating event that supersedes the historical certificate for current reliance purposes. --- ## certification/for-lawyers/certification-scope.md --- sidebar_position: 1 title: Scope & Legal Positioning description: What a TrackForge rating certificate asserts, what it does not assert, and the current UK/US jurisdictional scope. keywords: - certification scope - legal positioning - UK US scope - process fidelity - rating independence --- # Scope & Legal Positioning TrackForge certification is a process-fidelity and evidence-snapshot attestation. It records that a defined methodology was applied to a frozen evidence snapshot and produced the stated rating event at the stated time. It is not a legal opinion, title guarantee, or promise that no future contradictory evidence can emerge. ## What TrackForge Certifies Each production rating certificate identifies: - The rated subject: catalogue, track, or both. - The AAA-D rating. - The methodology version and methodology hash. - The taxonomy version and workflow version. - The declared jurisdictional scope. - The snapshot time and run ID. - Evidence packet hash or rating input hash. - Merkle root and OpenTimestamps proof state. The certificate asserts that the rating event was produced under that contract. It does not ask the reader to trust a mutable web page or an undocumented scoring process. ## Current Direct Jurisdictional Scope The current direct certification scope is **United Kingdom and United States** registration, repertoire, and revenue pathways. This means TrackForge may assess, where evidence is available and the workflow requires it: - UK composition pathways including PRS/MCPS-related evidence. - PRS/SearchWorks WACD agreement binding, including whether works are explicitly tied to client agreements rather than relying on inferred or assumed claim routes. - Authoritative ISWC coverage and conflicts where they affect work identity or registration resolution. - US composition pathways including MLC and PRO-related evidence. - UK and US neighbouring-rights diagnostics where they affect the declared workflow. - Cross-border consequences of UK/US defects. The current certificate does **not** directly certify French, German, Japanese, or other non-UK/US society registration state. Future society-specific expansion belongs in roadmap or future methodology-version language until it is implemented, versioned, and anchored. ## What TrackForge Does Not Certify TrackForge certification does not assert: 1. **Legal ownership** - It does not establish ownership of copyright, neighbouring rights, or any other intellectual property right. 2. **Definitive writer splits** - It does not state that shares are legally settled or dispute-free. 3. **Global society coverage** - It does not claim direct validation of every society outside the declared scope. 4. **Future absence of contradictions** - It does not guarantee that later evidence, transfers, or corrections will not change the state. 5. **Upstream database perfection** - It does not warrant that external source databases are complete or error-free. 6. **Legal advice** - It is not a substitute for formal legal due diligence. ## Process Fidelity The legal value of a TrackForge certificate is that it is repeatable and independently verifiable. A lawyer or auditor can inspect the methodology artefact, recompute hashes, verify the Merkle proof, and check the OpenTimestamps proof state. If a later remediation fixes a leakage condition, the correct output is a later rating event. The earlier certificate remains a true record of the earlier snapshot. ## Reliance Posture Reliance should always be tied to: - The methodology version. - The declared scope. - The proof state. - Whether the rating is production-certified, pending anchoring, local-only, or withheld. Pending means pending. Confirmed means confirmed. A certificate should not blur those states. --- ## certification/for-lawyers/conflicting-certifications.md --- sidebar_position: 5 title: Conflicting Certifications Policy description: How TrackForge handles the situation where two certifications for the same ISRC contain different metadata. keywords: - conflicting certifications - ISRC metadata conflict - certification dispute policy --- # 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 a public 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. ::: --- ## certification/for-lawyers/data-handling-gdpr.md --- sidebar_position: 7 title: Data Handling & GDPR description: Data handling principles for TrackForge rating evidence and proof bundles. keywords: - GDPR - data handling - evidence packet - proof bundle --- # Data Handling & GDPR TrackForge proof design minimises personal data exposure. Public blockchain records contain hash commitments, not catalogue metadata, writer data, or personal information. ## Data Categories - Catalogue metadata supplied by the owner. - Reference evidence needed for UK/US workflow checks. - Evidence packet hashes and Merkle roots. - Rating event metadata. - Operator evidence where required for remediation or proof. ## Public Proofs OpenTimestamps proofs record cryptographic commitments only. The blockchain does not contain track titles, writer names, IPI numbers, catalogue names, or ownership shares. ## External Sources External source consultation is documented as part of the workflow and evidence provenance. Source use must be described according to the actual workflow version used, not roadmap ambition. --- ## certification/for-lawyers/liability-risk.md --- sidebar_position: 5 title: Liability & Risk Boundaries description: Liability boundaries for TrackForge rating certificates. keywords: - liability - risk - process fidelity - legal disclaimer --- # Liability & Risk Boundaries TrackForge certification is a process-fidelity statement, not a legal ownership guarantee. ## Core Boundary The certificate records that the stated methodology was applied to the stated evidence snapshot. It does not state that all upstream sources are complete, that no future claimant exists, or that every society in the world has been directly checked. ## Foreseeable Risks | Risk | Boundary | |---|---| | Upstream source error | Certification records the process and evidence available at the time. | | Later transfer or correction | Later changes require a later rating event. | | Out-of-scope society issue | Current direct certification scope is UK/US unless stated otherwise. | | Legal ownership dispute | Certificate is not a legal opinion or title guarantee. | | Pending proof state | Pending anchoring must not be treated as confirmed. | ## Reliance Reliance should be based on the methodology version, jurisdictional scope, evidence snapshot, proof state, and any explicit limitations on the certificate. --- ## certification/for-lawyers/rating-independence.md --- sidebar_position: 6 title: Rating Independence description: How TrackForge keeps evidence production, remediation, and deterministic rating separate. keywords: - rating independence - Chinese Wall architecture - methodology hash - conflict of interest - deterministic rating --- # Rating Independence TrackForge may both identify/fix royalty leakage and rate catalogue state. That creates an obvious conflict risk: the same organisation that improves the data must not be able to soften the rating methodology after the fact. TrackForge addresses that risk with architecture, not trust language. ## Separation Model ```mermaid flowchart TB A["Evidence / Remediation Services"] --> B["Frozen Evidence Snapshot"] B --> C["Read-Only Rating Boundary"] D["Published Methodology Hash"] --> C E["Taxonomy + Workflow Versions"] --> C C --> F["Deterministic Rating Event"] F --> G["Proof Bundle"] ``` Evidence-producing services can write operational data. Rating services consume frozen snapshots and methodology artefacts. A rating event is a deterministic output pinned to its inputs. ## Independence Controls | Control | Purpose | |---|---| | Methodology versioning | Every rating states the ruleset used. | | Methodology hash | Any change to rules, thresholds, or disclosure changes the hash. | | Frozen evidence packets | Rating inputs are point-in-time snapshots, not live mutable rows. | | Read-only rating boundary | Rating logic reads snapshots and emits events; it does not modify evidence. | | Agreement and ISWC inputs | PRS/WACD agreement-binding state and ISWC coverage are assessed from frozen evidence, not adjusted during rating. | | Merkle proofs | Track evidence packets are committed to a root hash. | | OpenTimestamps | Methodology and/or evidence roots can be independently timestamped. | ## What An Auditor Can Verify An auditor should be able to: 1. Recompute the methodology hash from the published methodology artefact. 2. Recompute evidence packet hashes from canonical JSON. 3. Rebuild the Merkle root from the committed packet hashes. 4. Confirm the rating event references the same run, scope, methodology hash, and Merkle root. 5. Verify OpenTimestamps proof files where the proof state is confirmed. 6. Confirm any pending or local-only proof state is not presented as confirmed. ## No Per-Client Rating Overrides Rating criteria must be global for a methodology version. A client can remediate problems and receive a later rating event, but TrackForge should not adjust thresholds, waive leakage conditions, or relabel workflow failures as lower ratings for a specific client. ## Legacy Compatibility Older code paths still expose completeness and assurance language from earlier rating models. During migration, those fields are compatibility diagnostics. They should not be used as the certificate-facing public rating vocabulary unless the certificate is explicitly historical and bound to that historical methodology. ## Governance Methodology changes create new versions. Historical ratings remain tied to the methodology hash in effect when they were issued. Comparisons across methodology versions require a bridge note explaining what changed. --- ## certification/glossary.md --- sidebar_position: 99 title: Glossary description: Definitions of key terms used throughout the TrackForge rating and certification documentation. keywords: - music industry glossary - ISRC ISWC IPI - rating event - leakage taxonomy --- # Glossary ### AAA-D Rating The current TrackForge certificate-facing rating scale. It expresses active royalty-leakage exposure under the declared methodology, taxonomy, workflow, and jurisdictional scope. ### Blockchain Anchor An independently verifiable timestamp proof, currently produced through OpenTimestamps where available. A confirmed anchor means the proof has confirmed; pending and local-only states must not be presented as confirmed. ### Canonical JSON A deterministic JSON representation using sorted keys, compact separators, ASCII-safe encoding, and UTF-8 hashing. Canonical JSON lets independent verifiers reproduce evidence and rating hashes. ### Chinese Wall The separation between evidence/remediation services and rating services. Evidence can be assembled and remediated; rating consumes frozen snapshots and emits deterministic events. ### Evidence Packet A frozen JSON snapshot containing the evidence needed by the methodology. Its hash becomes a Merkle leaf or rating input. ### ISRC International Standard Recording Code. A 12-character identifier for a specific sound recording. ### ISWC International Standard Musical Work Code. An identifier for the underlying musical work. ### IPI Interested Party Information number. A rights-holder identifier used by societies and CISAC-linked systems. ### Jurisdictional Scope The direct territory and society pathway scope of a rating event. The current direct TrackForge certification scope is UK and US unless a certificate states otherwise. ### Leakage Taxonomy The versioned set of royalty-leakage conditions that TrackForge tests. Rating state is projected from this taxonomy. ### Leakage Vector A deterministic list of taxonomy conditions and their states: active, inactive, or not applicable. It is separate from remediation status and operator review status. ### Legacy Completeness Tier Historical Gold/Silver/Bronze/Declared fields retained for compatibility. They are not the current certificate-facing rating scale unless a historical certificate explicitly uses that old methodology. ### Merkle Proof A compact inclusion proof showing that a leaf hash belongs to a Merkle tree with a stated root. ### Merkle Root The single root hash committing a set of evidence packet hashes or other methodology-defined leaves. ### Methodology Hash The SHA-256 hash of the methodology artefact or preimage used for a rating. It proves which rules governed the event. ### OpenTimestamps An open protocol for timestamping hash commitments using calendar servers and public blockchain attestations. ### Process Fidelity The core certification claim: TrackForge followed the stated methodology on the stated evidence snapshot at the stated time. It is not a legal ownership guarantee. ### Rating Event The immutable record of a subject's rating under a specific methodology version, taxonomy version, workflow version, jurisdictional scope, evidence snapshot, and proof state. ### Workflow Version The version of the operational checks performed before rating. Workflow version defines what the system directly checked; it is not the same as roadmap scope. --- ## certification/methodology/blockchain-anchoring.md --- sidebar_position: 6 title: Blockchain Anchoring description: How the Merkle root hash is anchored to a public blockchain via the OpenTimestamps protocol, creating a permanent and independently verifiable timestamp. keywords: - blockchain anchoring - OpenTimestamps - Bitcoin timestamp - immutable timestamp - blockchain verification - music metadata blockchain faq: - q: "Why does TrackForge anchor certifications to a blockchain?" a: "A blockchain timestamp creates a permanent, tamper-proof record that a specific hash existed at a specific time. Unlike a PDF report that can be backdated, a blockchain record is independently verifiable by anyone and cannot be altered or deleted. TrackForge uses Bitcoin via OpenTimestamps as it is the most widely distributed and longest-running public blockchain." - q: "What exactly is recorded on the blockchain?" a: "Only the Merkle root hash — a 64-character string — is recorded, not any catalogue data. This single hash cryptographically commits to every track in the certification batch. The actual metadata stays private; the blockchain provides only the timestamp proof." --- # Blockchain Anchoring :::info[Methodology Version] Methodology Version 1.1 - Effective May 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 a **public 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. :::note[Implementation] TrackForge currently uses the Bitcoin blockchain via the OpenTimestamps protocol. The properties described on this page — immutability, independence, transparency, cost efficiency — are properties of the blockchain verification approach. The technical pages reference Bitcoin specifically where the implementation details require it. ::: ## The OpenTimestamps protocol OpenTimestamps is an open protocol for creating timestamps backed by a blockchain. The process works as follows: ### Current implementation 1. **Submission** — The Merkle root or methodology hash is first decoded from its 64-character hexadecimal form to 32 bytes, then committed to OpenTimestamps as the SHA-256 digest of those bytes. This matches the backend anchoring implementation. 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 blockchain verification? | Property | Significance for certification | |:--|:--| | **Immutability** | Once confirmed in a block, blockchain transactions cannot be altered, reversed, or deleted. The timestamp is permanent for as long as the blockchain network exists. | | **Independence** | Verification does not require TrackForge to exist or to cooperate. Any party with access to a blockchain node or a public blockchain explorer can confirm the anchor. | | **Transparency** | The 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 blockchain transaction covers an entire catalogue batch — regardless of whether it contains 10 tracks or 100,000 tracks. | | **Decentralisation** | No single entity controls the blockchain. The timestamp does not depend on the continued operation of any single company, government, or institution. | TrackForge selected the Bitcoin blockchain for these properties due to its maturity, security track record, and the availability of the OpenTimestamps protocol. ## What is recorded on the blockchain The blockchain anchor contains **only a hash commitment derived from the Merkle root or methodology hash**. 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 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 | | **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 blockchain transaction ID (once confirmed) | | **Block number** | The 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 --- ## certification/methodology/canonicalization.md --- sidebar_position: 4 title: Canonicalisation description: How TrackForge prepares deterministic evidence and rating JSON for hashing. keywords: - canonicalisation - canonical JSON - evidence packet - rating event --- # Canonicalisation Canonicalisation turns evidence packets, leakage vectors, and rating events into deterministic JSON. Deterministic JSON is required because the same input must always produce the same hash. TrackForge uses sorted keys, compact separators, ASCII-safe output, and UTF-8 encoding before hashing. Canonicalisation applies to: - Evidence packet JSON. - Leakage vector JSON. - Rating event JSON. - Legacy certification records where historical verification requires them. See [Canonical JSON Schema](/technical/canonical-json-schema) for the byte-level rules. --- ## certification/methodology/enrichment-validation.md --- sidebar_position: 2 title: Evidence Assembly & Leakage Projection description: How TrackForge assembles source evidence, freezes it into evidence packets, and projects deterministic leakage taxonomy state. keywords: - leakage taxonomy - evidence packet - royalty leakage - UK US certification scope - deterministic rating --- # Evidence Assembly & Leakage Projection :::info[Current Methodology Direction] TrackForge ratings are leakage-taxonomy led. Source evidence is an input to the assessment; source-agreement scoring is not the rating driver. ::: Before a catalogue or track can receive a certificate-facing AAA-D rating, TrackForge freezes a deterministic evidence snapshot and projects that snapshot into the revenue leakage taxonomy. For catalogue workflows, this starts from the ingested-catalog results: the run-scoped findings shown on the `/results` page are the operational expression of the detected leakage taxonomy state. ## Evidence Inputs The current workflow uses available TrackForge data-lake and reference inputs for the declared UK/US scope, including sources such as: - Catalogue owner metadata and entity mapping. - Discogs and Spotify metadata where useful for identity and release context. - PRS/SearchWorks WACD work, agreement, chain-of-title, and ISWC data for UK composition pathways. - PRS/MCPS client agreement registry data where the workflow needs to distinguish agreement-bound claims from inferred or assumed claims. - MLC repertoire data for US composition pathways. - Additional PRO data where operationally available. - SoundExchange and PPL-related data for neighbouring-rights diagnostics. - ACE/GAP-style repertoire data, Companies House data, and other reference inputs. - Recovery findings, remediation state, valuation inputs, and operator evidence. These sources do not form a public "waterfall" whose depth directly determines the rating. They supply evidence. The rating is computed from the leakage conditions that remain active under the declared methodology, as captured in run-scoped findings and the sealed evidence snapshot. ## Leakage State For each taxonomy item, the workflow determines whether the condition is: | State | Meaning | |---|---| | `active` | The leakage condition exists in the frozen evidence snapshot. | | `inactive` | The condition was tested and is not present. | | `not_applicable` | The condition is outside the subject's rights, pathway, or declared scope. | This state is deterministic. It is separate from: - **Revenue exposure** - the value or pathway affected by the condition. - **Remediation status** - whether a fix has been queued, waived, resolved, or superseded. - **Review status** - operator workflow state. A later remediation creates a later rating event. It does not mutate the original event. ## Results-Page Findings The Results page is not a separate narrative report. It is the catalogue's detected leakage state after ingestion and workflow execution. Each finding carries a failure-mode identifier, status, asset, evidence, value tier, provenance, and valuation method where available. Those findings are grouped in the UI by taxonomy mode, industry category, artist, owner entity, urgency, and value tier. M58 v1.1 treats those findings as the primary leakage-taxonomy input. The rating event then adds sale-diligence signals that may not always be ordinary leakage findings, including agreement binding, ISWC coverage, missing ISRCs, and unmatched population rows. ## Mandatory UK Composition Signals Where PRS/MCPS scope is part of the workflow, the evidence projection must account for: - **Agreement binding** - whether the work is explicitly tied to a specific PRS/SearchWorks WACD agreement for the client's account. - **Claim basis** - whether the frozen evidence supports a determined/derived agreement-backed claim or only an inferred/assumed route. - **ISWC coverage** - whether a valid authoritative ISWC is present, missing, conflicting, or unresolved. An unbound work is not automatically unpaid, but it is a real leakage-risk condition because it weakens chain-of-title certainty and increases the chance of dispute, counterclaim, or manual society resolution. ISWC gaps are also rating inputs because they weaken work identity and cross-society registration resolution. ## Current Direct Scope The current direct certification methodology checks UK and US registration, repertoire, and revenue pathways. It is valid to state that defects in these pathways may propagate into other territories. It is not valid to claim that the current certificate directly checked every global society. Candidate future expansions belong in roadmap language until they are operationally implemented, versioned, and anchored. ## Workflow Failure Is Not A Lower Rating If a required step inside the declared workflow fails, the result should be withheld, marked not-rateable, or surfaced as an operational failure. It should not be converted into a lower AAA-D rating. Ratings measure leakage state under a completed workflow, not partial execution quality. ## Rating Independence Evidence assembly and rating remain structurally separated. Evidence-producing services can write operational data. Rating code reads frozen snapshots and emits deterministic rating events. Methodology versions, hashes, evidence packet hashes, Merkle roots, and proof states bind the output to the exact rules and evidence used. ## Related Pages - **[Rating Methodology (AAA-D)](./golden-record-selection)** - The current scoring recipe. - **[Canonicalisation](./canonicalization)** - How evidence is serialised for hashing. - **[Rating Independence](/for-lawyers/rating-independence)** - The Chinese-wall model. --- ## certification/methodology/golden-record-selection.md --- sidebar_position: 1 title: Rating Methodology (AAA-D) description: How TrackForge M58 v1.1 catalogue and track ratings are calculated from the leakage taxonomy, agreement binding, ISWC coverage, population defects, and proof hashes. keywords: - AAA-D rating - TrackForge rating methodology - leakage taxonomy - deterministic leakage vector - agreement binding - ISWC coverage --- # Rating Methodology (AAA-D) :::note[Legacy URL] This page keeps its historical slug for backwards-compatible links. The current public methodology is AAA-D and leakage-taxonomy led. Gold/Silver/Bronze/Declared are legacy compatibility fields, not the current certificate-facing rating scale. ::: TrackForge rates catalogue and track state using an institutionally recognisable **AAA-D** scale. The rating expresses active royalty-leakage exposure under the declared methodology version, workflow version, taxonomy version, and jurisdictional scope. The current public methodology label for the M58 grading/certification slice is **methodology v1.1**. ## Short Version A rating is made by applying a fixed scoring model to a frozen catalogue population: 1. Freeze the original ingested catalogue population. 2. Read the results-page findings for that population. 3. Attach the evidence available for each population row. 4. Project each row into deterministic leakage state. 5. Apply risk-point penalties for active failure-mode findings, agreement-binding risk, ISWC risk, and population defects. 6. Average the row scores. 7. Apply catalogue-level caps where a defect is too material to be averaged away. 8. Map the final score to AAA-D. 9. Hash the rating input, leakage vector, methodology artefact, and proof root. The purpose of the rating is not to reward attractive metadata. It is to measure how much of the catalogue population can be relied on for collection, sale diligence, and remediation under the declared workflow. For the recomputable public scoring contract, see [Rating Input & Scoring Schedule](./rating-input-scoring-schedule). That page is the detailed schedule for row inputs, risk points, catalogue caps, threshold lookup, and verification requirements. ## Population Denominator Catalogue-sale diligence begins with the **original ingested catalogue population** where that population is available. Every in-scope uploaded track remains in the denominator, even if it is later cleaned, matched, remediated, or found to be orphaned. This rule matters because a cleaned subset can make a distressed catalogue look better than it is. A track with no ISRC, no matched evidence snapshot, no work identity, or no registration evidence is itself a rating fact. It is not removed from the denominator because the workflow could not enrich it. When an original intake population was not persisted for a historical or non-production event, the model falls back to the sealed evidence snapshot set. Current M58 production events should identify which population source was used. ## From Results Page To Rating The `/results` page is the operational view of the ingested catalogue analysis. It is built from run-scoped `recovery.findings` rows. Those rows carry the failure mode, description, asset type, asset identifier, owner entity, value tier, valuation method, provenance, and enrichment evidence for each detected leakage condition. The rating is a deterministic translation of that results state into an institutional grade. The results page answers: **what problems did the catalogue analysis find?** The rating answers: **given those problems, the population denominator, and the sale-diligence rules, what grade does this catalogue deserve?** The leakage findings on the results page are therefore the primary taxonomy input to the grade. M58 v1.1 also adds registration and diligence signals that are not always represented as ordinary leakage findings: - PRS/SearchWorks WACD agreement binding. - ISWC missing/conflict coverage. - Population defects such as missing ISRCs or population rows with no matched sealed snapshot. These additional signals exist because a catalogue can carry serious transaction risk even where income is still being received. Inferred PRS income, for example, may still pay, but it is weaker than agreement-determined income for sale diligence. ## Relationship To The Revenue Leakage Taxonomy TrackForge maintains a revenue leakage taxonomy: named failure modes across the music royalty value chain. The public taxonomy families are: | Stage | Family | Examples of leakage conditions | |---|---|---| | 1 | Creation | ownership complexity, ghost contributions, sample or interpolation clearance gaps | | 2 | Recording | missing ISRC, duplicate ISRC, conflicting recording identity | | 3 | Rights assignment | missing assignments, conflicting publisher/writer shares, transfer ambiguity | | 4 | Work registration | missing work registration, missing ISWC, wrong shares, territory or agreement defects | | 5 | Recording-to-work linkage | missing or wrong ISRC-to-work link, tunecode mismatch, work/recording contamination | | 6 | Distribution | delivery gaps, DSP metadata divergence, unavailable or mismatched release data | | 7 | Consumption / usage | unreported or misclassified usage signals | | 8 | Usage reporting | usage files missing identifiers, bundled reports, poor statement granularity | | 9 | Matching & allocation | black-box allocation, MLC absence, SoundExchange absence, MCPS drain-clock exposure | | 10 | Royalty calculation | wrong rates, currency conversion errors, deductions or threshold issues | | 11 | Payment distribution | payment to wrong entity, defunct payment path, retained income | | 12 | Reconciliation & audit | unaudited catalogue state, time-barred claims, insufficient evidence | The full taxonomy is broader than any single rating workflow. M58 v1.1 is the current UK/US catalogue-sale diligence workflow. It consumes the active findings and evidence available under that workflow, then records the deterministic projection in the leakage vector. The public results page groups findings into industry-facing categories such as Ghost Tracks, Unclaimed Royalties, Unregistered Works, Rights Chain Issues, Distribution & Delivery, Linkage Failures, Data Quality, and Payment Leakage. Underneath those categories are the `RL-*`, `XD-*`, `DL-*`, and `PO-*` failure-mode identifiers used by the taxonomy. In the compact M58 proof bundle, the production leakage vector currently records one row-risk item per rated catalogue population row. That item carries the active finding count, severity counts, agreement-binding state, ISWC state, population flags, evidence references, and remediation pointer for that row. Where a richer export includes individual `RL-*` finding identifiers, those identifiers explain the underlying taxonomy conditions that contributed to the row risk. ## Leakage Vector Each leakage-vector item has a stable shape: ```json { "taxonomy_item_id": "M58-CATALOGUE-TRACK-RISK", "state": "active | inactive | not_applicable", "affected_revenue_pathway": "uk_us_collection", "affected_right_type": "composition_and_recording", "evidence_references": ["..."], "materiality_inputs": {}, "remediation_pointer": "..." } ``` The vector is ordered, canonicalised, and hashed. The hash is stored as `leakage_vector_hash` in the rating event. Any change to an active condition, evidence reference, materiality input, or remediation pointer changes the hash. ## Per-Track / Per-Row Risk Points Each rated population row starts at 100. Risk points are added from the active evidence state and then capped at 100. The row score is: ```text row_score = max(0, 100 - min(total_risk_points, 100)) ``` Current M58 v1.1 risk points: | Input | State | Risk points | |---|---:|---:| | Active finding severity | critical finding | 22 each, up to 3 per row | | Active finding severity | high finding | 13 each, up to 3 per row | | Active finding severity | medium finding | 6 each, up to 3 per row | | Active finding severity | low finding | 2 each, up to 3 per row | | Agreement binding | agreement-bound | 0 | | Agreement binding | inferred or assumed | 18 | | Agreement binding | missing or conflicting | 35 | | ISWC coverage | present | 0 | | ISWC coverage | missing | 10 | | ISWC coverage | conflicting | 20 | | Population integrity | missing ISRC | 28 | | Population integrity | no matched evidence snapshot | 30 | | Population integrity | duplicate ISRC in population | 8 | | Population integrity | missing title | 6 | | Population integrity | missing work identity | 10 | The active-finding severity inputs come from the evidence snapshot's finding summary, which is derived from the results-page leakage findings for the current run. Agreement, ISWC, and population-integrity inputs are recomputed directly from the frozen population and source evidence used by the rating event. The full public scoring schedule is published in [Rating Input & Scoring Schedule](./rating-input-scoring-schedule). ## Catalogue Aggregation The raw catalogue score is the arithmetic average of the row scores across the rating denominator: ```text raw_catalogue_score = sum(row_score) / rated_population_count ``` The model then applies cap rules. Caps prevent a catalogue with a severe structural defect from receiving a high grade merely because the rest of the population looks clean. Current M58 v1.1 catalogue caps: | Condition | Maximum score | |---|---:| | Any critical active finding exists | 72 | | Any missing or conflicting agreement binding exists | 82 | | Any inferred or assumed agreement binding exists | 90 | | Zero agreement-bound works and any agreement risk exists | 72 | | Agreement-risk rows are at least 25% of the population | 82 | | Missing/conflicting agreement rows are at least 25% of the population | 40 | | Original population is used, zero agreement-bound works, and agreement risk exists | 40 | | Any ISWC conflict exists | 82 | | Any missing ISWC exists | 90 | | ISWC-risk rows are at least 25% of the population | 82 | | Missing ISWCs are at least 50% of the population | 40 | | Missing ISRCs are at least 10% of the population | 40 | | Unmatched population rows are at least 10% of the population | 40 | The final numeric score is the lower of the raw average and every applicable cap. ## Numeric Score To AAA-D | Minimum final score | Rating | |---:|---| | 95 | AAA | | 90 | AA | | 82 | A | | 72 | BBB | | 62 | BB | | 52 | B | | 40 | CCC | | 30 | CC | | 20 | C | | 0 | D | ## Rating Definitions | Rating | Current meaning | |---|---| | **AAA** | No active leakage conditions under the current workflow and scope; identity, rights, and registration state are clean against the current taxonomy and evidence snapshot. | | **AA** | No material active leakage; minor remediable or informational issues may exist but do not presently create meaningful leakage exposure under the current scope. | | **A** | Low leakage exposure; limited active leakage conditions or data defects with bounded operational impact. | | **BBB** | Moderate leakage exposure; active leakage conditions exist and should be remediated before the catalogue is represented as operationally clean. | | **BB** | Elevated leakage exposure; multiple active leakage conditions, material registration defects, or unresolved rights/identity problems affect revenue pathways. | | **B** | High leakage exposure; broad or severe leakage across one or more material revenue pathways. | | **CCC** | Severe to critical leakage exposure; catalogue or track state is materially compromised under the current workflow. | | **CC** | Critical leakage exposure; collection pathways are significantly broken or structurally unsafe for certification as clean. | | **C** | Near-failing state; pervasive active leakage or missing rights/registration state in material pathways. | | **D** | Failing state under the current methodology; cannot be represented as materially collection-ready. | ## Agreement Binding And ISWC Coverage For UK composition pathways, TrackForge treats PRS/SearchWorks WACD agreement binding as a rating input. A work can still receive revenue when the publisher claim is not explicitly tied to a specific agreement, but that revenue path is weaker: the claim is more vulnerable to dispute, counterclaim, and manual back-and-forth than a work bound to the relevant PRS/ICE agreement record. The rating methodology distinguishes: - **Agreement-bound works** - the track/work is tied to the relevant society-assigned agreement identifier in the client's PRS/WACD account. - **Unbound or inferred works** - the work has ownership or income signals, but no explicit agreement binding in the frozen evidence snapshot. - **Missing or conflicting works** - the work has no reliable agreement route or has evidence that contradicts the expected client account path. - **Not applicable** - agreement binding is outside the declared rights, society, or workflow scope for that subject. ISWC coverage is also a rating input. Missing, conflicting, or weak ISWC evidence reduces the ability to resolve the registered composition, cross-reference society records, and support downstream registrations or corrections. The impact is methodology-versioned so a small number of low-value unresolved identifiers cannot be averaged together with severe agreement-binding gaps. ## Failure Rates And Summaries A rating event should expose both counts and rates. For example: - Agreement binding: bound, inferred/assumed, missing/conflicting, not applicable. - ISWC coverage: present, missing, conflicting, not applicable. - Leakage state: active, inactive, not applicable. - Taxonomy family counts where individual `RL-*` findings are available. - Population integrity: missing ISRC, unmatched snapshot, duplicate ISRC, missing work identity. Counts show scale. Rates show materiality. A catalogue with 10 missing ISWCs out of 50 tracks carries a different risk profile from 10 missing ISWCs out of 10,000 tracks. The cap rules above are the current public mechanism for turning material failure rates into grade ceilings. ## Proof And Reproducibility Every M58 rating event records: - `methodology_version` and `methodology_hash`. - `taxonomy_version` and `workflow_version`. - `rating_input_hash`. - `leakage_vector_hash`. - `agreement_binding_summary`. - `iswc_coverage_summary`. - snapshot run and snapshot time. - Merkle root / current root and OpenTimestamps proof state where applicable. The rating input hash binds the final grade to the exact methodology, scope, population-derived leakage vector, row materiality inputs, summary counts, and proof references. The Merkle/root proof binds the sealed evidence snapshots used by the rating workflow. Where a population row has no matched sealed snapshot, that absence is not hidden: it appears as population risk in the leakage vector and affects the rating. ## Legacy Medal Tiers Historical TrackForge systems used Gold/Silver/Bronze/Declared as metadata-completeness labels. Those labels may still appear in: - Historical certificates. - Legacy API fields such as tier counts. - Internal diagnostics while systems are migrated. They must be labelled as legacy when shown beside current rating output. They do not define the current certificate-facing methodology. ## Track And Catalogue Ratings Track-level output can expose both the track's leakage vector and, where implemented, its AAA-D rating. Catalogue-level output aggregates track and pathway state under the published methodology rules. Historical ratings remain bound to the methodology version and hash used when they were produced. ## Not-Rateable States A failed or incomplete workflow is not a lower rating. If required evidence steps did not complete, the output should be withheld or marked not-rateable until the declared workflow has run successfully. --- ## certification/methodology/rating-input-scoring-schedule.md --- sidebar_position: 2 title: Rating Input & Scoring Schedule description: The public M58 v1.1 scoring contract for recomputing TrackForge AAA-D catalogue and track ratings from certified rating inputs. keywords: - rating input - scoring schedule - M58 v1.1 - AAA-D rating - catalogue rating - leakage taxonomy - PRS agreement binding - ISWC coverage --- # Rating Input & Scoring Schedule This page is the public scoring schedule for the current TrackForge **M58 v1.1** AAA-D catalogue rating. It is designed for buyers, lawyers, auditors, technical reviewers, and catalogue owners who need to understand exactly how a frozen rating input becomes a numeric score and a grade. It should be read with the overview [Rating Methodology (AAA-D)](./golden-record-selection). That page explains why the methodology exists. This page specifies the scoring contract. ## Transparency Boundary TrackForge publishes the parts of the system that a verifier needs in order to check the rating: - the rating input shape; - the public scoring factors; - the row-level risk-point schedule; - the catalogue-level cap rules; - the AAA-D threshold table; - the hashes and proof files that bind a rating event to its exact inputs. TrackForge does not publish the private detector playbook: source-specific SQL, graph traversals, resolver thresholds, society-specific scraping logic, matching heuristics, or the full internal research history behind every detector. Those are proprietary detection methods. They are also upstream of the rating contract. The distinction is deliberate. A verifier must be able to recompute the grade from the certified rating input bundle. A verifier does not need to independently rediscover every leakage condition from raw society data in order to verify that TrackForge applied the published scoring schedule consistently. ## Inputs To The Rating Function The catalogue rating function is deterministic: ```text rating_event = f( methodology_version, methodology_hash, workflow_version, taxonomy_version, jurisdictional_scope, original_ingested_population, leakage_vector, agreement_binding_summary, iswc_coverage_summary, merkle_root, snapshot_time ) ``` For catalogue-sale diligence, the denominator is the original ingested catalogue population where that population is available. Later cleaning, matching, or remediation does not remove a row from the original rating event. A later remediation creates a later rating event. ## Row-Level Rating Input Each rated population row is represented in the leakage vector as `M58-CATALOGUE-TRACK-RISK`. The row is not a secret classification. It is the public scoring projection of the frozen evidence state. Current row materiality inputs include: | Field | Meaning | |---|---| | `population_id` | Stable identifier for the row in the original ingested catalogue population. | | `population_source` | Source table or intake population used as the rating denominator. | | `source_row_number` | Source file row number where available. | | `isrc` | Recording identifier supplied or resolved for the population row. | | `tunecode` | PRS/SearchWorks work identifier where available. | | `title` | Title supplied or resolved for the population row. | | `matched_snapshot_id` | Sealed evidence snapshot matched to the population row, or `null` if none matched. | | `active_finding_count` | Count of active results-page findings attached to the row. | | `critical_count` | Active critical findings attached to the row. | | `high_count` | Active high-severity findings attached to the row. | | `medium_count` | Active medium-severity findings attached to the row. | | `low_count` | Active low-severity findings attached to the row. | | `agreement_binding_state` | PRS/SearchWorks WACD agreement-binding state for the row. | | `iswc_coverage_state` | ISWC coverage state for the row. | | `population_flags` | Population-integrity flags such as missing ISRC, duplicate ISRC, missing work identity, or no matched evidence snapshot. | | `population_risk_points` | Risk points added by population-integrity flags. | | `finding_risk_points` | Risk points added by active finding severity counts. | | `agreement_risk_points` | Risk points added by agreement-binding state. | | `iswc_risk_points` | Risk points added by ISWC state. | | `total_risk_points` | Sum of row risk points before the 100-point row cap. | | `capped_total_risk_points` | Row risk points after the 100-point cap. | | `track_score` | Row score after risk points are subtracted from 100. | The row score is calculated as: ```text total_risk_points = population_risk_points + finding_risk_points + agreement_risk_points + iswc_risk_points capped_total_risk_points = min(total_risk_points, 100) track_score = max(0, 100 - capped_total_risk_points) ``` ## Results-Page Findings The results page is the operational expression of the leakage taxonomy for a catalogue run. Its active findings are grouped for users into industry-facing categories, but the rating consumes the deterministic severity counts attached to the rated population row. The public scoring schedule does not publish every internal detector rule. Instead, it publishes how the scoring function treats active findings once the run has projected them into the frozen rating input: | Public scoring input | State | Risk points | |---|---:|---:| | Active finding severity | critical finding | 22 each, up to 3 per row | | Active finding severity | high finding | 13 each, up to 3 per row | | Active finding severity | medium finding | 6 each, up to 3 per row | | Active finding severity | low finding | 2 each, up to 3 per row | The "up to 3 per row" rule prevents a single row with many similar findings from dominating the entire catalogue by count alone. Severe structural defects are handled again at catalogue level through caps. ## Agreement-Binding Inputs For UK composition pathways, TrackForge treats PRS/SearchWorks WACD agreement binding as a direct rating input. | `agreement_binding_state` | Meaning | Risk points | |---|---|---:| | `agreement_bound` | The track/work is explicitly tied to a specific client-controlled PRS/SearchWorks agreement. | 0 | | `inferred_or_assumed` | There is ownership, work, tunecode, income, or society evidence, but no explicit agreement binding in the frozen evidence. | 18 | | `missing_or_conflicting` | No reliable client agreement route exists, or the evidence contradicts the expected account path. | 35 | | `not_applicable` | Agreement binding is outside the declared rights, society, or workflow scope. | 0 | This is a sale-diligence input, not merely a payment input. A work may still receive income without explicit agreement binding, but that income is weaker because PRS or ICE may treat it as inferred rather than determined. That creates counterclaim and dispute risk for a buyer. ## ISWC Inputs ISWC coverage is scored separately from agreement binding because it affects work identity and society cross-reference. | `iswc_coverage_state` | Meaning | Risk points | |---|---|---:| | `present` | Exactly one reliable ISWC is present for the row. | 0 | | `missing` | No ISWC is present where composition identity is in scope. | 10 | | `conflict` | More than one conflicting ISWC is present for the row. | 20 | | `not_applicable` | ISWC coverage is outside the declared workflow scope. | 0 | Missing ISWC is not always a direct payment leak by itself. It is still a rating factor because it weakens work resolution, registration repair, and diligence certainty. ## Population-Integrity Inputs Population defects are scored because the catalogue denominator is the original ingested population. A row that cannot be matched or resolved is part of the risk profile; it is not silently removed. | Population flag | Meaning | Risk points | |---|---|---:| | `missing_isrc_count` | The population row has no usable ISRC. | 28 | | `unmatched_snapshot_count` | The population row has no matched sealed evidence snapshot. | 30 | | `duplicate_isrc_count` | The same ISRC appears more than once in the rating population. | 8 | | `missing_title_count` | The population row has no usable title. | 6 | | `missing_work_identity_count` | The row has no tunecode, ISWC, or writer evidence. | 10 | These points are additive with active findings, agreement risk, and ISWC risk. ## Catalogue Aggregation The raw catalogue score is the arithmetic average of all row scores: ```text raw_catalogue_score = sum(track_score) / rated_population_count ``` The final numeric score is the lower of that raw average and every applicable catalogue cap: ```text final_score = min(raw_catalogue_score, applicable_catalogue_caps) ``` Caps are important because some defects should prevent a high grade even if they affect only part of the catalogue. For example, a catalogue with no agreement-bound PRS works is not a high-grade sale-diligence asset merely because some rows have clean metadata. ## Catalogue Caps Current M58 v1.1 cap rules: | Rule ID | Condition | Maximum score | |---|---|---:| | `critical_findings_cap_bbb` | Any critical active finding exists. | 72 | | `any_missing_or_conflicting_agreement_cap_a` | Any row has missing or conflicting agreement binding. | 82 | | `any_inferred_agreement_cap_aa` | Any row has inferred or assumed agreement binding. | 90 | | `zero_bound_agreement_with_agreement_risk_cap_bbb` | Zero rows are agreement-bound and at least one row carries agreement risk. | 72 | | `agreement_risk_quarter_population_cap_a` | Agreement-risk rows are at least 25% of the population. | 82 | | `catalog_population_missing_agreement_quarter_cap_ccc` | Original population is used and missing/conflicting agreement rows are at least 25% of the population. | 40 | | `catalog_population_zero_bound_agreement_cap_ccc` | Original population is used, zero rows are agreement-bound, and at least one row carries agreement risk. | 40 | | `any_iswc_conflict_cap_a` | Any ISWC conflict exists. | 82 | | `any_missing_iswc_cap_aa` | Any missing ISWC exists. | 90 | | `iswc_risk_quarter_population_cap_a` | ISWC-risk rows are at least 25% of the population. | 82 | | `catalog_population_missing_iswc_half_cap_ccc` | Original population is used and missing ISWCs are at least 50% of the population. | 40 | | `catalog_population_missing_isrc_tenth_cap_ccc` | Original population is used and missing ISRCs are at least 10% of the population. | 40 | | `catalog_population_unmatched_snapshot_tenth_cap_ccc` | Original population is used and unmatched rows are at least 10% of the population. | 40 | ## Numeric Score To Rating | Minimum final score | Rating | |---:|---| | 95 | AAA | | 90 | AA | | 82 | A | | 72 | BBB | | 62 | BB | | 52 | B | | 40 | CCC | | 30 | CC | | 20 | C | | 0 | D | ## Worked Example Consider a three-row catalogue: | Row | Inputs | Risk points | Row score | |---|---|---:|---:| | 1 | agreement-bound, ISWC present, no active findings | 0 | 100 | | 2 | one high finding, inferred agreement, ISWC missing | 13 + 18 + 10 = 41 | 59 | | 3 | no ISRC, no matched snapshot, missing work identity, missing/conflicting agreement, ISWC missing | 28 + 30 + 10 + 35 + 10 = 113, capped to 100 | 0 | The raw average is: ```text (100 + 59 + 0) / 3 = 53.0 ``` The catalogue has one missing/conflicting agreement row out of three, so the `catalog_population_missing_agreement_quarter_cap_ccc` cap applies. The final score is therefore: ```text min(53.0, 40) = 40 ``` The catalogue receives **CCC**, not B, because the structural agreement defect is too material to average away. ## Verification Requirements A verifier checking an M58 v1.1 rating should be able to inspect: - `methodology_version` and `methodology_hash`; - `workflow_version`; - `taxonomy_version`; - `jurisdictional_scope`; - `rating_scale`; - `rating_input_hash`; - `leakage_vector_hash`; - the ordered leakage vector; - row-level materiality inputs and row scores; - agreement-binding summary counts; - ISWC coverage summary counts; - the original population count used as denominator; - the Merkle/current root and proof state; - snapshot links for sealed evidence rows. The verification task is: 1. Confirm the proof files hash to the values stated in `manifest.json`. 2. Confirm `proof/leakage_vector.json` hashes to the rating event's `leakage_vector_hash`. 3. Recompute row risk points and row scores from this scoring schedule. 4. Average the row scores across the rating denominator. 5. Apply every applicable catalogue cap. 6. Map the final score to AAA-D. 7. Confirm the recomputed score and rating match `proof/rating_event.json`. 8. Confirm the rating event hashes to the stated `rating_input_hash`. 9. Confirm the methodology hash and proof root match the certified event. ## Internal Taxonomy Relationship The results-page taxonomy is the detection layer. It contains internal identifiers and detector families such as `RL-*`, `XD-*`, `DL-*`, and `PO-*`, plus source-specific evidence and remediation context. The rating input is the public scoring projection. It records the severity counts, agreement state, ISWC state, population flags, evidence references, and row risk points needed to reproduce the grade. That projection protects two things at once: - **Verifier rights** - a buyer or auditor can check the grade without trusting TrackForge's narrative. - **Detection IP** - TrackForge does not publish the full detector recipe book that created the results-page findings. If TrackForge changes how it detects an internal failure mode but emits the same public rating input, the scoring methodology has not changed. If TrackForge changes points, caps, thresholds, input states, denominator rules, or proof requirements, the methodology must be versioned and historical ratings remain bound to the version and hash they were issued under. --- ## certification/methodology/hashing.md --- sidebar_position: 5 title: Hashing description: How TrackForge hashes evidence packets, rating events, and methodology artefacts. keywords: - hashing - SHA-256 - methodology hash - evidence hash --- # Hashing TrackForge uses SHA-256 hashes to bind ratings to exact inputs. Key hashes include: - Methodology hash. - Evidence packet hash. - Leakage vector hash. - Rating input hash. - Merkle root. Any change to canonical JSON, methodology text, taxonomy version, workflow version, scope, or evidence contents should produce a different hash. Hashing makes drift detectable; it does not by itself prove legal ownership or future royalty collection. --- ## certification/methodology/independent-verification.md --- sidebar_position: 7 title: Independent Verification description: How any party can independently verify a TrackForge certification without access to TrackForge systems, using standard cryptographic tools. keywords: - independent verification - self-verification certification - cryptographic audit - third-party verification --- # Independent Verification :::info[Methodology Version] Methodology v1.1 — M58 AAA-D rating and certification model ::: A TrackForge certification is designed to be verifiable by any party, at any time, **without requiring access to TrackForge systems**. This is the distinguishing property of the certification: the proof does not depend on the certifier's continued existence, cooperation, or honesty. ## Three-step verification process Verification follows three steps. Each step uses standard cryptographic tools available in every major programming language and operating system. ### Step 1: Re-compute the hash Take the canonical JSON artefact included in the certification proof bundle, such as `proof/rating_event.json` or `proof/leakage_vector.json`, and compute its SHA-256 hash using the canonicalisation rules for the methodology version: ``` SHA-256( canonical_json_bytes ) → 64-character hex digest ``` Compare the computed digest with the matching hash stated in the proof wrapper or certificate. If they match, the canonical JSON artefact has not been altered since certification. If they do not match, the artefact has been modified. This step requires only the canonical JSON string and any SHA-256 implementation. No TrackForge software or network access is needed. ### Step 2: Verify the Merkle inclusion proof The certificate includes a [Merkle inclusion proof](./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 blockchain transaction. This can be done using: - **Any public blockchain explorer** (e.g., blockstream.info, mempool.space) - **A local blockchain node** (for maximum independence) - **The OpenTimestamps verifier** (`ots verify` command-line tool) The OpenTimestamps proof file (`.ots` format, included in the proof bundle) contains the complete cryptographic path from the Merkle root to the block header. Verification confirms that the hash was committed to the blockchain[^1] 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 | |:--|:--| | **`README.md`** | Human-readable verification instructions | | **`manifest.json`** | Bundle inventory and file hashes | | **`proof/rating_event_proof.json`** | Proof wrapper for the rating event, root/current-root state, and hash references | | **`proof/rating_event.json`** | AAA-D rating event with methodology, workflow, taxonomy, scope, PRS/WACD agreement-binding summary, ISWC coverage summary, root, and proof state | | **`proof/leakage_vector.json`** | Deterministic leakage-vector projection used by the rating methodology | | **`proof/snapshot_links.json`** | References from the rating event back to the frozen evidence snapshot | Enhanced or legacy chain-of-title bundles may also include per-track canonical JSON, Merkle inclusion proofs, OpenTimestamps files, and operator audit trails. Those files remain useful when present, but they are not the compact M58 proof ZIP shape. The proof bundle is self-contained. If TrackForge ceased to exist, a verifier with only the proof bundle and access to the blockchain could independently confirm every certification. ## What verification proves A successful three-step verification confirms: 1. **Data integrity** — The metadata has not been altered since certification (Step 1) 2. **Batch inclusion** — The track was part of the specific certified batch (Step 2) 3. **Temporal proof** — The certification existed at the stated time, as recorded on the blockchain (Step 3) 4. **Methodology integrity** — The rating was governed by a specific, published set of criteria, as confirmed by the methodology hash (Step 4 of rating verification) Verification does **not** prove that the metadata is legally correct or that no competing claims exist. It proves that the metadata was in the certified state at the certified time, and that it has not been altered since. See the [overview of certification scope](/overview/scope) for the precise boundaries of what certification asserts. ## Verifying a rating (not just a certification hash) The three steps above verify that the **certified data** has not been altered and was anchored at the stated time. TrackForge's [Rating Methodology](/methodology/golden-record-selection) and [Rating Input & Scoring Schedule](/methodology/rating-input-scoring-schedule) add a further layer of verifiability: because the rating is produced by a deterministic pure function applied to published criteria, an independent party can also verify the **rating itself**. To verify a rating: 1. **Obtain the catalogue data snapshot** — The same data the deterministic rating engine evaluated. This is included in the proof bundle's canonical JSON records. 2. **Apply the published scoring schedule** — The rating criteria are published as the [Rating Methodology](/methodology/golden-record-selection) and the detailed [Rating Input & Scoring Schedule](/methodology/rating-input-scoring-schedule), with versioned leakage-vector, agreement-binding, ISWC coverage, materiality, aggregation, cap, and threshold rules. Identical rating inputs always produce identical outputs. 3. **Compare evidence hashes** — Each track rating includes a SHA-256 evidence hash computed from the canonical JSON. Recompute the hash from the canonical data and confirm it matches. 4. **Verify the methodology hash** — Each rating includes a `methodology_hash` field: a SHA-256 digest of the complete rating ruleset. Recompute the hash from the published criteria (available in `methodology.json` in the proof bundle) and confirm it matches. This proves the exact thresholds and criteria that governed the rating. 5. **Verify the methodology/workflow/taxonomy versions** — Every rating output records the methodology version, workflow version, taxonomy version, and declared jurisdictional scope. Confirm that the published methodology for those versions matches the criteria applied. ### 5. Verify the methodology anchor The proof bundle includes a `methodology_standard.ots` file — an OpenTimestamps proof that anchors the methodology hash to the Bitcoin blockchain independently of the certification anchor. To verify: 1. Extract the `methodology_hash` from the certification record. 2. Use the OpenTimestamps verifier (`ots verify methodology_standard.ots`) to confirm that this hash was committed to a Bitcoin block. 3. Confirm that the Bitcoin block timestamp for the methodology anchor **predates** the certification timestamp. This proves that the rating rules were locked in before the certification was issued. TrackForge cannot have adjusted methodology thresholds after the fact to produce a more favourable result, because the methodology hash was committed to an immutable public ledger before the certification process began. The methodology anchor can also be verified programmatically via the `/verify/methodology` endpoint, which returns the methodology hash, the anchoring transaction, and the block timestamp. If the independently computed rating matches the published rating, this confirms that the rating was produced by faithful application of the stated methodology to the stated data — not influenced by the enrichment engagement. For the technical architecture ensuring rating independence (Chinese Wall), see [Rating Independence](/for-lawyers/rating-independence). [^1]: TrackForge currently uses the Bitcoin blockchain via the [OpenTimestamps](https://opentimestamps.org/) protocol. ## Related methodology pages - **[Hashing](./hashing)** — The SHA-256 algorithm used in Step 1 - **[Rating Input & Scoring Schedule](./rating-input-scoring-schedule)** — The row inputs, risk points, caps, thresholds, and rating recomputation contract - **[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 --- ## certification/methodology/merkle-tree.md --- sidebar_position: 5 title: Merkle Tree Construction description: How individual track hashes are assembled into a binary Merkle tree, producing a single root hash that commits to every track in a certification batch. keywords: - Merkle tree - binary hash tree - Merkle root hash - inclusion proof - cryptographic commitment - music metadata verification faq: - q: "What is a Merkle tree in music certification?" a: "A Merkle tree is a binary tree where every leaf contains a track's metadata hash and every parent contains the hash of its children. The single root hash cryptographically commits to every track in the batch. Any change to any track produces a different root — making tampering detectable." - q: "Why use a Merkle tree instead of hashing all tracks together?" a: "A Merkle tree allows individual tracks to prove their inclusion without revealing other tracks' data. For a catalogue of 10,000 tracks, an inclusion proof requires only about 14 hashes — compact, fast, and privacy-preserving. This enables partial acquisitions and sub-licensing verification." --- # Merkle Tree Construction :::info[Methodology Version] Methodology Version 1.1 - Effective May 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 graph TD Root["Merkle Root"] HAB["Parent AB"] HCD["Parent CD"] HA["Track A"] HB["Track B"] HC["Track C"] HD["Track D"] Root --> HAB Root --> HCD HAB --> HA HAB --> HB HCD --> HC HCD --> HD ``` 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 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 blockchain - **[Independent Verification](./independent-verification)** — How Merkle proofs are used in the verification process --- ## certification/methodology/recertification.md --- sidebar_position: 7 title: Re-Rating & Supersession description: How later evidence or remediation produces a new rating event without rewriting history. keywords: - re-rating - supersession - rating event - remediation --- # Re-Rating & Supersession A rating is a snapshot. Later remediation or new evidence creates a new rating event; it does not mutate the old one. ## When To Re-Rate Re-rating is appropriate when: - A remediation package has been accepted or actioned. - New society evidence changes leakage state. - A methodology, workflow, taxonomy, or jurisdictional scope version changes. - A prior workflow failed and must be rerun before the subject is rateable. ## What Changes The new event gets its own: - Snapshot time. - Run ID. - Evidence packet hash. - Leakage vector hash. - Merkle root. - Proof state. - Methodology and workflow metadata. Historical events remain verifiable under their original contracts. --- ## certification/methodology/value-chain-maturity-model.mdx --- sidebar_position: 3 title: Rating Contract & Maturity Model description: How TrackForge separates evidence maturity, leakage state, and certificate-facing AAA-D ratings. keywords: - rating contract - leakage vector - methodology hash - evidence maturity - AAA-D --- # Rating Contract & Maturity Model TrackForge still tracks evidence maturity internally, but the current certificate-facing rating is the **AAA-D leakage rating**. Evidence maturity answers "what evidence do we have?" The rating answers "what leakage conditions are active under the declared methodology and scope?" ## Three Separate Concepts | Concept | Purpose | Example output | |---|---|---| | Evidence maturity | Describes the depth and provenance of the evidence packet. | Source counts, operator review, proof artefacts. | | Leakage state | Describes deterministic taxonomy conditions. | Active, inactive, not applicable. | | Rating event | Applies methodology-versioned materiality and aggregation rules. | AAA, AA, A, BBB, BB, B, CCC, CC, C, D. | Keeping these concepts separate prevents two errors: - Treating missing global-society checks outside the declared UK/US scope as "poor coverage". - Treating source agreement as a substitute for leakage-taxonomy state. - Treating PRS agreement binding or ISWC coverage as optional hygiene when they are declared workflow inputs. ## Rating Event Inputs ```mermaid flowchart LR A["Evidence Packet"] --> B["Agreement + ISWC Inputs"] B --> C["Leakage Vector"] D["Methodology Hash"] --> F["Rating Event"] E["Workflow + Taxonomy Versions"] --> F C --> F G["Jurisdictional Scope"] --> F F --> H["AAA-D Rating"] F --> I["Proof Bundle"] ``` Every production rating event pins: - Methodology version and methodology hash. - Taxonomy version. - Workflow version. - Jurisdictional scope. - Subject ID and snapshot run ID. - Agreement-binding and ISWC coverage summaries where in scope. - Evidence packet hash or rating input hash. - Leakage vector hash. - Merkle root. - OpenTimestamps proof state. - Snapshot time. ## Current Scope Boundary The current direct workflow is UK/US. A catalogue should not be penalised for not directly checking societies outside that declared scope. If the scope changes, the methodology version and workflow version must change with it. ## Maturity Is Still Useful Evidence maturity remains useful for operator diagnostics and future expansion. It can explain why a leakage condition was found, how strongly it is evidenced, and what proof artefacts exist. It should not be presented as the public rating language unless it is explicitly labelled as a legacy or diagnostic field. ## Portfolio Aggregation Catalogue ratings aggregate track-level and pathway-level leakage state using methodology-versioned rules. The final formula must prevent severe defects from being averaged away by a large clean tail, and it must identify the material revenue pathways affected. In particular, an otherwise clean catalogue should not remain AAA if a material share of PRS/MCPS-scoped works are not explicitly bound to client WACD agreements. ISWC gaps should also be weighted by pathway and materiality so identifier defects are visible without pretending every blank ISWC has the same commercial consequence. Historical methodology versions remain comparable only when the comparison states the version bridge being used. --- ## certification/overview/audience.md --- sidebar_position: 6 title: Who Uses TrackForge? description: Guidance for catalogue owners, lawyers, buyers, and operators using TrackForge rating certificates. keywords: - catalogue owners - lawyers - due diligence - royalty recovery --- # Who Uses TrackForge? TrackForge is built for people who need to know whether royalty infrastructure is working and how to fix it when it is not. ## Catalogue Owners Use TrackForge to find money at risk, prioritise remediation, and produce evidence-backed deliverables. Start with [Reading Your Certificate](/for-catalogue-owners/reading-your-certificate). ## Lawyers And Buyers Use TrackForge to understand the diligence record behind a catalogue rating, including methodology hash, scope, proof state, and leakage conditions. Start with [Scope & Legal Positioning](/for-lawyers/certification-scope). ## Operators Use TrackForge to move from finding to fix: registration files, claim packages, evidence briefs, and proof bundles. Start with [Evidence Assembly & Leakage Projection](/methodology/enrichment-validation). --- ## certification/overview/independent-verification-explained.md --- sidebar_position: 0.8 title: "Independent Verification: Why You Don't Have to Trust Us" description: Every TrackForge rating is mathematically verifiable by anyone, without TrackForge's involvement. Here is how it works, explained for a general audience. keywords: - cryptographic verification music - SHA-256 metadata hash - Merkle tree music certification - blockchain timestamp verification - OpenTimestamps Bitcoin - independent audit music rights - tamper-proof certification faq: - q: "How can I verify a TrackForge certification without trusting TrackForge?" a: "Every current certification includes proof artefacts. You recompute SHA-256 fingerprints for the rating event, leakage vector, and snapshot links — if they match, the proof files are identical to what was certified. A current root proves the event belongs to the certified evidence set, and any OpenTimestamps proof shows when the root existed." - q: "What is a Merkle tree and why does it matter for music certification?" a: "A Merkle tree combines thousands of track fingerprints into a single root hash. Any individual track can prove it was included in the certified catalogue without revealing other tracks' data. For 10,000 tracks, an inclusion proof requires only about 14 hashes — compact, fast, and privacy-preserving." - q: "What does cryptographic verification NOT prove?" a: "It proves the data has not changed since certification and that certification happened when claimed. It does not prove that the underlying data was correct in the first place. If a writer's IPI number was wrong when certified, the fingerprint faithfully records the wrong number. The rating methodology ensures rigour; the cryptographic layer ensures tamper-proofness." --- # Independent Verification — Why You Don't Have to Trust Us ## The trust problem If the only way to believe a rating is to take the rater's word for it, you have not solved the information asymmetry problem. You have merely moved trust from the seller to a new intermediary. A buyer's lawyer should be able to ask two questions and get answers that do not depend on TrackForge being honest: 1. *"How do I know the data hasn't been changed since certification?"* 2. *"How do I know this track was actually part of the certified batch?"* TrackForge answers both with mathematical proof. ## The simple version Think of it like notarising a document — but one that nobody can forge, alter, or backdate, and that you can verify yourself without the notary's involvement. When TrackForge certifies a catalogue under the current M58 model, four things happen: ### 1. The rating event gets a unique digital fingerprint The rating event, leakage vector, and snapshot links are serialised deterministically and run through a mathematical function that produces fixed strings of characters. The same data always produces the same fingerprint. Change a single digit and the fingerprint changes completely. Anyone with the same proof files can compute the fingerprints and check they match. ```mermaid flowchart LR A["Track Metadata
ISRC: GBAYE0000001
Writer: Freddie Mercury
IPI: 00003926939
Share: 25.00%"] --> B["Canonical
Format"] B --> C["SHA-256"] C --> D["Fingerprint
a7f3b2c1...
(64 hex characters)"] style A fill:#1a1a2e,stroke:#e94560,color:#fff style D fill:#1a1a2e,stroke:#e94560,color:#fff ``` ### 2. Proof fingerprints are bound to a current root The proof files are tied to a current Merkle/root commitment for the certified evidence set. Enhanced or historical bundles may also include per-track inclusion proofs, but the compact M58 bundle centres on `manifest.json`, `methodology/methodology.json`, `proof/rating_event_proof.json`, `proof/rating_event.json`, `proof/leakage_vector.json`, and `proof/snapshot_links.json`. ```mermaid flowchart TD R["Root Hash
e4d2f1a8..."] --- AB["b3c7d9e2..."] R --- CD["f1a4b8c3..."] AB --- A["Track 1
a7f3b2c1..."] AB --- B["Track 2
d8e5f4a2..."] CD --- C["Track 3
c2b9a7d4..."] CD --- D["Track 4
9f1e3c8b..."] style R fill:#e94560,stroke:#ff6b6b,color:#fff style AB fill:#1a1a2e,stroke:#e94560,color:#fff style CD fill:#1a1a2e,stroke:#e94560,color:#fff style A fill:#2d6a4f,stroke:#40916c,color:#fff style B fill:#2d6a4f,stroke:#40916c,color:#fff style C fill:#2d6a4f,stroke:#40916c,color:#fff style D fill:#2d6a4f,stroke:#40916c,color:#fff ``` ### 3. The catalogue fingerprint is permanently timestamped The root fingerprint is recorded on a public blockchain — a distributed ledger maintained by a global network that no single party controls. This creates an immutable record that *this exact fingerprint existed at this exact point in time*. It cannot be altered, backdated, or deleted. ### 4. The rating methodology is independently timestamped The rules that govern the rating — every threshold, criterion, and disclosure — are also fingerprinted and permanently timestamped on the blockchain, separately from any individual certification. This means the methodology itself cannot be changed retroactively. A verifier can confirm that the rating rules predated the certification they governed, closing the loop on the question: *"Could the rules have been adjusted after the fact to produce a more favourable result?"* The answer is mathematically provable: no. ```mermaid flowchart LR M["Rating Methodology
Thresholds, criteria,
disclosure text"] --> S["SHA-256"] S --> H["Methodology Hash
b4e2a1f7..."] H --> OTS["OpenTimestamps"] OTS --> BTC["Bitcoin
Blockchain"] style M fill:#1a1a2e,stroke:#e94560,color:#fff style H fill:#1a1a2e,stroke:#e94560,color:#fff style BTC fill:#2d6a4f,stroke:#40916c,color:#fff ``` The result: any third party can independently confirm that the rating event proof files have not changed, that the event is tied to the certified evidence root, that any anchored proof happened when it claims, and that the rating rules were locked in before the assessment — all without contacting TrackForge. ## Why this matters commercially This is not technology for technology's sake. Each step solves a specific commercial problem: **Fingerprinting solves the "was this proof altered?" problem.** In a traditional advisory engagement, a buyer must trust that the data in the report is what was actually reviewed. With TrackForge, the buyer recomputes the fingerprint from the rating event and proof files. If it matches, the artefact is identical to what was certified. If it doesn't, something has changed. No trust required. **The current root solves the "is this the certified event?" problem.** A buyer can verify that the rating event is tied to the certified evidence set and current certification root. Enhanced bundles can add per-track inclusion proofs for partial acquisitions, sub-licensing, and portfolio carve-outs. **The blockchain timestamp solves the "when was this actually done?" problem.** A PDF report can be backdated. A blockchain record cannot. This provides independently verifiable proof of *when* the assessment happened — critical for re-certification, recourse claims, and regulatory compliance. ## The technical detail (for those who want it) The fingerprinting uses **SHA-256**, a cryptographic hash function that is an industry standard used in banking, government systems, and digital signatures worldwide. The serialisation rules are [published](/technical/canonical-json-schema) so any engineer can reproduce the process. The combined fingerprint uses a **Merkle tree** — a data structure that allows individual items to prove their inclusion in a set without revealing the other items. For a catalogue of 10,000 tracks, an inclusion proof requires only about 14 hashes. Compact, fast, and privacy-preserving. The timestamp uses **OpenTimestamps** on the Bitcoin blockchain — chosen because it is the most widely distributed and longest-running public blockchain, providing the highest assurance of permanence. See [Blockchain Anchoring](/methodology/blockchain-anchoring) for implementation details. ## Comparison at a glance | | Consultant report | TrackForge certification | | --- | --- | --- | | **Can the buyer verify data hasn't changed?** | No — must trust the consultant | Yes — recompute the fingerprint | | **Can a third party reproduce the grade?** | No — methodology is proprietary | Yes — the rating methodology and scoring schedule are published | | **Is there proof of when the assessment happened?** | Dated report (can be backdated) | Blockchain timestamp (immutable) | | **Can individual tracks be verified privately?** | No | Yes — inclusion proofs | | **Does verification need the assessor?** | Yes | No — all proofs are self-contained | | **What if the assessor goes out of business?** | Report becomes unverifiable | Proofs remain valid indefinitely | | **Can the methodology be changed retroactively?** | No way to verify | No — methodology is OTS-timestamped on Bitcoin | ## What this does not do Cryptographic verification proves that the data has not changed since certification and that the certification happened when it claims. It does not prove that the underlying data was correct in the first place. If a writer's IPI number was wrong when certified, the fingerprint faithfully records the wrong number. This is why the [rating methodology](/methodology/golden-record-selection) and [rating input scoring schedule](/methodology/rating-input-scoring-schedule) are equally important. The cryptographic layer ensures the assessment is tamper-proof and verifiable. The methodology and scoring schedule explain how TrackForge projects evidence into leakage state, row risk points, catalogue caps, and an AAA-D rating. Together, they provide something that has never existed in the music rights market: a standardised, verifiable, and comparable assessment of catalogue quality. **Return to: [Why TrackForge Exists](/overview/why-trackforge)** --- **Notes** [^1]: TrackForge currently uses the Bitcoin blockchain via the [OpenTimestamps](https://opentimestamps.org/) protocol. Bitcoin is used because it is the most widely distributed and longest-running public blockchain, providing the highest assurance of permanence. See [Blockchain Anchoring](/methodology/blockchain-anchoring) for implementation details. --- ## certification/overview/logging-in.md --- title: Logging In sidebar_position: 4 --- ## TrackForge Accounts Are Invite-Only TrackForge does not currently allow public self-signup. To access TrackForge, you must be invited by the TrackForge team. ## How To Log In 1. Go to [auth.trackforge.studio](https://auth.trackforge.studio) 2. Enter your email address and password. 3. If prompted, complete 2-factor authentication (2FA). After login, you will be redirected back to TrackForge. ## Accepting An Invite If you've been invited, you'll receive an email with a link to verify your email address and set your password. 1. Open the invite email. 2. Click the verification link. 3. Set your password (and 2FA if prompted). 4. Return to [auth.trackforge.studio](https://auth.trackforge.studio) to log in. Note: During the verification/password setup flow, you may briefly see our authentication provider's UI. This is expected. ## Troubleshooting ### I didn't receive the invite email 1. Check spam/junk folders. 2. Ask the TrackForge team to resend the invite. ### I can log in but can't access TrackForge TrackForge access is controlled by invitation and authorization. If you believe you should have access, contact the TrackForge team. --- ## certification/overview/scope.md --- sidebar_position: 5 title: What Certification Does And Does Not Mean description: The boundaries of TrackForge rating certification. keywords: - certification scope - process fidelity - AAA-D rating --- # What Certification Does And Does Not Mean TrackForge certification means a defined methodology was applied to a frozen evidence snapshot and produced the stated rating event. It does not mean TrackForge is guaranteeing legal ownership, future royalty payment, or direct registration state in every global society. ## Certification Confirms - Methodology version and methodology hash. - Taxonomy and workflow versions. - Direct jurisdictional scope. - Snapshot run and snapshot time. - Rating event value on the AAA-D scale. - Evidence hashes, Merkle root, and proof state. ## Certification Does Not Confirm - Absolute legal ownership. - Dispute-free writer shares. - Direct validation outside the declared scope. - Future absence of corrections or transfers. - Legal advice. Current direct scope is UK/US unless a certificate states a different methodology-versioned scope. --- ## certification/overview/the-market.md --- sidebar_position: 0.6 title: "The Market: Music Catalogues as Financial Assets" description: Over $20 billion in institutional capital has deployed into music rights since 2019, but the mid-tier market lacks standardised risk assessment. keywords: - music catalogue investment - music rights acquisition - institutional capital music - NPS multiples - music ABS securitisation - mid-tier catalogue opportunity - music copyright valuation faq: - q: "How much capital has been deployed into music rights?" a: "Over $20 billion in confirmed capital has been deployed into music rights acquisitions since 2019. Buyers include pension funds, private equity firms, sovereign wealth vehicles, and ABS investors. Concord's 2025 securitisation raised $1.765 billion — the largest music ABS ever issued." - q: "What valuation multiples do music catalogues trade at?" a: "Evergreen catalogues trade at 14–18x Net Publisher's Share (NPS), implying unlevered yields of 5–7%. Mid-tier catalogues ($1–50M) offer higher yields at 5–10x multiples but lack standardised risk assessment." - q: "Why is the mid-tier catalogue market underserved?" a: "Due diligence costs $100K–$300K regardless of deal size. For a $5M catalogue, that is 6% of the deal value — economically impossible. The capital wants to deploy but cannot price what it is buying." --- # The Market — Music Catalogues as Financial Assets ## A $30 billion revenue stream attracting institutional capital Global recorded music revenues reached $29.6 billion in 2024, the tenth consecutive year of growth. Streaming alone accounted for $20.4 billion, with 752 million subscribers worldwide. Catalogue music — tracks older than 18 months — now accounts for over 70% of all streaming consumption.[^ifpi] These characteristics make music rights attractive to institutional investors: the cash flows are long-duration (copyright extends 70+ years), inflation-linked, diversified across platforms and territories, and largely uncorrelated with economic cycles. Academic research shows music consumption actually increases during downturns.[^sonar] Since 2019, over $20 billion in confirmed capital has been deployed into music rights acquisitions. The buyers are no longer just music companies — pension funds, private equity firms, sovereign wealth vehicles, and ABS investors now compete for catalogue assets. Concord's July 2025 securitisation, backed by 1.3 million copyrights, raised $1.765 billion across tranches maturing over five, seven, and ten years. It was the largest music ABS ever issued. SESAC's $889 million securitisation was oversubscribed three times.[^sonar] | Transaction | Year | Value | |---|---|---| | Concord ABS (1.3M copyrights) | 2025 | $1.765 billion | | Queen (Sony / Apollo) | 2024 | $1.27 billion | | Warner Music / Bain Capital JV | 2024 | $1.2 billion | | SESAC whole business securitisation | 2025 | $889 million | | Michael Jackson (50% stake to Sony) | 2024 | $600 million | | Bruce Springsteen | 2021 | $500 million | ## The mid-tier opportunity The headline deals get the attention, but the real opportunity — and the real problem — sits lower in the market. The top twenty confirmed transactions account for roughly 61% of total disclosed capital. The remaining 39%, and the vast majority of catalogues by count, sits in the $1–50 million range. These mid-tier catalogues offer higher yields (5–10x NPS multiples versus 14–18x for iconic catalogues) with natural diversification benefits.[^sonar] But this is precisely the segment where standardised risk assessment does not exist. The due diligence cost structure — $100K–$300K regardless of deal size — makes it economically impossible to evaluate a $5M catalogue with the same rigour applied to a $500M deal. The capital wants in. It just cannot price what it is buying. ## Valuation depends on metadata Current market multiples for evergreen catalogues cluster around 14–18x Net Publisher's Share, implying unlevered yields of roughly 5–7%. But these valuations assume the underlying metadata is correct — that the royalties being projected will actually flow to the buyer.[^sonar] The Hipgnosis Songs Fund demonstrated what happens when this assumption breaks down. An independent forensic review in 2024 revealed that 67 of 105 acquisitions had been overvalued, 75% of the portfolio was missing growth forecasts, and the gap between two independent valuations of the same assets was $690 million. Blackstone eventually acquired the fund at a discount to both figures.[^shottower] This was not fraud. It was the predictable outcome of a market where there is no standardised way to measure the quality of what is being bought. ## How capital flows through the music rights market ```mermaid flowchart LR A["Institutional
Investors"] --> B["Fund Vehicles
(PE, dedicated funds,
JVs, ABS)"] B --> C["Catalogue
Acquisitions"] C --> D["228 CMOs
Worldwide"] D --> E["Royalty
Streams"] E --> F["Distributions
to Investors"] F -.->|"Reinvestment"| B style A fill:#1a1a2e,stroke:#e94560,color:#fff style B fill:#1a1a2e,stroke:#e94560,color:#fff style C fill:#1a1a2e,stroke:#e94560,color:#fff style D fill:#1a1a2e,stroke:#e94560,color:#fff style E fill:#1a1a2e,stroke:#e94560,color:#fff style F fill:#1a1a2e,stroke:#e94560,color:#fff ``` The diagram above simplifies a system that involves hundreds of collecting societies, multiple royalty types (mechanical, performance, synchronisation, neighbouring rights), and territory-by-territory administration. The complexity of this pipeline is precisely why metadata quality determines whether royalties reach the correct rights holder — or disappear into suspense accounts. **Next: [The Solution — How TrackForge Rates a Catalogue](./the-solution)** --- **Sources and notes** [^ifpi]: IFPI Global Music Report 2025. Global recorded music revenues of $29.6 billion in 2024; streaming revenues of $20.4 billion (69% of total); tenth consecutive year of growth; 752 million streaming subscribers globally. [^sonar]: Research synthesis based on disclosed transactions 2019–2025 (Perplexity Sonar Deep Research, February 2026). Transaction data, fund performance, valuation multiples, and market structure findings from 50+ authoritative sources including Goldman Sachs, Citrin Cooperman, Shot Tower Capital, CISAC, and MLC disclosures. [^shottower]: Shot Tower Capital independent valuation of Hipgnosis Songs Fund (March 2024). Prior valuation by Citrin Cooperman: $2.62 billion. Shot Tower valuation: $1.93 billion. 67 of 105 acquisitions valued below purchase price; 75% of portfolio missed growth forecasts. --- ## certification/overview/the-problem.md --- sidebar_position: 0.5 title: "The Problem: Why Catalogues Are Hard to Value" description: Information asymmetry creates a market for lemons. Sellers with good catalogues are penalised. Buyers discount everything. The mid-tier is locked out. keywords: - music catalogue valuation - market for lemons - information asymmetry - metadata risk - music rights due diligence cost - Hipgnosis valuation gap - uncollected royalties - ISRC ISWC IPI faq: - q: "Why are music catalogues hard to value?" a: "The seller knows the true state of their metadata but the buyer does not. There is no standardised, affordable way to close that gap — creating a textbook market for lemons where buyers discount everything and sellers of good catalogues are penalised." - q: "How much in royalties goes uncollected due to metadata errors?" a: "The Mechanical Licensing Collective in the US alone accumulated $427 million in unmatched mechanical royalties between 2007 and 2020. Globally, conservative estimates put unmatched royalties above $1 billion across all royalty types and territories." - q: "What happened with the Hipgnosis Songs Fund valuation?" a: "An independent forensic review in 2024 revealed a $690 million gap between two independent valuations of the same assets. 67 of 105 acquisitions had been overvalued and 75% of the portfolio was missing growth forecasts. Blackstone acquired the fund at a discount to both figures." --- # The Problem — Why Catalogues Are Hard to Value ## The lemons problem in music rights The core problem in the music catalogue market is information asymmetry. Sellers know the true state of their metadata. Buyers do not. And there is no standardised, affordable way to close that gap. This creates a textbook ["market for lemons"](https://trackforge.studio/why): **Sellers with good catalogues are penalised.** A rights holder who has invested in clean metadata, complete registrations, and accurate writer data has no credible way to prove it. Without a recognised quality metric, their catalogue is priced the same as one with incomplete data. Rational sellers of high-quality assets either accept a discount they don't deserve or withdraw from the market entirely. **Buyers discount everything.** Unable to distinguish quality, rational buyers assume average (or worse) metadata health and price accordingly. Deals that should close don't. Capital that should deploy stays on the sideline. **The market shrinks.** Over time, the highest-quality assets are priced out and the market is left with progressively lower-quality inventory. Everyone loses — owners, investors, and the creators whose royalties go uncollected. ## Why metadata is the whole game When you buy a catalogue, you are buying the right to collect royalties. Those royalties only flow if the metadata is correct: - Every recording needs an **ISRC** (International Standard Recording Code) to be identified on streaming platforms. - Every composition needs an **ISWC** (International Standard Musical Work Code) to be identified in the publishing system. - Every writer needs an **IPI number** to receive their share. - Every work must be **registered** with the collecting societies in each territory where it earns. If any of these identifiers are missing, incorrect, or inconsistent across systems, the payment chain breaks. The money doesn't disappear — it accumulates in suspense accounts, gets distributed to the wrong parties, or is eventually written off. The Mechanical Licensing Collective in the US alone accumulated $427 million in unmatched mechanical royalties between 2007 and 2020 — and that covers a single royalty type, in a single country. Globally, conservative estimates put unmatched royalties above $1 billion.[^mlc][^cisac] ```mermaid flowchart TD A["Recording Released"] --> B["DSP Streams Track"] B --> C{"Metadata
Complete?"} C -->|"Yes"| D["CMO Matches
to Rights Holder"] D --> E["Royalty Paid"] C -->|"No"| F["Suspense
Account"] F --> G{"Claimed
Within
Window?"} G -->|"Yes"| H["Late Payment
(months/years delayed)"] G -->|"No"| I["Black Box
(redistributed or
written off)"] style E fill:#2d6a4f,stroke:#40916c,color:#fff style H fill:#e9c46a,stroke:#f4a261,color:#000 style I fill:#d62828,stroke:#e76f51,color:#fff ``` For a buyer, this means the yield you think you are acquiring may be materially lower than the headline figures suggest — and you have no reliable way to quantify the gap before closing. ## The due diligence bottleneck The only current option for assessing metadata health is to hire a specialist advisory firm. The process costs $100,000–$300,000, takes 4–8 weeks, and produces a bespoke report that cannot be independently reproduced or compared to other assessments.[^sonar] This works for megadeals. At $500M+, the cost is a rounding error. But look at what happens as deal sizes shrink: | Deal size | Due diligence cost | Cost as % of deal | Feasibility | | --- | --- | --- | --- | | $500M+ | $100–300K | 0.02–0.06% | Standard practice | | $50–500M | $100–300K | 0.06–0.6% | Marginal | | $5–50M | $100–300K | 0.6–6% | Prohibitive | | $1–5M | $100–300K | 6–30% | Economically impossible | For the mid-tier catalogues that represent the majority of the market by count, traditional due diligence is economically impossible. This creates a hard barrier that locks out both buyers and sellers from the most capital-efficient segment of the market. ## What this means for you **If you're a catalogue owner:** You may have spent years maintaining clean metadata, but you cannot prove it to prospective buyers without paying for expensive due diligence yourself — and even then, the report is not portable or verifiable by other parties. **If you're a buyer or investor:** You cannot quantify the metadata risk you are taking on. Every acquisition is priced in the dark. The deals you don't do because you cannot assess quality represent lost opportunities. **If you're a lender:** You cannot underwrite music rights without standardised quality metrics. The asset class remains unquantifiable, no matter how attractive the yield profile looks on paper. ## What happens when due diligence fails The Hipgnosis Songs Fund provides the most documented case study of what happens when catalogue valuations are wrong. Hipgnosis assembled a portfolio of approximately 45,000 songs through aggressive acquisitions between 2018 and 2022. In 2024, an independent forensic review revealed the scale of the problem:[^shottower] | Metric | Before review | After review | |---|---|---| | Portfolio valuation | $2.62 billion (Citrin Cooperman) | $1.93 billion (Shot Tower Capital) | | Value destroyed | — | **$690 million (−26%)** | | Acquisitions overvalued | — | 67 of 105 | | Portfolio missing forecasts | — | 75% | The two independent valuers used different discount rates (Citrin Cooperman: 8.5%; Shot Tower: 9.63%), different growth assumptions, and arrived at valuations $690 million apart for the same assets. Blackstone subsequently acquired the fund for $1.6 billion — a discount to both valuations.[^sonar] This was not fraud. It was the predictable outcome of a market where there is no standardised way to measure the quality of what is being bought. ## No price discovery, no market In functioning markets, standardised quality assessments enable price discovery. Bond markets have credit ratings. Real estate has standardised appraisals. Equities have audited financial statements. Music catalogues have none of these. Each advisory engagement produces a proprietary, non-comparable opinion. There is no portable quality score, no published methodology, and no way for a second party to reproduce the analysis. The result is that every catalogue transaction is priced in the dark.[^sonar] This is the gap TrackForge fills. **Next: [The Market — Music Catalogues as Financial Assets](./the-market)** --- **Sources and notes** [^sonar]: Research synthesis based on disclosed transactions 2019–2025 (Perplexity Sonar Deep Research, February 2026). Due diligence cost ranges, market concentration data, and valuation methodology analysis from 50+ authoritative sources. [^shottower]: Shot Tower Capital independent valuation of Hipgnosis Songs Fund (March 2024). Prior valuation by Citrin Cooperman: $2.62 billion. Shot Tower valuation: $1.93 billion. 67 of 105 acquisitions valued below purchase price; 75% of portfolio missed growth forecasts. [^mlc]: The Mechanical Licensing Collective. Historical unmatched mechanical royalties of $426.9 million accrued by 21 Digital Service Providers between 2007 and 2020. [^cisac]: CISAC Global Collections Report 2025. 228 member societies across 111 countries collected €13.97 billion in royalties in 2024. The $1 billion+ global estimate for unmatched royalties is an extrapolation from MLC data across all royalty types and territories. --- ## certification/overview/the-solution.md --- sidebar_position: 4 title: The Solution description: TrackForge rates catalogue royalty-leakage state and produces proof-backed remediation deliverables. keywords: - royalty leakage - AAA-D rating - music catalogue due diligence --- # The Solution TrackForge is a rights-rating and remediation system for music catalogues. It detects active royalty-leakage conditions, values the money at risk, and produces the deliverables that fix the problem at the society or counterparty controlling the money. ## What Changes Instead of asking whether a catalogue is "well enriched", TrackForge asks: - Which leakage conditions are active? - Which revenue pathways are affected? - Which rights or identities are blocking collection? - What proof exists? - What deliverable fixes the issue? The certificate-facing rating is **AAA-D**, pinned to a methodology hash, taxonomy version, workflow version, jurisdictional scope, evidence snapshot, Merkle root, and proof state. ## Why This Matters Music royalty losses often sit in infrastructure gaps: missing registrations, conflicting work identities, unclaimed pools, unmatched recordings, chain-of-title breaks, and society-specific claim failures. TrackForge turns those gaps into auditable findings and practical remediation packages. ## Current Scope The current direct certification workflow is UK/US. Global society expansion is roadmap scope until a future methodology version implements and anchors it. --- ## certification/overview/what-is-certification.md --- sidebar_position: 1 title: What is TrackForge Rating Certification? description: An introduction to TrackForge's methodology-versioned, cryptographically anchored catalogue and track rating system. keywords: - TrackForge rating certification - music royalty leakage rating - AAA-D catalogue rating - blockchain anchored verification - methodology hash - Merkle proof faq: - q: "What is TrackForge Rating Certification?" a: "TrackForge Rating Certification is a deterministic snapshot rating of a catalogue or track under a named methodology version, workflow version, taxonomy version, and jurisdictional scope. The current public rating language is AAA-D." - q: "What does the rating measure?" a: "The rating measures active royalty-leakage conditions under the declared workflow and scope. Evidence sources feed the assessment, but the rating is driven by the leakage taxonomy and rating rules, not by a source-agreement medal tier." --- # What is TrackForge Rating Certification? TrackForge identifies royalty leakage and produces the deliverables that fix it: CWR files, spreadsheets, evidence packets, briefs, and proof bundles. Rating certification is the cryptographic record of the catalogue or track state assessed at a specific time. A TrackForge rating is not a mutable scorecard. It is a point-in-time event: ```text rating_event = f(methodology version, methodology hash, taxonomy version, workflow version, jurisdictional scope, evidence snapshot, leakage vector, materiality rules, aggregation rules, snapshot time) ``` The current certificate-facing rating scale is **AAA-D**. Legacy Gold/Silver/Bronze/Declared fields may still appear in historical exports or compatibility APIs, but they are not the current public rating contract. ## The Current Process ```mermaid flowchart TB A["Catalogue Intake"] --> B["UK/US Workflow Execution"] B --> C["Evidence Packet Snapshot"] C --> D["Agreement + ISWC Risk Inputs"] D --> E["Leakage Taxonomy Projection"] E --> F["AAA-D Rating Event"] F --> G["Canonical JSON + Hashes"] G --> H["Merkle Root"] H --> I["OpenTimestamps Proof State"] I --> J["Certificate / Proof Bundle"] ``` 1. **Catalogue intake** - TrackForge receives catalogue metadata and maps the relevant entity scope. 2. **Workflow execution** - The current direct certification workflow checks UK and US registration, repertoire, and revenue pathways. 3. **Evidence packet snapshot** - Evidence is frozen into deterministic packet JSON with a packet hash. 4. **Agreement and ISWC risk inputs** - PRS/SearchWorks WACD agreement binding and authoritative ISWC coverage are projected where they are in scope. 5. **Leakage taxonomy projection** - Active, inactive, and not-applicable leakage conditions are projected from the frozen evidence. 6. **AAA-D rating event** - Materiality and aggregation rules produce a catalogue or track rating. 7. **Canonical hashing** - The rating event, methodology, and evidence snapshot are pinned by hashes. 8. **Merkle tree construction** - Evidence packet hashes are combined into a deterministic Merkle root. 9. **OpenTimestamps anchoring** - The proof state records whether the root or methodology hash is pending, confirmed, failed, or local-only. 10. **Proof bundle** - The owner receives the rating event data, proof files, verification instructions, and methodology artefacts. ## What The Rating Means The AAA-D rating describes royalty-leakage exposure under the declared methodology and scope. | Rating | Meaning | |---|---| | **AAA** | No active leakage conditions under the current workflow and scope. | | **AA** | No material active leakage; only minor remediable or informational issues. | | **A** | Low leakage exposure with bounded operational impact. | | **BBB** | Moderate active leakage; remediation should precede a clean operational claim. | | **BB** | Elevated leakage exposure across material registration or identity pathways. | | **B** | High leakage exposure across one or more material revenue pathways. | | **CCC** | Severe leakage exposure; catalogue or track state is materially compromised. | | **CC** | Critical leakage exposure; collection pathways are structurally unsafe. | | **C** | Near-failing state with pervasive active leakage or missing rights state. | | **D** | Failing state under the methodology; not collection-ready. | The rating is deterministic. If the same methodology, workflow, taxonomy, evidence snapshot, and rating rules are used, the same input produces the same rating event. For UK composition pathways, the rating includes whether works are explicitly bound to the relevant PRS/SearchWorks WACD agreement in the client's account. Revenue can still flow without that explicit binding, but the route is weaker because the claim is more exposed to dispute and manual society resolution. ISWC coverage is also part of the rating input because it affects composition identity, registration resolution, and downstream correction work. ## Current Scope The current direct certification scope is **United Kingdom and United States** registration, repertoire, and revenue pathways. UK/US defects can affect downstream international collection, but the current certificate does not claim direct validation of French, German, Japanese, or other non-UK/US society records. Global society expansion is roadmap scope. Future methodology versions may add direct checks for additional societies when the operational data and proof contracts are ready. ## What You Receive - Catalogue rating event summary using AAA-D. - Track-level leakage vector and evidence snapshot references where applicable. - Methodology version and methodology hash. - Taxonomy version, workflow version, and declared jurisdictional scope. - Evidence packet hashes and Merkle root. - OpenTimestamps proof state and proof files where available. - Verification instructions that do not require trusting TrackForge after issuance. ## What Certification Proves Certification proves that a defined process was followed and that the certified data, methodology, and proof artefacts existed in the stated form at the stated time. It does not prove legal ownership, guarantee future collection, or substitute for legal advice. The useful analogy is a rating agency or title-search record: the value is the documented, repeatable, independently verifiable process, not a claim that no unknown future contradiction can ever appear. ## Next Step If you need a defensible rating event for a catalogue transaction, audit, or remediation programme, request a certification review and confirm the intended scope before relying on any certificate-facing output. --- ## certification/overview/why-trackforge.md --- sidebar_position: 2 title: Why TrackForge? description: Why catalogue owners, lawyers, and buyers need deterministic royalty-leakage ratings instead of generic metadata scores. keywords: - why TrackForge - royalty leakage - music catalogue rating - AAA-D --- # Why TrackForge? Royalty leakage is not an abstract metadata quality problem. It is money blocked by specific infrastructure failures: registrations not made, works not matched, societies missing identifiers, rights chains breaking, or claims never reaching the payer. TrackForge exists to recover that money and prevent future loss. ## The Rating Agency Model TrackForge provides a deterministic AAA-D rating for catalogue or track state under a named methodology. Every production rating event pins: - The rules used. - The evidence snapshot assessed. - The direct UK/US scope currently certified. - The leakage taxonomy version. - The Merkle root and proof state. That gives buyers, lawyers, and owners a repeatable record instead of a trust-me score. ## The Operational Model Every finding is money at risk. Every deliverable is a fix. The rating is useful because it is tied to the same evidence and workflow that produce remediation outputs. ## Where To Start - **[What is TrackForge Rating Certification?](./what-is-certification)** - How ratings and proofs work. - **[Scope & Legal Positioning](/for-lawyers/certification-scope)** - What the certificate does and does not claim. - **[Reading Your Certificate](/for-catalogue-owners/reading-your-certificate)** - How to interpret rating fields. --- ## certification/technical/canonical-json-schema.md --- sidebar_position: 2 title: Canonical JSON Schema description: Deterministic JSON rules used for evidence packets, rating events, and legacy certification records. keywords: - canonical JSON schema - deterministic serialisation - evidence packet - rating event - leakage vector --- # Canonical JSON Schema TrackForge uses deterministic JSON to make evidence and rating outputs reproducible. The same data, serialised with the same rules, must produce the same SHA-256 hash. ## Serialisation Rule ```python json.dumps(data, sort_keys=True, separators=(",", ":"), ensure_ascii=True) ``` Rules: - Sort object keys lexicographically. - Use no whitespace after separators. - Escape non-ASCII characters. - Encode the resulting string as UTF-8 before hashing. - Do not append a trailing newline. ## Current Rating Event JSON Current certificate-facing output should identify the rating event and its proof contract: ```json { "rating_event_id": "...", "subject_type": "catalogue", "subject_id": "...", "rating": "BB", "rating_scale": "TRACKFORGE_AAA_D", "methodology_version": "v1.1", "methodology_hash": "...", "taxonomy_version": "v...", "workflow_version": "v...", "jurisdictional_scope": ["UK", "US"], "snapshot_run_id": "...", "snapshot_at": "...", "agreement_binding_summary": { "agreement_bound_count": 1042, "inferred_or_assumed_count": 38, "missing_or_conflicting_count": 0, "not_applicable_count": 0 }, "iswc_coverage_summary": { "present_count": 1061, "missing_count": 19, "conflict_count": 0, "not_applicable_count": 0 }, "leakage_vector_hash": "...", "evidence_packet_hash": "...", "merkle_root": "...", "ots_status": "pending" } ``` ## Evidence Packet JSON Evidence packets contain positive evidence and deterministic evaluation inputs. They should avoid duplicating finding narratives or mutable workflow state when a stable reference is enough. Common blocks include: - `track` - `identifiers` - `sources` - `society_registrations` - `neighbouring_rights` - `writers` - `publishers` - `findings_summary` - `valuation_summary` - `operator_review` - `evaluation` The evidence packet hash is the SHA-256 hash of the canonical packet JSON. ## Leakage Vector JSON A leakage vector is a deterministic projection from the revenue leakage taxonomy: ```json { "taxonomy_item_id": "RL-...", "state": "active", "affected_revenue_pathway": "uk_performance", "affected_right_type": "composition", "evidence_references": ["snapshot:..."], "materiality_inputs": { "agreement_binding_state": "agreement_bound | inferred_or_assumed | not_applicable", "iswc_state": "present | missing | conflict | not_applicable" }, "remediation_pointer": null } ``` The vector hash should be computed from the ordered canonical representation used by the methodology version. ## Legacy Canonical Track Records Historical certification endpoints may still expose canonical track JSON and compatibility fields such as `certification_tier`, `source_count`, or platform identifiers. These are legacy or diagnostic fields unless a historical certificate explicitly binds them to its original methodology. Current rating events should not treat platform source identifiers as rating-determinative by themselves. ## Verification Procedure To verify a current rating event: 1. Canonicalise the evidence packet and rating event JSON. 2. Recompute the evidence packet hash and rating input hash. 3. Rebuild the Merkle root from the committed leaf hashes. 4. Confirm the methodology hash, taxonomy version, workflow version, scope, and snapshot run ID match the certificate. 5. Verify OpenTimestamps proof files where status is confirmed. --- ## certification/technical/data-security.md --- sidebar_position: 5 title: Data Security & Privacy description: Technical analysis of data visibility boundaries, blockchain content, verification page privacy, and GDPR-relevant controls in the TrackForge certification system. keywords: - data security - privacy - public vs private data - GDPR technical controls - verification page privacy --- # 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 the blockchain. Reveals nothing about individual tracks. | | Blockchain transaction ID | Anchor metadata | Publicly visible on the blockchain. Contains only the Merkle root hash. | | 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 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 blockchain 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 blockchain 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 current M58 proof bundle ZIP archive contains the rating event proof, manifest, methodology artefact, leakage vector, and snapshot links needed for independent verification. Enhanced or legacy bundles may also include canonical track JSON and Merkle proofs. Proof bundles are 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 blockchain. 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 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. --- ## certification/technical/merkle-proof-format.md --- sidebar_position: 3 title: Merkle Proof Format description: Technical specification of TrackForge's deterministic Merkle tree construction and inclusion proofs. keywords: - Merkle proof format - inclusion proof - evidence packet hash - proof verification --- # Merkle Proof Format TrackForge uses a deterministic binary Merkle tree to commit a set of evidence packet hashes to one root. The root is then tied to certificate and OpenTimestamps proof state. ## Proof JSON ```json { "leaf_hash": "64-character sha256 hex", "proof_hashes": ["64-character sha256 hex"], "proof_directions": ["right"], "root_hash": "64-character sha256 hex", "leaf_index": 0, "total_leaves": 1095 } ``` | Field | Meaning | |---|---| | `leaf_hash` | Evidence packet hash or other methodology-defined leaf hash. | | `proof_hashes` | Sibling hashes from leaf to root. | | `proof_directions` | Direction of each sibling: `left` or `right`. | | `root_hash` | Merkle root committed by the rating/certification event. | | `leaf_index` | Position in the sorted leaf list. | | `total_leaves` | Total leaves in the tree. | ## Construction Rules 1. Sort leaf hashes lexicographically. 2. Pair adjacent hashes. 3. If a layer has an odd number of nodes, duplicate the last node. 4. Combine siblings by concatenating their hex strings and hashing the UTF-8 bytes: ```python hashlib.sha256((left + right).encode("utf-8")).hexdigest() ``` This mirrors the backend implementation. The combination input is the concatenated hex text, not decoded raw bytes. ## Verification Algorithm ```python 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": current = sha256_hex(current + sibling) else: current = sha256_hex(sibling + current) return current == proof["root_hash"] ``` The proof only establishes inclusion in the committed root. To verify a certificate, also check that the root belongs to the same rating event, methodology hash, snapshot run, and proof state shown on the certificate. --- ## certification/technical/opentimestamps.md --- sidebar_position: 4 title: OpenTimestamps Integration description: How TrackForge submits hash commitments to OpenTimestamps and records proof state. keywords: - OpenTimestamps integration - Bitcoin timestamp - OTS proof - Merkle root - hash commitment --- # OpenTimestamps Integration TrackForge uses OpenTimestamps (OTS) to create independently verifiable timestamp evidence for methodology hashes and evidence roots. ## What Is Submitted TrackForge stores hashes as 64-character lowercase hexadecimal SHA-256 strings. For OTS submission, the implementation: 1. Validates that the value is a 64-character lowercase hex digest. 2. Decodes the hex string to 32 bytes with `bytes.fromhex(hash_hex)`. 3. Computes `SHA256(decoded_hash_bytes)`. 4. Submits that 32-byte commitment to OTS calendar servers. This means the OTS commitment is a SHA-256 commitment of the decoded hash/root bytes. It is not the raw ASCII string of the Merkle root. ## Submission Flow ```mermaid flowchart TB A["64-char hex hash"] --> B["Decode to 32 bytes"] B --> C["SHA-256 commitment"] C --> D["POST /digest to OTS calendar"] D --> E["Pending .ots proof"] E --> F["Upgrade / check confirmation"] F --> G["Confirmed or still pending"] ``` The proof bundle should include both the original hash value and the `.ots` proof file, so an independent verifier can reproduce the commitment and validate the timestamp. ## Proof States | State | Meaning | |---|---| | `pending` | Calendar proof exists or submission is awaiting confirmation. | | `confirmed` | Proof contains confirmed blockchain attestation. | | `failed` | Submission or upgrade failed. | | `not_submitted` | No OTS submission was made. | | `local_only` | Local witness only; not a public blockchain confirmation. | Certificate and verification pages must not blur pending, confirmed, failed, and local-only states. ## Calendar Servers TrackForge submits to configured OTS calendar servers. Calendar availability is external to TrackForge; if calendars are unreachable, the system can preserve a local witness state so certification work is not silently blocked. That state must be labelled as local-only rather than confirmed. ## Verification Without TrackForge To verify a confirmed proof: 1. Recompute the relevant evidence or methodology hash. 2. Decode the 64-character hash to bytes. 3. Compute the OTS commitment hash. 4. Verify the `.ots` file with a compliant OpenTimestamps verifier. 5. Confirm the verified commitment corresponds to the certificate's hash/root. The certificate should provide enough information for this process without requiring access to TrackForge systems. --- ## certification/technical/verification-api.md --- sidebar_position: 1 title: Verification API description: Current and legacy verification endpoints for TrackForge rating certificates and proof bundles. keywords: - verification API - rating event - certificate verification - Merkle proof API - legacy certification API --- # Verification API TrackForge verification APIs expose certificate and proof data so a third party can check the methodology hash, evidence hashes, Merkle root, and OpenTimestamps proof state. :::caution[Compatibility Surface] Some deployed endpoints and fields still use historical names such as `golden_record_count` or tier-count fields. Those names are legacy compatibility fields. Current certificate-facing methodology uses AAA-D rating events and leakage-taxonomy state. ::: ## Current Rating Event Shape New rating-event payloads should expose: ```json { "rating_event_id": "...", "subject_type": "catalogue", "subject_id": "...", "rating": "BB", "rating_scale": "TRACKFORGE_AAA_D", "methodology_version": "v1.1", "methodology_hash": "...", "taxonomy_version": "v...", "workflow_version": "v...", "jurisdictional_scope": ["UK", "US"], "snapshot_run_id": "...", "snapshot_at": "...", "leakage_vector_hash": "...", "evidence_packet_hash": "...", "merkle_root": "...", "ots_status": "pending" } ``` Current M58 proofs should also include PRS/WACD agreement-binding and ISWC coverage summaries where those inputs are in scope. ## Verification Requirements A verifier should be able to: 1. Recompute the methodology hash from the methodology artefact. 2. Recompute evidence packet hashes from canonical JSON. 3. Rebuild the Merkle root from the rating event's evidence packet set. 4. Confirm the rating event references the same run, methodology hash, workflow version, taxonomy version, and scope. 5. Verify `.ots` proof files when `ots_status` is confirmed. ## Public Verification Endpoint The historical public endpoint verifies submitted canonical JSON against stored certification records. Current verification pages should additionally show rating event fields when available. ```http POST /api/v1/certifications/verify ``` Request: ```json { "canonical_json": "" } ``` Response: ```json { "verified": true, "record_hash": "64-character sha256 hex", "certification": { "batch_id": "...", "merkle_root": "...", "methodology_hash": "...", "rating_event_id": "..." }, "anchors": [ { "chain": "bitcoin", "status": "confirmed", "tx_id": "...", "block_number": 879234 } ] } ``` ## Forge Grade Proof Endpoint Forge exposes the current M58 grade proof for a subject so internal operators and authorised verifiers can retrieve the rating event and proof wrapper directly. ```http GET /ops/api/forge/catalogs/{catalog_id}/grade/proof ``` The response should identify the current certification root for the subject and return the same proof concepts found in the M58 ZIP: - `rating_event_proof` - `rating_event` - `leakage_vector` - `snapshot_links` - `manifest` or file-hash equivalent The **current root** is the active Merkle/root commitment for the latest certification event in the subject's version chain. Historical roots remain valid for their own events, but current reliance should use the root marked current by the certification chain. ## Legacy Batch Fields The following fields may remain in compatibility endpoints: | Field | Current interpretation | |---|---| | `golden_record_count` | Legacy count retained for historical APIs. Not the current rating basis. | | `tier_gold_count` | Legacy completeness-tier count. | | `tier_silver_count` | Legacy completeness-tier count. | | `tier_bronze_count` | Legacy completeness-tier count. | | `tier_declared_count` | Legacy completeness-tier count. | | `catalog_grade` | Historical or transitional field; current outputs should prefer `rating`. | Any UI that displays these fields beside a current rating should label them as legacy diagnostics. ## Proof Bundle Endpoint ```http GET /api/v1/certifications/{catalog_id}/proof-bundle ``` The legacy public bundle endpoint may still return historical certification archives. The current Forge M58 proof ZIP is available to authorised operators at: ```http GET /ops/api/forge/catalogs/{catalog_id}/grade/proof-bundle ``` The current M58 bundle should include: - `README.md`. - `manifest.json`. - `proof/rating_event_proof.json`. - `proof/rating_event.json`. - `proof/leakage_vector.json`. - `proof/snapshot_links.json`. - `methodology/methodology.json`. - Legacy or enhanced chain-of-title records only where needed for backwards compatibility or richer certification bundles. ## Status Semantics | Status | Meaning | |---|---| | `pending` | Submitted or awaiting confirmation; not confirmed. | | `confirmed` | Confirmed proof state. | | `failed` | Anchoring or verification failed. | | `not_submitted` | No external proof submission exists. | | `local_only` | Local witness only; not public blockchain confirmation. |