# 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 > We find out what's actually registered, fix what's broken, and prove it's paying. The registration-truth layer for music rights. *Published by [TrackForge](https://trackforge.studio)* --- ## We find out what's actually registered, fix what's broken, and prove it's paying The registration-truth layer for music rights. ### Services - **TrackForge Workspace** — Keep your works in one place and see where each society stands. Free during the beta: [create a free workspace](/workspace) - **MCP server for AI assistants** — Free server that checks a catalogue against The MLC's data, looks up a song's writers and publishers, and validates CWR files. Add `https://api.trackforge.studio/api/v1/mcp` to Claude, ChatGPT or any AI assistant that takes a remote MCP server: [how to add it](/mcp#add) - **CWR Workbench** — Free online tool to create, check and read Common Works Registration 2.1 files and understand society ACK responses: [open the Workbench](/cwr-tool/workbench) - **ISRC Lookup** — Free tool that cross-references ISRCs across Spotify, MusicBrainz and The MLC to find metadata conflicts, registration gaps and trapped mechanical royalties: [look up an ISRC](/isrc-lookup) --- ## 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 hold unclaimed US mechanical royalties at The MLC — cross-referenced against 12 data sources. 67.5% are registered for performance rights at ASCAP; 73% stream on Spotify. [Read the full research note](/research/unclaimed-economy) ### How ISRC Registration Gaps Cost Labels Money 94.7% of a label catalog matched on Spotify. Only 50% had a registered mechanical work at the MLC. That 45-point gap — across 1,581 ISRCs — is where $569.9M in royalties disappear. [Read the full analysis](/research/isrc-registration-gaps) ### 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 of where the money goes — and why it never arrives. [Read the full essay](/research/royalty-leakage-map) ### Rowntree v PRS: The £3 Line The Court of Appeal has explained why black box royalties cannot be litigated back — and revealed the £3 threshold below which no one manually investigates an unmatched royalty. What the twenty-one pages almost nobody read actually say. [Read the full research note](/research/rowntree-v-prs) ### Irene Cara's $333,353 was not at her record label Irene Cara's estate has recovered $333,353 in royalties she never collected. About $246,000 was held by her music publisher and $78,000 by a UK collecting society. Roughly $8,000 was at a label. Why having a publisher does not mean your songs are registered, and how to check. [Read the full article](/research/irene-cara-uncollected-royalties) ### Doubt in the rate, fact in the forecast Valuations argue over the discount rate and take the income base on trust. Why a registration gap belongs in the forecast, and what buyers should check first. [Read the full analysis](/research/doubt-in-the-rate-fact-in-the-forecast) ### $198 billion, 57%, and the number nobody models Goldman Sachs forecasts music to $198.1 billion by 2035 and stops at the society's door. The step it leaves out has a published size and, from 2027, a clock. [Read the full analysis](/research/music-in-the-air-number-nobody-models) ### How to due-diligence a music catalogue before you buy Music catalogue due diligence checklist: six questions to answer before you buy, the data room, red flags, and how an independent rating fits. UK and US. [Read the guide](/research/music-catalogue-due-diligence) ### How to verify music rights ownership and metadata How to verify music rights ownership and metadata: match chain-of-title documents to what each society register holds, then check IDs, shares and links. [Read the guide](/research/verify-music-rights-ownership-metadata) ### Music catalogue risk: what to check and which tools help Music catalogue risk assessment: the 13 risks to check, how to detect each, what settles it, and which tools help, from society registers to valuation models. [Read the guide](/research/music-catalogue-risk-assessment) ### How to find unpaid music royalties and claim them Find unpaid music royalties by checking each society's register against your catalogue, fixing registrations and claiming in time. Covers The MLC's 2027 clock. [Read the guide](/research/find-unpaid-music-royalties) --- ## Contact - Email: [hello@trackforge.studio](mailto:hello@trackforge.studio) --- Source: [https://trackforge.studio/](https://trackforge.studio/) --- ## about.md # The registration-truth layer for music rights > TrackForge finds where music royalties go missing, helps owners fix their catalogue in a free Workspace, and is building an evidence-based catalogue rating. *Published by [TrackForge](https://trackforge.studio)* **Page:** https://trackforge.studio/about **Last updated:** 2026-10-15 --- ## About TrackForge TrackForge is infrastructure for music rights. We find out what’s actually registered, fix what’s broken, and prove it’s paying. It works in three layers: find where a catalogue’s income leaks, fix the catalogue in the free TrackForge Workspace, and rate it, with an evidence-based catalogue rating now in development. --- ## Nobody sees the whole picture A catalogue’s income depends on records held by dozens of collecting societies: PRS for Music and MCPS (the Mechanical-Copyright Protection Society) in the UK; The MLC (the Mechanical Licensing Collective) and SoundExchange in the US; PPL for performers; and many more around the world. Each has its own identifiers, formats and rules. Nobody sees the whole picture, so money goes missing quietly: a work registered at one society but not another, a writer’s share that nobody claimed, a recording never matched to its song. The same complexity makes catalogues very hard to value. Checking one properly is slow, specialist and expensive, so buyers and lenders assume part of any catalogue is broken and price that in. Well-kept catalogues are marked down along with neglected ones. --- ## Three layers of infrastructure ### 1. Find the leaks *Available now* We check every work against what each society actually holds, and show where income is being lost. Each check leaves one evidence record per work per society: what the society holds, when it was checked, where the data came from, and whether it matches the catalogue. [Essays and research](https://trackforge.studio/#essays-research) ### 2. Fix the catalogue *Free, open to anyone* The TrackForge Workspace is free, and anyone can sign up. Import a catalogue, see each work’s status at each society, fix what the checks flag, prepare CWR (Common Works Registration) files, and record each society’s response. Where income has gone unpaid, recovery traces it to its cause and follows it until the money arrives. [Open the Workspace](https://trackforge.studio/workspace) ### 3. Rate it *In development* We are developing an evidence-based catalogue rating across five components: registration, collection, title, identity and risk. It is our work towards a common standard for valuing music catalogues. [How certification works](https://trackforge.studio/docs/certification/overview/what-is-certification) Each piece of evidence is built once and used three ways: in the catalogue check, in the owner’s Workspace and in the rating. --- ## Why it matters With the evidence in place: - **Owners** can point to clear proof of how their catalogue performs and what it is worth. - **Buyers** can see what the records actually show before they commit. - **Lawyers and advisers** spend far less time on due diligence. - **Lenders and investors** can price the risk instead of discounting for the unknown. Together, that makes music a less risky asset class. --- ## Where TrackForge came from TrackForge began as an applied artificial intelligence (AI) project inside Adaptive Intelligence. Adaptive Intelligence’s work is finding complex problems that become tractable once AI can make sense of the data behind them, so people can make better decisions. Music rights are one of the clearest examples. TrackForge is based in Oxford. --- ## Explore TrackForge - [TrackForge Workspace](https://trackforge.studio/workspace) -- Import a catalogue, see each work’s status at each society and prepare CWR files. Free. - [CWR Workbench](https://trackforge.studio/cwr-tool/workbench) -- Create, check and read CWR files in your browser, and understand society responses. Free, no account. - [For AI assistants](https://trackforge.studio/mcp) -- TrackForge’s free MCP (Model Context Protocol) server lets an AI assistant check recordings and songs. - [Essays and research](https://trackforge.studio/#essays-research) -- Where royalties go missing, and why catalogues are hard to value. - [Certification](https://trackforge.studio/docs/certification/overview/what-is-certification) -- What a TrackForge certification is and what it records. - [Methodology](https://trackforge.studio/docs/certification/overview/the-problem) -- The published method, starting from the problem it addresses. --- ## Contact Questions, or want to talk about a catalogue? Email [hello@trackforge.studio](mailto:hello@trackforge.studio). --- Source: [https://trackforge.studio/about](https://trackforge.studio/about) --- ## 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, The MLC), 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 choose a report. 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 hello@trackforge.studio to discuss a catalogue assessment for your own catalogue. --- *TrackForge -- the registration-truth layer for music rights* --- 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: 2 October 2026 | Last Updated: 19 October 2026 --- These Terms of Service ("Terms") govern your use of the TrackForge certification platform, of TrackForge Workspace, and of the free public tools TrackForge offers, including the ISRC Lookup, the CWR Workbench, the public API and the MCP server (together, 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/docs/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 open a TrackForge Workspace account yourself, by signing in with Google, LinkedIn or a code sent to your email address (section 17). Accounts for the certification service are opened by invitation: TrackForge sets up your account and gives you your sign-in details. The free public tools need no account. - 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/docs/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/docs/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/docs/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 ### Free Public Tools, API and MCP Server The free ISRC Lookup, CWR tool, public API and MCP server may be used by people and by software acting for them, including AI assistants, without an account. When you use them: - Stay within the published limits (see [auth.md](https://trackforge.studio/auth.md)); do not rotate sessions, addresses or identities to get around them. - Do not use them to copy, rebuild or resell TrackForge's data, or to harvest registration data at scale. - Only submit a report request for yourself, or for someone who has agreed to be contacted by TrackForge. We may change, limit or withdraw these tools at any time. ### Findings, Not Advice Answers from the free tools are findings from third-party registration data (such as The MLC's bulk data feed) as of the date shown with each answer. Registrations and matches made after that date are not reflected, and the underlying data may contain errors. An answer is not a statement of who owns or controls a work or recording, is not permission to use it, and is not legal advice. The tools are provided as they are, without any warranty of accuracy or completeness. ## 9. Liability Limitations - **What these limits do not cover:** Nothing in these Terms limits or excludes our liability for death or personal injury caused by our negligence, for fraud or fraudulent misrepresentation, or for anything else that the law does not allow us to limit or exclude. - **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/docs/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/docs/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. - Closing a TrackForge Workspace, and what is deleted when, is covered by Section 17. ## 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. The Workspace beta offer has the longer notice set out in Section 17. - No third-party rights under the Contracts (Rights of Third Parties) Act 1999. ## 16. CWR Workbench The CWR Workbench is a free toolset for working with Common Works Registration files: a Validator (structural analysis against the CISAC CWR specification), an Inspector (field-level file viewer), a Generator (form-based .V21 file creation, currently in beta) and an ACK Parser (society acknowledgement response reader). ### What We Keep Files you check, open or read with the CWR Workbench are sent to our server and processed there. We do not keep the files. We keep the result of a check, including the work titles, writer and publisher names, IPI numbers and shares read from the file, for 30 days so that its link can be opened and shared, and then delete it. Section 12 of the [Privacy Policy](https://trackforge.studio/privacy) has the details. ### Generator: Saved Sessions If you choose to save your progress in the Generator, we store your form inputs (work titles, writer names, share percentages) and the email address you give, so that you can resume within 30 days. Generated CWR output files are never retained on our servers. ### Beta Disclaimer The Generator is currently in beta. Output may be incomplete or inaccurate. Always review and validate CWR files before submitting to collecting societies. We recommend using the Validate tab to verify generated output. This tool does not guarantee acceptance by any specific society or PRO. ## 17. TrackForge Workspace TrackForge Workspace is a signed-in service for keeping catalogues of musical works, checking them, preparing Common Works Registration (CWR) files and recording each society's response. It is in beta. You create a workspace yourself by signing in with Google, LinkedIn or a code sent to your email address. Sections 1 and 3 to 7 are about certification and ratings and do not apply to the Workspace. Where this section says something different from the rest of these Terms, this section applies to the Workspace. ### The Beta Offer - The Workspace is free during the beta. No card is needed and nothing is charged. - Each account has one workspace, holding up to 500 works across its catalogues. Email support@trackforge.studio to ask for more. - The beta runs until paid plans start. We will give you at least 60 days' written notice before anything changes, and you will never be charged unless you choose a plan. - If you do not choose a plan when the beta ends, you keep read access and every download (Excel, CSV, JSON and the exact CWR and society response files). Editing and preparing new files stop. ### You Send Your Own Files The Workspace checks your works and prepares files. You can download a file and send it yourself, or have TrackForge send it through your society connection. TrackForge sends a file only when you ask it to and confirm that you are authorised to send those registrations from that account. Either way, you are responsible for what is sent, and for having the right to register the works and to give us the details of the writers and publishers in them. Checks and statuses are findings, not a promise that a society will accept a file. If you add a society connection, TrackForge signs in to the society's file server with its login, to test the connection, to collect the society's responses for your files, and to send a file when you ask it to. If you turn on automatic checks for a connection, it collects the responses about every 12 hours, including while you are signed out, until you turn them off or the login stops working. Use only a login you are authorised to use for this. You can save the login so that you do not type it each time; we then keep it in Google Cloud Secret Manager until you remove it or your workspace is deleted. The Privacy Policy (section 13) says what a connection keeps. ### Your Data You keep all rights in what you put into your workspace, and you can download it at any time. Section 13 of the [Privacy Policy](https://trackforge.studio/privacy) says what we store and for how long. ### Closing and Deletion - You can close your workspace from the Account page at any time. Access stops at once, and everything in the workspace is permanently deleted 30 days later. Email support@trackforge.studio within those 30 days to reopen it, or to have it deleted sooner. - A workspace that has not been used for 11 months gets a warning email to its owner. If it is still unused 30 days after that email, it is closed and deleted. Signing in once keeps it. We do not otherwise delete your data without asking. - We may pause new sign-ups, and may suspend or close a workspace for a breach of section 8. - For the Workspace, this section applies in place of the 90-day download period in section 13. ### A Beta Service The Workspace may change, have faults or be unavailable at times, and features may be added or removed. We take care of your data, but keep your own copies of anything you cannot afford to lose. The downloads are there for that. ### Data Protection Your catalogue holds personal data about other people, such as writers' names, IPI numbers and shares. For that data you are the controller and we are your processor under UK data protection law. We will: - process it only to provide the Workspace and on your instructions, which you give by using the Workspace and by agreeing to these Terms; - keep it confidential, and make sure that anyone at TrackForge who can reach it is bound to do the same; - protect it with appropriate security measures; - use other companies to process it only as listed in section 13 of the Privacy Policy, on terms that protect it to the same standard, and tell you before we add or replace one; - help you answer requests from the people the data is about, and tell you without undue delay if we learn of a breach that affects it; - delete it when your workspace is deleted, as set out above; and - give you the information you reasonably need to show that these commitments are met. For your own account details we are the controller, and the Privacy Policy explains what we do with them. ### Liability Section 9 applies to the Workspace. To the extent the law allows, we are not liable for a society rejecting, delaying or wrongly applying a file you send, for royalties you do not receive, or for a loss of data that you could have avoided by keeping the downloads. While the Workspace is free, the cap in section 9 is GBP 100. ## Contact Adaptive Intelligence (trading as TrackForge), 128 City Road, London, EC1V 2NX. Email: legal@trackforge.studio --- *This document does not constitute legal advice. See the full [legal framework documentation](https://trackforge.studio/docs/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: 3 October 2026 | Last Updated: 23 October 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) - For an account we set up for you: your password, which we store only as a one-way hash - For TrackForge Workspace: your email address and the name you give your workspace. Sign-in is run by Cloudflare, and we hold no password for it (section 13) ### 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) ### Server Logs Our web servers record each request they receive: the time, the address requested, the response, the referring page, your browser's user agent and your IP address. We use this log to investigate faults and abuse. Each server keeps at most about 30 MB of it and overwrites the oldest entries first; in October 2026 that covered about two and a half weeks. ### Error Reports If a page of the CWR tool or of TrackForge Workspace fails, your browser sends us a technical report (the step that failed and the kind of error; a report you choose to send adds your browser family, whether you are on a phone and how many works the page held), which holds no file content, names, email addresses or message text and is stored without your IP address. ### Free Public Tools and API When you, or software acting for you such as an AI assistant, use the free ISRC Lookup, the CWR tool or the public API, we record each request: the ISRCs requested or found, the kind of input, the outcome, the user agent, the origin and referring site, and a keyed one-way hash of the IP address. The IP address itself is not stored in this log. When a request comes through our MCP server, we also record the name and version the AI assistant reports and a pseudonymous session key. ### Report Requests If you ask for a follow-up review, directly or through an AI assistant using our MCP server, we store your name, email address, optional organisation, the ISRCs or catalogue description you give, the consent you confirmed, the AI assistant's name and version, and a keyed hash of the IP address. We use them only to contact you about that request. A person at TrackForge reviews the catalogue before anything is sent to you. ## 2. How We Use Your Data | Purpose | Legal Basis | |---------|------------| | Provide and operate the Service | Contract performance | | Provide TrackForge Workspace: your account, your sign-in and the catalogue you keep in it | Contract performance | | Warn you by email before an unused workspace is deleted | Legitimate interest | | Email you updates from your society connections, if you turn them on | Contract performance | | Answer questions you ask Ask TrackForge in the Workspace | 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 | | Measure use of the free public tools and API, and prevent abuse | Legitimate interest | | Count visits to the website and to TrackForge Workspace, Workspace sign-ups and first use, without cookies, until you answer the cookie banner (sections 9 and 13) | Legitimate interest | | Analytics on the public website | Consent | | Follow up on a report request you asked for | Consent | | Check a CWR file you send us, and keep its result for the link you can share | Legitimate interest | | Answer an enquiry or request you send us | 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, for catalogue audits and certification** -- 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. - **Sources the free public tools ask** -- The ISRC Lookup, the public API and the MCP server ask Spotify about the ISRC or the Spotify track link you give. If you search by title, the title and artist you type are sent to MusicBrainz when our own copy of The MLC's data has no match. If you give a YouTube link, the video's ID is sent to YouTube to read its title. A lookup by ISRC reads our own copies of MusicBrainz's and The MLC's data, so it is not sent to either. These requests come from our server, not your browser, and say nothing about who you are. - **Spotify, for album artwork** -- When the ISRC Lookup page shows a result's album artwork, your browser loads the image directly from Spotify's image servers (i.scdn.co). Like any server a web page loads an image from, Spotify receives your IP address and your browser's details with that request. The page tells your browser not to send the page's address, and we send Spotify nothing about you. Artwork loads only as results come into view, and not at all on screens narrower than 640 pixels. The artwork and Spotify's logo link to the track on Spotify; following one takes you to Spotify. - **Google Fonts** -- Our pages use a typeface served by Google Fonts. Your browser fetches it directly from Google (fonts.googleapis.com and fonts.gstatic.com), which receives your IP address and your browser's details with that request. We send Google nothing else about you. - **Cloudflare** -- Our website and API are delivered through Cloudflare's network. Cloudflare processes every request, including your IP address, to deliver pages, filter abusive traffic and measure how quickly pages load. That measurement (Cloudflare Web Analytics) uses no cookies. For Ask TrackForge in the Workspace, Cloudflare also searches TrackForge's guides, and Cloudflare Workers AI writes the answers, with a model made by DeepSeek that Cloudflare runs on its own network, from the question and the details of your own catalogue that it needs: DeepSeek receives nothing (section 13). - **Voyage AI** -- Ask TrackForge's questions are sent to Voyage AI, in the United States, to search TrackForge's knowledge base of music-rights sources for passages that answer them (section 13). - **Hosting** -- Our servers are in Germany (Hetzner) and our databases are in the EU (Neon). - **Signing in to TrackForge Workspace** -- Sign-in to the Workspace is run by Cloudflare (Cloudflare Access). You choose how to prove who you are: a code Cloudflare emails to you, or your Google or LinkedIn account. If you choose Google or LinkedIn, that company confirms your identity to Cloudflare and passes it your name, profile picture and email address. TrackForge receives only your email address and an account reference from Cloudflare, and uses the email address to find your workspace. We never see your Google or LinkedIn password, and we cannot read or post anything on those accounts. - **Email delivery** -- The emails we send you, such as the warning before an unused workspace is deleted, are delivered by Resend, which receives your email address and the message. - **Email you send us** -- Mail to our addresses is received by Proton, in Switzerland. Mail to support@trackforge.studio is also passed to Inkbox, which holds our support inbox, and is read first by an automated assistant that runs on xAI's Grok. Both companies are in the United States. The assistant may answer you, pass a fault to our engineering assistant without your name or address, or pass your message to a person. A person reads every thread. The assistant cannot see your workspace. Write to privacy@trackforge.studio if you want a person only. - **Bitcoin blockchain** -- Only the Merkle Root hash is published. No personal data. - **OpenTimestamps calendars** -- Hash submitted for timestamping. No personal data. - **Analytics providers, only with your consent** -- PostHog (EU cloud) for product analytics, and Google Analytics 4 delivered through Cloudflare Zaraz, receive page and feature usage from the public website. PostHog also records how pages are used (what is shown and what is clicked); what you type is masked in those recordings. Until you answer the cookie banner PostHog only counts visits, without cookies (in TrackForge Workspace also sign-ups and first use), and if you decline it receives no usage data (section 9). Inside TrackForge Workspace only PostHog runs, on the same consent, and it receives nothing from your catalogue (section 13). We do not sell your personal data. We do not share it with advertisers. ## 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 | | Public tool and API request log | 12 months; the IP address hash is removed after 90 days | | Web server request logs | Until overwritten: each server keeps at most about 30 MB (about two and a half weeks in October 2026) | | Report requests | 24 months after the request, or sooner if you ask us to delete it | | CWR check results and saved Generator sessions | 30 days | | TrackForge Workspace contents | Until you delete them or close the workspace; 30 days after closure; or after 12 months unused, following a warning email (section 13) | | Ask TrackForge questions and answers | Not kept: they stay in your browser tab (section 13) | | Ask TrackForge counts per workspace and month | As long as the workspace's contents | | Details you give to have a CWR report emailed | 24 months after the request, or sooner if you ask us to delete them | ## 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 - **Withdraw consent** -- where we rely on your consent (website analytics and report requests), withdraw it at any time: use the analytics control on the privacy page, or email us > **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, on servers in Germany). Some enrichment queries are sent to international APIs (e.g., Spotify, MusicBrainz, YouTube), the ISRC Lookup page loads album artwork from Spotify's image servers, our pages load a typeface from Google and are delivered through Cloudflare's global network, and, with your consent, analytics data may be processed by Google and Cloudflare outside the UK and EEA. The emails we send are delivered by Resend, a company in the United States, and if you sign in to TrackForge Workspace with Google or LinkedIn, that company confirms who you are to Cloudflare. A society login you save in the Workspace is kept by Google Cloud, a company in the United States, in its London region. A question you ask Ask TrackForge is searched for by Voyage AI, a company in the United States, and answered, with the details of your catalogue it needs, by a model Cloudflare runs on its network. These transfers rely on standard contractual clauses or adequacy decisions as appropriate. ## 9. Cookies The signed-in TrackForge application uses essential cookies for authentication and session management. We do not use advertising cookies. On the public website, analytics (PostHog and Google Analytics 4 through Cloudflare Zaraz) run only after you accept them in the cookie banner. Until you answer the banner, Google Analytics does not run and PostHog only counts visits, without cookies: it stores nothing in your browser and gives you no visitor ID. Each page you open is sent to PostHog with its address, the page you came from, any campaign tags in the link, and your browser's type, language, time zone and window size; no clicks, recordings or profile are kept. To count unique visitors, PostHog's servers combine your network address and browser details with a value that changes every day and is then deleted, and keep only the resulting one-way code, so a visit cannot be traced back to you or linked to another day's visits. PostHog does not keep your network address. If you decline, no usage data is sent to PostHog or Google Analytics, on that visit or later ones. Your choice is kept in your browser so the banner does not ask again. You can accept or decline analytics at any time on the privacy page at [trackforge.studio/privacy](https://trackforge.studio/privacy). The same choice applies in TrackForge Workspace, where only PostHog runs. Until you answer the banner it counts Workspace visits in the same way, and also when an account is opened and when works are first saved into a workspace, with nothing from your catalogue (section 13). The CWR Generator keeps an unsaved draft in your browser's own storage so a reload does not lose it. The public verification page at /verify uses no cookies at all. What the public website stores in your browser: | What | Set by | When | Kept for | Purpose | |------|--------|------|----------|---------| | `cf_clearance` cookie | Cloudflare | Every visit | 1 year | Security: records that your browser passed Cloudflare's check for automated traffic | | `cf_zaraz_client` cookie | Cloudflare | Every visit | 1 year | Belongs to Cloudflare's script loader; it is empty and holds no identifier | | `zaraz-consent` cookie; `tf_consent_v1` in browser storage, and `__ph_opt_in_out_...` there too once you accept | Cloudflare, TrackForge, PostHog | When you answer the cookie banner | 1 year for the cookie; the rest until you clear your browser's storage | Remember your choice | | `ph_..._posthog` cookie and matching entries in browser storage | PostHog | Only after you accept | 1 year; removed if you later decline | Product analytics and recordings: a random visitor ID and details of the visit | | `cfz_google-analytics_v4` and `cfzs_google-analytics_v4` cookies | Cloudflare, for Google Analytics 4 | Only after you accept | 1 year, and until you close the browser; removed if you later decline | Google Analytics visitor and session IDs | | `cwr_generator_draft` and similar entries in browser storage | TrackForge | When you use a tool that keeps a draft | Until you clear the draft or your browser's storage | Keep unsaved work across a reload | | `trackforge.client-incidents.queue.v1` and `trackforge.operational-events.queue.v1...` in browser storage | TrackForge | Only while an error report is waiting to be sent | Until it is sent, and at most 30 days | Deliver the report when the connection returns | What TrackForge Workspace stores in your browser: | What | Set by | When | Kept for | Purpose | |------|--------|------|----------|---------| | Sign-in cookie (`CF_Authorization`) | Cloudflare | When you sign in | Until you sign out or your sign-in expires | Keep you signed in | | `cwr_workspace_recovery...` and `cwr-agreement-draft...` in browser storage | TrackForge | While a work or an agreement has unsaved changes | Until you save or discard them; ignored after 24 hours. They hold what you typed, stay on that device and are not cleared by signing out | Keep unsaved changes across a reload | | `cwr-workspace:last-catalogue...` in browser storage | TrackForge | When you open a catalogue | Until you clear your browser's storage | Reopen the catalogue you last used | | `cwr_workspace_handoff...` in the tab's own storage | TrackForge | When you send works from the CWR tool to your workspace | Until you add or discard them, or close the tab | Carry the works across | | `tf_consent_v1` in browser storage, and the `ph_..._posthog` cookie with matching entries in browser storage | TrackForge, PostHog | Your answer to the cookie banner; the PostHog entries only after you accept | As on the public website (above); signing out gives the PostHog entries a new random visitor ID | Remember your choice; product analytics: a random visitor ID, and your account's reference number once you sign in | ## 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), 128 City Road, London, EC1V 2NX. 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. ## 12. CWR Tool The CWR tool checks CWR files on our server: your browser sends the file to us. We do not keep the file. We keep the result of a check for 30 days, so that its link can be opened and shared, and then delete it. The result holds the file's name and the work titles, writer and publisher names, IPI numbers and shares the check read from the file. Anyone who has the link can open the result until it is deleted. - **Generator saved sessions** -- If you choose to save your progress, we store what you entered (work titles, writer names, shares) and the email address you give, so you can resume. A saved session is deleted after 30 days, or when you clear it. Generated CWR files are not kept. TrackForge Workspace is different: it keeps what you put in it (section 13). - **Reports by email** -- If you ask for a check's report by email, we store your email address, the name and company you give, the file's name, the number of errors the check found and a reference to its result, and our email provider (Resend) delivers the report. We delete them 24 months after the request, or sooner if you ask. - **Through an AI assistant** -- A file checked through the MCP server's `validate_cwr` tool is not stored, and neither is its result. ## 13. TrackForge Workspace TrackForge Workspace is the signed-in service where you keep catalogues of works, check them, prepare CWR files and record society responses. Section 4 describes how you sign in. This section says what the Workspace stores. - **Your account** -- Your first and last name, as you give them when you open your account and can change on the Account page; your email address, as confirmed when you sign in; and the business or publisher name you give your workspace. We take no picture and no name from Google, LinkedIn or any other service. We never receive a password for signing in. We record which version of the beta offer you accepted and when, and when the workspace was last used. - **Your catalogue** -- What you enter or import: work titles and alternative titles, ISWCs and your own work references, writer and publisher names, IPI numbers, society memberships, shares, territories and agreement numbers, performers, and recording details such as ISRCs, labels and release dates. Much of this is personal data about writers. You are responsible for having the right to give it to us, as you are when you send it to a society. - **Files** -- When you import a spreadsheet we keep the rows read from it, not the file. When you import a CWR file, prepare one, or upload a society's response file, we keep the exact file, so that you can download it again and the record of what was prepared and answered stays accurate. - **History** -- Each change to a work is kept with its time and the account that made it. A work you delete leaves your catalogues and can be restored; files already prepared from it, and the responses to them, still show it. - **Your records and settings** -- What you record as sent to a society and when, the societies you choose, and the sender name and codes you enter for your files. - **Checks against US Copyright Office records** -- These run on our own server, against a copy of the Office's public records that we hold. Nothing from your workspace is sent to the Office. - **The search box** -- Going to a section and finding a work, a writer or a publisher are done by our own server. Where we have switched them on for your workspace, two more things use Cloudflare. What you type is sent to Cloudflare AI Search, which searches our help pages and nothing else. Cloudflare keeps recent searches for up to two days to answer a repeated one faster. And if you choose to ask a question about your works, the question and the codes of the societies your workspace has chosen are sent to a language model that Cloudflare runs for us (Workers AI). It turns the question into the works list's filters, and our server then finds the works. The model is sent nothing from your catalogue. Cloudflare states that Workers AI does not keep what it is sent once it is no longer needed for the request, except where it must for legal reasons, and does not use it to train models. Neither what you search nor what you ask is written to our own logs. - **Society connections** -- You can add a connection to a society's file server: ICE's (for PRS for Music and MCPS), The MLC's, or that of another society that gave you an SFTP login. We keep the connection's name, the server's address and folders, the sender name and codes it uses, and when it was last tested or checked and what that found, such as how many files were in each folder. You can save the connection's login, once you confirm that it is your organisation's own and that we may keep it and use it. A saved login is kept in Google Cloud Secret Manager, in Google's London region, not in our database. Google encrypts it where it is stored and logs every time it is read. Our server reads it only to test the connection, check for responses or send a file when you ask, and, if you turn on automatic checks for that connection, to check for responses about every 12 hours, including while you are signed out. Automatic checks stop if the login stops working, and you can turn them off at any time. It is never written to our logs or shown again. Signing out or closing the page leaves it saved. You can replace or remove it at any time, and removing it deletes it from Google. If you delete your workspace (Account page, Close workspace), a saved login is not used unless the workspace is reopened, and is deleted from Google with everything else 30 days later. A login you type without saving it travels encrypted, through Cloudflare, to our server, which uses it for that one request and then discards it. So that a later login can be checked against the same account, we keep a fingerprint of the username, made with a key of ours, from which the username cannot be read back. A test signs in and counts the files in your folders. A check for responses lists the society's response folder and keeps a copy of the society's response files for files sent under your sender code, as it does a response file you upload. It reads no other file and keeps none of their names. Neither changes, moves or deletes anything on the society's server. - **Sending a file to a society** -- You can send a file you prepared to ICE (for PRS for Music and MCPS), to The MLC or to another society that gave you an SFTP login, through your connection, or download it and send it yourself. TrackForge sends a file only when you press Send file and confirm that you are authorised to send those registrations from that account. It uploads that exact file, and nothing else from your catalogue, to the society's server, and removes its own copy there if the upload does not finish. For each send we keep which file it was (by a fingerprint of its contents), the connection and folder it went to, when it was sent, and whether it worked; the send is then recorded against the file as sent. TrackForge sends nothing from your workspace to another customer or anyone else. - **Ask TrackForge** -- Where it is switched on, the Workspace's assistant answers questions from TrackForge's guides, music-rights sources and your own catalogue, and shows which it used. It sends what you type, with the conversation's last few turns, and, when you ask it to explain a problem or a society's response, the society, the record type, the field, TrackForge's rule and the society's message code and words. To answer about your catalogue, our server reads, from the workspace you are working in and no other: the name of each of your catalogues and how many works are saved in it; for the catalogue you have open or, when none is open, all your catalogues together, its counts, what needs doing as the Today screen lists it (the titles of the works that need you, the names of files not yet sent or waiting for a society's response, and imports not finished), and the writers, publishers and artists on its saved works, with their IPI numbers and how many works each is on, and how many recordings and ISRCs it has; the works your question names (by a title, a name, an ISWC, an ISRC or an IPI number), in the catalogue you have open or, when none is open, in all of them; and the work you have open or are explaining. While it writes an answer, the model may also ask our server for more of the same workspace's details, which our server reads, from that workspace alone, without changing anything: the works that match the works list's own filters, such as a state, a society, a writer or works with no ISWC (up to 50 at a time, each with its title, references, ISWC, state and the societies' latest responses); all the writers, publishers and artists with their IPI numbers; everything the Today screen lists; what is holding works up; and, in full, works it has found. It sends those names and counts, and, for each work it reads, the title, your references, the ISWC, the writers and publishers with their IPI numbers, societies and shares, the artists, the recordings with their ISRCs, the work's state, what is left to do on it and the societies' latest responses. Your question, those codes and a society's words are sent to Cloudflare AI Search, to search TrackForge's guides (Cloudflare holds a recent search for up to two days, as it does for the search box), and to Voyage AI, in the United States, to search TrackForge's knowledge base, with the titles and names found in your catalogue taken out and IPI numbers and ISWCs masked; nothing else from your catalogue is sent to them. The question, the conversation, the passages found and your catalogue's details go to Cloudflare Workers AI, which writes the answer with a model made by DeepSeek that Cloudflare runs on its own network. DeepSeek receives nothing. Cloudflare states that Workers AI does not keep what it is sent or writes once it is no longer needed for the request, except where it must for legal reasons, and does not use it to train models; it keeps a computed form of the start of a request, for a time it does not state, so that a later request that starts the same way is answered sooner. We keep no question and no answer: the conversation stays in your browser tab and is gone when you close it or start again. We keep counts for each workspace and month: how many Premium and standard answers it had, what they cost, and how many answers its members marked helpful or not helpful. Under an answer, Send this to TrackForge opens a message to support@trackforge.studio in your own email program, with your question, the answer, its sources and the screen you were on filled in; if you send it, it is handled like any other email you send us (section 4). Our logs hold an answer's kind, size, cost, time and number of sources, and, for each lookup it made, which kind it was, how many lines it returned and how long it took; never the question, what was looked up or anything from your catalogue. Answers are information from the sources shown, not legal advice. The assistant cannot change your catalogue or send anything. - **Analytics, only with your consent** -- If you accept analytics cookies (in the cookie banner, which asks once for the whole site, or on the privacy page), PostHog's EU cloud receives how the Workspace is used: which page and view is open, what is clicked and where clicks repeat, how long pages take, and named steps such as an import started, a file prepared or a response added, with counts, a file's type and size, and whether the step worked. It also records the screen with every piece of text and everything you type masked, so a recording shows the layout and the clicks, never the words. To link your visits it receives your account's reference number, not your name or email address. It receives nothing from your catalogue: no work titles, writer or publisher names, IPI numbers, ISWCs, file names or file contents, and ids and search words are removed from page addresses before anything leaves your browser. Google Analytics and Cloudflare's page measurement do not run in the Workspace. Until you answer the banner, PostHog counts without cookies only, as section 9 describes: each Workspace page you open (its address, with ids and search words removed), that an account was opened, and that works were first saved into a workspace, with how many and whether they came from a spreadsheet, a CWR file, the CWR tool or were typed in. Those counts carry no account reference and no visitor ID. If you decline, none of this is collected. The error reports in section 1 work whatever you choose, and they hold nothing from your catalogue. - **Whose data it is** -- Your catalogue holds personal data about other people, such as writers' names, IPI numbers and shares. You decide what goes into it, so for that data you are the controller and we process it for you, on the terms in section 17 of the [Terms of Service](https://trackforge.studio/terms). If someone named in your catalogue asks us about their data, we will pass the request to you. For your own account details we are the controller. - **Who at TrackForge can see it** -- There is no screen for TrackForge staff to browse your workspace. Our admin's account screen shows your account and how much you use the Workspace: names and email addresses of the people in the workspace, sign-up and sign-in dates, your plan and billing state, and counts such as how many works are saved and files sent. It shows nothing from your catalogue. The people who run the service can reach the database it is stored in. They do so only to fix a fault, to keep the service secure, or when you ask us for help. - **Our notes and actions on your account** -- We may keep private notes about your account, for example of a conversation with you, and we keep a record of each action we take on it, such as blocking or unblocking someone's access, with the date, who acted and why. Both are deleted with the workspace. - **Emails** -- We email the owner of a workspace before an unused workspace is deleted. Our email provider (Resend) receives the owner's email address, the workspace's name and the deletion date. No catalogue data is in the email. If you turn on update emails on the Account page, we email you when a society connection brings an update: a response arrived or needs review, a check could not finish, or automatic checks paused. Resend receives your email address, the workspace's name, the connection's name and the name of the file the update is about. No other catalogue data is in the email. You can turn them off on the Account page or from the link in each email. - **Where it is kept** -- In our database in the EU (Neon), except a saved society login, which Google Cloud keeps in London. - **How long** -- Until you delete it or close your workspace. Closing stops access at once, and everything in the workspace, including prepared files and society responses, is permanently deleted 30 days later. Email support@trackforge.studio within those 30 days to reopen it, or to have it deleted sooner. A workspace that has not been used for 11 months gets a warning email, and is closed and deleted if it is still unused 30 days after that; signing in once keeps it. After deletion we keep one record that holds no names, email addresses or catalogue content: the dates, the reason and how many rows were deleted. Your sign-in account is deleted with the workspace unless it still belongs to another workspace. - **Restore history** -- Our database's own restore history holds deleted data for up to 7 days after it is deleted. - **Your copy** -- You can download your works at any time as Excel, CSV or JSON, and the exact CWR and response files held in your workspace. The rights in section 6 apply to your account details. The companies that handle Workspace data for us: | Company | What it does | Where | |---------|--------------|-------| | Neon | The database your workspace is stored in | Germany | | Hetzner | The servers that run the Workspace | Germany | | Cloudflare | Delivers the site and runs sign-in; where switched on, searches the help, turns a question about your works into filters, and writes Ask TrackForge's answers from the question and the catalogue details it needs or looks up as it writes (AI Search and Workers AI) | Its worldwide network | | Voyage AI | Searches TrackForge's knowledge base for Ask TrackForge; it receives the question, without the titles and names found in your catalogue | United States | | Resend | Delivers the emails we send about your workspace | United States | | PostHog | Product analytics, only if you accept analytics cookies; it receives nothing from your catalogue | EU | | Google Cloud | Keeps a society login you choose to save (Secret Manager) | United Kingdom (London) | --- *See the full [data handling documentation](https://trackforge.studio/docs/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) --- ## support.md # Support > Help with TrackForge's free tools, and who to contact. *Published by [TrackForge](https://trackforge.studio)* --- ## The free tools These tools are free and need no account. - **[ISRC Lookup](https://trackforge.studio/isrc-lookup)** -- check a recording by its ISRC against Spotify, MusicBrainz and TrackForge's copy of The MLC's data. - **[CWR tool](https://trackforge.studio/cwr-tool)** -- create, check and read Common Works Registration (CWR) 2.1 files, and understand society acknowledgement (ACK) responses. - **Public API** -- the ISRC lookup for software. Endpoints and limits are in [auth.md](https://trackforge.studio/auth.md). - **MCP server** -- lets an AI assistant check a catalogue against The MLC, look up a song's writers and publishers, and validate CWR files. Server address: `https://api.trackforge.studio/api/v1/mcp`. What it does and how to add it are on the [MCP server page](https://trackforge.studio/mcp); every tool and limit is in the [MCP server documentation](https://trackforge.studio/docs/ai-assistants/mcp-server). ## Before you write Answers are findings from third-party registration data, as of the date shown with each answer. Registrations and matches made after that date are not reflected, and the underlying data may contain errors. An answer is not a statement of who owns or controls a work, and is not legal advice. MLC answers come from TrackForge's copy of The MLC's bulk data, refreshed weekly. TrackForge does not query The MLC live. An "unknown" or "not checked" answer means the lookup did not finish or the data could not be read. It does not mean the work is unregistered. Please try again. Usage limits for the API and the MCP server are in [auth.md](https://trackforge.studio/auth.md). ## Contact Adaptive Intelligence (trading as TrackForge) is a company incorporated in England and Wales. ### Questions and help Email: hello@trackforge.studio Write here with questions about the tools or their answers, including an answer you think is wrong. ### Personal data and report requests Email: privacy@trackforge.studio Write here about personal data we hold, about a report request you made (including asking us to delete one), or to use your data-protection rights. We respond to data-rights requests within 30 days. You can also complain to the Information Commissioner's Office at [ico.org.uk](https://ico.org.uk). ### Terms, legal notices and abuse Email: legal@trackforge.studio Write here about the Terms of Service, to send a legal notice, or to report misuse of the tools. ## Policies - [Terms of Service](https://trackforge.studio/terms) - [Privacy Policy](https://trackforge.studio/privacy) --- *Copyright Adaptive Intelligence. All rights reserved.* --- Source: [https://trackforge.studio/support](https://trackforge.studio/support) --- ## cwr-tool.md # Common Works Registration (CWR) Workbench > Create Common Works Registration 2.1 files, check and read existing .V21 files, and understand society ACK responses in one free browser workbench. *Published by [TrackForge](https://trackforge.studio) · Last updated 2026-10-20* - **Workbench:** https://trackforge.studio/cwr-tool/workbench - **Supported standard:** Common Works Registration 2.1 Revision 8 - **Supported public file type:** .V21 --- The TrackForge Common Works Registration (CWR) Workbench helps publishers and rights administrators create a CWR 2.1 file, check or read an existing .V21 file, and understand a society acknowledgement response (ACK). ## Choose a task ### Create a registration file Build a Common Works Registration 2.1 file from a form or CSV, then download it for review and submission. **Before you begin:** You will need your sender identity, works, writers, publishers and rights shares. [Open Create](/cwr-tool/workbench?tab=generate) ### Check an existing file Choose a CWR 2.1 source file, check it for structural, field, share and destination-rule problems, then open supported files in the editor to amend them. **Before you begin:** You will need the source registration file you plan to submit or re-submit; society responses belong in Society response. [Open Check](/cwr-tool/workbench?tab=validate) ### Read an existing file Turn a registration file into a readable view of its works, writers, publishers and rights shares. **Before you begin:** You will need the registration file you want to understand. [Open Read](/cwr-tool/workbench?tab=inspect) ### Understand a society response Upload a society acknowledgement response (ACK) to see what was accepted, rejected or needs attention. **Before you begin:** You will need the acknowledgement file returned by the society. [Open Society response](/cwr-tool/workbench?tab=parse-ack) ## Available Workbench features - Create Common Works Registration 2.1 .V21 files from a form or CSV. - Check existing .V21 files for structural, field, share and available destination-profile problems. - Read works, writers, publishers and rights shares from an existing .V21 file. - Understand society acknowledgement responses (ACKs) by accepted, rejected and attention-needed outcome. - Open supported .V21 files in the editor, correct identified issues and download a regenerated file without changing the original upload. - Use plain-language issue explanations with technical evidence kept available under Technical details. - Use all four public tasks without creating an account. - Convert a completed LyricFind spreadsheet into LyricFind’s lyric-1.2 lyrics file or its preferred ownership-1.4 file with ownership and lyrics together, with a review list of rows to fix and values to confirm; uploads are converted and then discarded, never stored. - Keep each work’s lyrics in the CSV template’s optional Lyrics column or on the work itself, and make LyricFind’s lyric-1.2 file from the works you are building; lyrics are never put in the CWR file and are converted and then discarded, never stored. - Give a recording’s release barcode in the CSV template’s Release EAN/UPC column or in the work card; a 13-digit EAN is written into the file as it is, and a 12-digit UPC with a leading 0, which is how the file holds it. ## Destination submission requirements These recipient policies sit outside the CWR file-format checks and must be confirmed before submission. ### CAPASSO Africa If a work includes a sub-publisher or publishing administrator, CAPASSO accepts that party only when it is directly affiliated with, or linked to, CAPASSO. Confirm the relationship before submission. TrackForge can validate the CWR publisher chain but cannot verify that external relationship from the file alone. ## Roadmap The roadmap uses only three states and does not promise a date without an owned delivery commitment. ### Available now Implemented in the public Workbench and backed by a dated release entry. - **Create, check, read and understand responses** — Four outcome-led public tasks cover CWR 2.1 generation, .V21 checking and reading, and society acknowledgement-response review. - **Correct supported .V21 files in the Workbench** — Check a file, open supported content as a pre-filled draft, correct identified issues and regenerate without changing the original upload. Lossy imports stop with preservation blockers. - **Society-led CWR generation choices** — Choose familiar destinations including The MLC, PRS for Music / MCPS via ICE, CMRRA, CAPASSO Africa, ABRAMUS, AllTrack Worldwide, AllTrack US-only, SACEM, SIAE and SGAE. TrackForge states whether it applies recipient-specific checks or the common CISAC Base CWR 2.1 rules. - **LyricFind lyrics files** — Turn a completed LyricFind spreadsheet into the lyric-1.2 lyrics file or LyricFind’s preferred ownership-1.4 file with ownership and lyrics together, with a review list of rows to fix and values to confirm. Uploads are converted and then discarded, never stored. ### In development Actively being implemented, without an unowned delivery date. Nothing is publicly committed to active development right now. ### Exploring A direction under consideration, not a delivery promise. - **Additional recipient-specific checking** — Further destination rules will move forward as current technical guidance and recipient evidence are verified. Direct GEMA generation also depends on CWR 2.2 support because GEMA currently requires that version. - **Public integration access** — A governed way to integrate Workbench capabilities with other systems is being considered. No public API, webhook contract or delivery date is promised. ## Common Workbench questions **What is a CWR file?** Common Works Registration (CWR) is the CISAC file format publishers use to tell collecting societies who wrote and publishes a musical work, how rights are shared, and what should be registered. **What can I do in the CWR Workbench?** The Workbench has four tasks: create a CWR 2.1 .V21 file, check an existing .V21 file, read a file in plain language, and understand a society acknowledgement response (ACK). **Which CWR version and destination profiles does the Workbench support?** The public Workbench creates Common Works Registration 2.1 Revision 8 .V21 files. Society choices include The MLC, CMRRA, AllTrack Worldwide, AllTrack US-only, CAPASSO Africa, ABRAMUS, PRS for Music / MCPS via ICE, SACEM, SIAE and SGAE; the interface states whether recipient-specific rules or CISAC Base checks are being applied. Direct GEMA generation is unavailable because GEMA currently requires CWR 2.2. **What does receiver 000 mean?** Receiver 000 means multiple or unspecified recipients. It remains a valid CWR receiver code, but CISAC Base checks alone do not assess a known recipient’s own profile or prove that one file is ready for every society. **Can I keep lyrics in the same spreadsheet as my works?** Yes. Tick “Include a Lyrics column” when you download the CSV template, and put each work’s lyrics in that column. CWR has no place for lyric text, so lyrics are never put in the CWR file. When any work has lyrics, the LyricFind lyrics file panel below Generate makes LyricFind’s lyric-1.2 file from them, using each work’s Work ID as its SongID. **Does passing validation guarantee society acceptance?** No. A passing result means the named CWR structure and selected destination-profile checks found no blocking issue. A society can apply additional policy or data checks, and only its acknowledgement response confirms the outcome of a submission. ## Scope and limitations - The Workbench does not submit files to a collecting society or promise that a recipient will accept them. - Public generation and checking support Common Works Registration 2.1 Revision 8 and .V21 files; CWR 2.2 is not available. - CWR 2.1 generation is available for CISAC Base, The MLC, CMRRA, AllTrack Worldwide, AllTrack US-only, CAPASSO Africa, ABRAMUS, PRS for Music / MCPS via ICE, SACEM, SIAE and SGAE. A separate PRS-specific checking profile remains available for uploaded files. - The MLC, SACEM, SIAE and SGAE choices currently use CISAC Base CWR 2.1 checks; TrackForge does not yet assess every requirement specific to those organisations. - GEMA currently requires CWR 2.2 for direct CWR submissions, so the CWR 2.1 generator cannot create a direct-GEMA-ready file. - Receiver 000 means multiple or unspecified recipients. Under CISAC Base it does not claim that any named society’s destination-specific requirements were assessed. - Additional society profiles and public integration access remain exploratory until implementation and evidence exist. - The LyricFind lyrics file is not sent to LyricFind: you add your LyricFind login and upload it yourself. - Saving your progress does not keep lyrics: keep them in your spreadsheet’s Lyrics column, or use Save to workspace, where they are kept with each work. ## Help and updates - [Help and plain-language issue explanations](https://trackforge.studio/docs/cwr/problems-and-fixes) - [Dated Workbench updates](https://trackforge.studio/cwr-tool/updates) - [Roadmap](https://trackforge.studio/cwr-tool/updates#roadmap) --- 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 registration-truth layer for music rights* **Tool URL:** https://trackforge.studio/isrc-lookup **Last updated:** 2026-10-14 --- ## 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, album artwork, label, markets, release date, and duration. 2. **MusicBrainz** — the open editorial music database, used for independent verification of recording metadata, and for the works, ISWCs, writers and publishers its editors have linked to a recording. 3. **The MLC (Mechanical Licensing Collective) bulk data feed** — US mechanical rights, ISWC resolution, writer credits, publisher shares, and MLC song codes, as of the snapshot date returned with each result. If Spotify and MusicBrainz disagree about the album, artist or release date, the tool flags it as a conflict. If no MLC work is linked to the recording, or part of its share is unclaimed, 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 and publisher details where available. 6. Export results to CSV (for spreadsheet analysis) or PDF (branded report) if needed. No account is required. MLC results come from The MLC's bulk data feed and show the date they are true as of. Prefer to ask in plain words? Use the same checks from your AI assistant through TrackForge's [MCP server](https://trackforge.studio/mcp). Releasing your own music? Start with the plain-English guide, [Are your songs registered with The MLC?](https://trackforge.studio/check-my-music) --- ## What the Tool Returns For each ISRC you submit, the tool returns: ### Spotify block - Canonical track title, artist, and album - Label - Release date - Duration (minutes:seconds) - Number of available markets - Album artwork: links to the cover image in up to three sizes (typically 640, 300 and 64 pixels wide), hosted on Spotify's image servers. The results page shows a small thumbnail (not on phone-width screens) and the CSV export carries the 300-pixel link. ### MusicBrainz block - Track title and artist credit, the earliest release (album, date and label), and the works MusicBrainz links to the recording with their ISWCs, writers and publishers (with IPI numbers where MusicBrainz has them) - From TrackForge's copy of MusicBrainz's public data, refreshed from MusicBrainz's data dumps twice a month, not a live query - Through the API, a lookup of a single ISRC also returns MusicBrainz's core data for its recordings in full: credits, every release with dates by country, labels and catalogue numbers, related recordings, links and aliases. The MCP server returns the same when asked for the full record - Only MusicBrainz's core data is used, which MusicBrainz dedicates to the public domain (CC0). Its tags, genres, ratings, annotations and cover art links are licensed for non-commercial use only and are not returned - Independent cross-reference against Spotify ### The MLC block - MLC song code of the linked work - ISWC (if The MLC has one for the work) - Work title and the recording artist The MLC lists - Writer names, IPI numbers and roles (no writer shares) - Publisher names, IPI numbers, roles and collection shares as The MLC lists them (the highest share each publisher holds on the work; shares are not adjusted to add up to 100%) - Any share of the recording left unclaimed, any share in dispute, and other MLC works the recording is also linked to ### Conflicts Where Spotify and MusicBrainz disagree on the album, artist or release date (e.g., Spotify says artist "Tyler, The Creator" but MusicBrainz says "Tyler The Creator"), both values are shown. MLC findings (no linked work, an unclaimed share, a share in dispute, more than one linked work, no ISWC) come with a plain-language note. ### Health status Each ISRC is graded. The first grade that applies wins, in this order: - **Critical** — the recording is on Spotify but no MLC work is linked to it (unless it is a recent release, below), The MLC holds usage for it that is matched to no work, or part of its share is unclaimed at The MLC. - **Unknown** — The MLC data could not be checked. Never read this as "not registered". - **Warning** — something to check: Spotify and MusicBrainz list different albums, The MLC holds the recording but links it to no work, no MLC work is linked and Spotify has no record of it, no MLC work is linked to a recent release (released within 60 days before the MLC data's date, or after it, so its registration may not have reached that data yet), a share is in dispute, or the linked work has no ISWC. - **Clean** — an MLC work is linked and none of the above applies. Artist and release-date differences are shown but do not change the grade. Nor does a missing Spotify or MusicBrainz record on its own. The grade stays in the API's results and the CSV; the page's badges, counts and PDF follow the verdict below. ### Verdict Each result also carries a `verdict`: what the registration data shows, dated. - **registered** — linked to one MLC work, nothing unclaimed or disputed. - **partial** — linked, but part of the share is unclaimed or in dispute. - **nobody** — no MLC work is linked to the recording (absent, held by The MLC with no work link, or usage The MLC holds unmatched). This is not proof the work is unregistered: The MLC registers works and matches recordings to them in separate steps. So the tool also checks registered work titles and says which route applies: match the recording to an existing work, or register one. - **conflict** — the recording is linked to more than one MLC work. - **unknown** — The MLC data could not be checked. Never read this as "not registered". On the page each verdict is a badge: **REGISTERED**; **SHARE GAP** (partial); **MULTIPLE WORKS** (conflict); **NO WORK LINKED** (nobody at high or medium confidence); **CHECK LATER** (nobody at low confidence: a recent release, a recording not live yet, or Spotify could not be checked, so The MLC's data may not include it yet; not a finding); and **NOT VERIFIED** (unknown, or the lookup did not finish). Under each row the page shows the verdict's next step, with The MLC's and TrackForge's addresses as links; the CSV carries it too. When several apply, the first in this order wins: unknown, conflict, nobody, partial, registered. A conflict whose linked work also has a share unclaimed or in dispute lists `partial` under `secondary_states`. Each verdict has a confidence, dated evidence items and a one-sentence `next_step` naming the registered process (for example, registering a work with The MLC). It is a finding, not advice about ownership. ### Resolve from a link or title `POST https://api.trackforge.studio/api/v1/isrc-lookup/resolve` accepts exactly one of `isrc`, `spotify_url` (track link or URI), `title` with optional `artist`, or `youtube_url`. It returns the candidate recordings and works, how each was resolved and how confidently, and the verdict for up to five candidate ISRCs. Several equally plausible works are all returned with `ambiguous: true`. Titles are matched against The MLC's bulk data first, with MusicBrainz as a fallback. A YouTube link is resolved from its public video title and is always low confidence. --- ## Features - Single and batch ISRC lookup (a batch is split into requests of 50 ISRCs) - Parallel queries across Spotify, MusicBrainz, The MLC - Automatic conflict detection between sources - MLC registration gap flagging - Writer and publisher details, with publisher shares as The MLC lists them - ISWC resolution from ISRC - CSV export for spreadsheet analysis - Branded PDF report export - No account required - MLC answers dated with the bulk-data snapshot they come from - 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, reads TrackForge's copies of MusicBrainz's data and The MLC's bulk data, and returns metadata, writer and publisher details, 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 your ISRCs, one per line or comma-separated. The tool splits them into groups of 50 and sends two groups at a time; each group has about 45 seconds. An ISRC whose lookup has not finished by then is shown as Not checked: nothing is known about it yet, and you can look it up again. 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:hello@trackforge.studio?subject=TrackForge%20Assay%20Request). ### Is my ISRC data stored when I use this tool? The ISRCs you look up are logged with the result, the browser or client name, the referring site and a keyed one-way hash of your IP address (never the address itself), so we can see how the tool is used. No account, name or email is collected. Spotify is queried live; MusicBrainz data comes from TrackForge's copy of MusicBrainz's public data, and MLC data from The MLC's bulk data feed as of the date shown with each result. ### 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. When no MLC work is linked to a recording, the work may be unregistered, or registered but not yet matched to the recording. The verdict's next step says whether a registered work with the same title exists. ### 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 [hello@trackforge.studio](mailto:hello@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) — Create Common Works Registration 2.1 files, check and read existing .V21 files, and understand society ACK responses in one free browser workbench. - [Why TrackForge](https://trackforge.studio/why) — The case for independent catalogue verification. --- ## Privacy and Disclaimer **Privacy.** Each lookup is logged — the ISRCs requested, the result, the browser or client name, the referring site and a keyed one-way hash of your IP address (never the address itself) — to understand how the tool is used. No account, name or email is collected. **Disclaimer.** This tool queries Spotify and reads TrackForge's copies of MusicBrainz's data and The MLC's bulk data as of the date shown; it 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) --- ## mcp.md # Check your catalogue’s registrations and your CWR files from your AI assistant > Ask your AI assistant which catalogue recordings have no MLC work or an unclaimed share, and whether a CWR file is valid. Free MCP server with ISRC lookup. *Published by [TrackForge](https://trackforge.studio)* **Page:** https://trackforge.studio/mcp **Server address:** `https://api.trackforge.studio/api/v1/mcp` (Streamable HTTP, no sign-in) **Last updated:** 2026-10-07 --- ## MCP server for AI assistants TrackForge’s free MCP server lets your AI assistant check a catalogue of recordings against The MLC, look up a song’s writers and publishers, and validate a CWR file before it is sent. No account and no API key. Tested with Claude and ChatGPT, and built for any assistant that can add a remote MCP server. --- ## What it does - **Check a catalogue against The MLC.** Give it your ISRCs, up to 50 a request. For each recording it says whether The MLC links it to a work and whether a share is unclaimed, and it counts each result. That shows where US mechanical royalties may be going unmatched or unclaimed. - **Look up one song.** One ISRC, Spotify link or title. It returns the recording’s MLC verdict and, from MusicBrainz, the song’s ISWCs, songwriters and publishers with their IPI numbers, and its first release. - **Validate a CWR file.** Paste the CWR 2.1 file you are about to send to a society. It reports every error and warning with the line, the rule and how to fix it. Files up to 256 KB; larger files go through the CWR Workbench. - **Ask for a person.** If you want someone at TrackForge to look at your catalogue, say so and agree to be contacted. Your name and email address are recorded and a person replies by email within two working days. You get a free summary of what the registration data shows for your catalogue, for up to 500 recordings: how many have no linked work, how many have an unclaimed share, and which to look at first. If you want more, we quote a fixed fee for a full report before any work starts. Nothing is charged and nothing is filed on your behalf unless you agree to it. Nothing is sent automatically. --- ## What you can ask Real answers from the server, shortened. Your assistant puts them in its own words. ### “Check my catalogue against The MLC. How many of these recordings have no linked work, and how many have unclaimed shares?” - **Checked:** 300 recordings - **No linked work:** 102 - **Unclaimed share:** 67 - **Registered, nothing unclaimed:** 111 - **MLC data as of:** 29 September 2026 From a sample of 300 recordings, not a client’s catalogue. Each recording also gets its own verdict. ### “Here is the CWR file I am about to send. Is it valid, and what should I fix?” - **Result:** Not valid: 1 error and 1 warning in 1 transaction - **Line 3, error:** Work title is blank. Every NWR/REV record must have a non-empty work title (positions 20-79). - **Line 4, warning:** Publisher IPI Name # fails its check digits. That normally means a typo or a transposed digit. A test file with its title removed. A valid result does not guarantee that a society will accept the file. ### “Is ISRC USIR20400274 registered with The MLC, and is any share unclaimed?” - **Verdict:** registered, high confidence - **Evidence:** Linked to MLC work M1972U, “MR. BRIGHTSIDE”, ISWC T0721040692 - **MLC data as of:** 29 September 2026 ### “Who wrote the song on that recording, and which label first released it?” - **Writers:** Brandon Flowers and Dave Keuning, each with an IPI number - **Publishers:** The Killers Publishing; Universal Music Publishing Ltd. - **First release:** “Mr. Brightside”, 29 September 2003, Lizard King Records, catalogue number LIZARD007X - **Source:** MusicBrainz ### How to read a verdict Every recording gets one of five verdicts. An MLC answer always carries the date its data is true as of, and a next step when there is something to do. - `registered` -- Linked to one MLC work, with nothing unclaimed or in dispute. - `partial` -- Linked to one MLC work, and a share is unclaimed or in dispute. - `nobody` -- No MLC work is linked to the recording. The answer says whether to match it to an existing work or register one. - `conflict` -- Linked to more than one MLC work. - `unknown` -- The data could not be read. Never a negative finding. --- ## Having a publisher does not mean your songs are registered A publisher or administrator on record shows a relationship, not a finished registration. The MLC pays US mechanical royalties from streaming and download services only when a recording is linked to a registered work with its shares claimed. This server checks that link, recording by recording. --- ## How to add it ### Any AI assistant Look in your assistant’s settings for connectors, integrations, tools or MCP servers, and add a custom one with these three settings. - **Address:** `https://api.trackforge.studio/api/v1/mcp` - **Connection type:** Streamable HTTP. Some assistants call it a remote MCP server or an HTTP server. - **Sign-in:** None. Leave any sign-in, OAuth or API key field empty. Steps for the assistants TrackForge has tested are below. ### Claude Tested 3 October 2026 on claude.ai. 1. In Claude, open Customize, then Connectors. 2. Select Add, then Add custom connector. 3. Give it a name, such as TrackForge, paste the server address and select Continue. Claude shows No sign-in as detected. Select Add. 4. On the connector’s page, select Connect. 5. Ask your question in a new conversation. The first time each tool is used, Claude asks whether to allow it. Claude's connectors page: https://claude.ai/customize/connectors Custom connectors are available on Free, Pro and Max plans; the Free plan allows one. On Team and Enterprise plans an Owner adds it under Organization settings, Connectors, and members then select Connect. ### ChatGPT Tested 5 October 2026 on chatgpt.com. 1. In ChatGPT, open Settings, then Security and login, and turn on Developer mode. 2. Open Plugins, select the plus button, then Create custom MCP server, then Create MCP App. 3. Give it a name, such as TrackForge, paste the server address and set Authentication to No Auth. 4. Tick “I understand and want to continue”, select Create, then Connect. 5. In a new conversation, select the plus button, type TrackForge and choose it. Then ask your question. Developer mode was available on a Free plan when tested; OpenAI lists it for Plus, Pro, Business, Enterprise and Education accounts. To have a list of recordings checked together, ask for the catalogue check by name. ### Command-line assistants Tested: Claude Code on 3 October 2026 and Codex CLI on 5 October 2026. One command adds the server. Claude Code: ```bash claude mcp add --transport http trackforge https://api.trackforge.studio/api/v1/mcp ``` Codex CLI: ```bash codex mcp add trackforge --url https://api.trackforge.studio/api/v1/mcp ``` --- ## Limits and privacy Free. One conversation can check up to 600 recordings every five minutes and 6,000 a day. A catalogue request takes up to 50 recordings and a CWR file up to 256 KB. Each call is logged for usage measurement: the tool, the kind of input, the ISRCs, the outcome and the assistant’s name, with a one-way hash of the address rather than the address itself. Titles, artist names and CWR file content are not logged. Contact details are stored only when you ask for a follow-up. The full terms are in the [Privacy Policy](https://trackforge.studio/privacy) and the [Terms of Service](https://trackforge.studio/terms). ### What it is not - Answers are findings from registration data as of the date shown. They are not legal advice and not a statement of who owns a song or who may use a recording. - The registration check reads The MLC’s data, which covers US mechanical royalties. It holds no PRS for Music, PPL or SoundExchange data. - Writer, publisher, ISWC and release details come from MusicBrainz’s public-domain core data, which its community edits: evidence, not proof. - A Spotify link is used only to find the recording’s ISRC. Spotify’s own data is not returned. - TrackForge is independent of Anthropic, OpenAI, The MLC, MusicBrainz and Spotify, and none of them endorses this server. --- ## Questions ### How do I check a catalogue against The MLC with an AI assistant? Add the TrackForge MCP server (https://api.trackforge.studio/api/v1/mcp) to your assistant, give it the catalogue’s ISRCs and ask how many recordings have no linked work and how many have an unclaimed share. Each request takes up to 50 ISRCs and returns a verdict for every recording, a count of each verdict and the date the MLC data is true as of. One conversation can check up to 600 recordings every five minutes. ### What is the TrackForge MCP server? A free remote MCP (Model Context Protocol) server at https://api.trackforge.studio/api/v1/mcp. It gives an AI assistant three checks: a catalogue registration check against The MLC’s data, a song lookup by ISRC, Spotify link or title that returns the song’s ISWCs, writers and publishers, and CWR 2.1 file validation. A fourth tool lets you ask a person at TrackForge to follow up. Answers are findings from registration data, not legal advice and not a statement of who owns a song. No account or API key is needed. ### Can it check a CWR file before I send it? Yes. Paste the text of a CWR 2.1 file, up to 256 KB, and ask whether it is valid. The answer lists each error and warning with its line, the rule it breaks and how to fix it. A valid result does not guarantee that a society will accept the file. Larger files go through the CWR Workbench at trackforge.studio/cwr-tool. ### Which AI assistants can use it? Any assistant or app that can add a remote MCP server by its address: it uses the open Model Context Protocol over Streamable HTTP and needs no sign-in. Tested with Claude and Claude Code on 3 October 2026, and with ChatGPT and Codex CLI on 5 October 2026. ### How do I check whether a song is registered with The MLC using Claude? Add https://api.trackforge.studio/api/v1/mcp as a custom connector in Claude under Customize, Connectors, then ask with an ISRC, a Spotify track link or a song title. The answer gives a verdict (registered, partial, nobody, conflict or unknown), the date the MLC data is true as of, and a next step when there is one. ### Where does the data come from, and how current is it? MLC answers come from TrackForge’s copy of The MLC’s public bulk data, refreshed weekly, and every answer carries the snapshot date. Writer, publisher, ISWC and release details come from TrackForge’s copy of MusicBrainz’s public-domain core data, refreshed about twice a month. The server never queries The MLC live. --- ## Help and documentation - [MCP server documentation](https://trackforge.studio/docs/ai-assistants/mcp-server) -- Every tool, input and limit, and how to read each verdict. - [auth.md](https://trackforge.studio/auth.md) -- The same details in a form for automated clients. - [ISRC Lookup](https://trackforge.studio/isrc-lookup) -- The same checks in your browser, with CSV and PDF export. - [CWR Workbench](https://trackforge.studio/cwr-tool) -- Create, check and read CWR files in the browser, including files over 256 KB. - [Support](https://trackforge.studio/support) -- How to read an answer, and who to contact. - [Registry entry](https://trackforge.studio/.well-known/mcp/server.json) -- The server’s description for MCP registries: studio.trackforge/music-registration-check. ## Continue reading - [ISRC Registration Gaps](https://trackforge.studio/research/isrc-registration-gaps) -- How the gap between Spotify coverage and MLC work registration leaves mechanical royalties unpaid. - [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy) -- Works with unclaimed US mechanical royalties at The MLC, cross-referenced against other sources. - [What is CWR?](https://trackforge.studio/docs/cwr/) -- The Common Works Registration format, and how a work reaches a society. --- Source: [https://trackforge.studio/mcp](https://trackforge.studio/mcp) --- ## check-my-music.md # Are your songs registered with The MLC? > Free check for independent artists and songwriters: see whether The MLC links each of your recordings to a registered song and whether a share is unclaimed. *Published by [TrackForge](https://trackforge.studio)* **Page:** https://trackforge.studio/check-my-music **The check:** https://trackforge.studio/isrc-lookup (free, no account) **Last updated:** 2026-10-14 --- ## Free check for artists and songwriters If you write your own songs and release them through a distributor, one of your royalties from streaming in the United States, the mechanical royalty, is paid through The MLC. It can pay you only once the song is registered, your share is claimed and your recording is matched to it. This free check reads The MLC’s public data and shows, recording by recording, whether a song is linked and whether any share is unclaimed. No account and no email address. An ISRC is the 12-character code for one recording, such as GBAYE0601498. Paste one or as many as you like. Your results open in TrackForge’s ISRC Lookup, where you can save them as a CSV or a PDF. [Check these recordings](https://trackforge.studio/isrc-lookup) --- ## Where to find your ISRCs Every recording you release has an ISRC. It identifies that one recording wherever it is played, and it is how The MLC’s data is searched here. Your distributor either gave each track an ISRC or asked you for one when you uploaded it. Look at the release or track details in your distributor account, or in the royalty reports it sends you. If you cannot find them, ask its support team for a list. No ISRCs to hand? Your AI assistant can check a song by its title or a Spotify link through TrackForge’s free MCP server. [How to add it](https://trackforge.studio/mcp#add) --- ## Releasing a song does not register it A distributor delivers your recordings to the streaming services and pays you for the recordings. The song itself, the words and music, earns separately, and that money takes a different route. In the United States, the mechanical royalty for streams and downloads goes from the services to The MLC (the Mechanical Licensing Collective). The MLC pays it to whoever has joined as a Member and registered the song: a publisher, a publishing administrator, a collecting society outside the US, or you, if you look after your own songs. If nobody has done that for a song, or your recording has not been matched to it, the money stays with The MLC as unmatched or unclaimed. That is usually an admin gap, not anybody’s wrongdoing: a service you assumed had registered the song, a co-writer’s share that nobody claimed, or a recording that was never linked. A performing rights organisation such as ASCAP or BMI collects a different royalty, for public performance. Joining one does not register your songs with The MLC. If you belong to a mechanical rights society outside the United States, such as MCPS in the UK, it may already collect these royalties for you: ask it, and use the check to see what has reached The MLC’s data. --- ## What each result means Each recording gets one of six results. A result is a finding from The MLC’s public data as at the date shown with it, not a statement of who owns a song. - **REGISTERED** -- The recording is linked to one registered song, with no share unclaimed or in dispute. Nothing is missing in this data. - **SHARE GAP** -- The recording is linked to a song, but part of the song is unclaimed or in dispute. The royalties for that part are being held. - **NO WORK LINKED** -- The MLC’s data links no song to this recording. Either the song is not registered, or it is registered and this recording has not been matched to it. Under each result, the lookup gives the next step for that recording. - **MULTIPLE WORKS** -- The recording is linked to more than one song in The MLC’s data, so which registration applies is unsettled. - **CHECK LATER** -- Nothing is linked yet, but the release is recent or could not be confirmed, so The MLC’s data may not include it yet. Check again after the next weekly update. - **NOT VERIFIED** -- The data could not be read for this recording. That is not a finding either way: run it again. --- ## What to do about a gap - **You have a publisher or a publishing administrator.** That includes a publishing service you signed up for alongside your distribution. Send them the recordings that show a gap and ask them to register the songs or match the recordings. The CSV or PDF of your results is made for this. - **You look after your own songs.** Join The MLC as a Member, register your songs with your share, and match your recordings to them in its portal. The MLC says there is no cost to join, and a songwriter can join as an individual without setting up a company. - **The gap is a co-writer’s share.** Tell them. Each writer’s share is claimed by that writer or by whoever administers their songs, so you cannot claim it for them. [Membership on The MLC’s site](https://www.themlc.com/membership) TrackForge does not register songs with The MLC for you. The check is free, and what you do with the result is up to you. --- ## Why it is worth checking before February 2027 The MLC has said it intends to begin what it calls market share distributions in April 2027. Royalties that are still unmatched or unclaimed for a month of use will be shared out among the Members it has already paid, in proportion to those payments. It plans to start with what remains from January 2021 and then take one month at a time. For the first of these it will use its records as they stand on or about 10 February 2027. The MLC recommends registering, claiming and matching well before that date. A share can still be claimed afterwards. But under The MLC’s policy a completed distribution is final: money already shared out for a month is not paid a second time. These are The MLC’s stated plans as read on 13 October 2026, and it may change them. It has not given a date for royalties from before 2021. [The current dates on The MLC’s site](https://www.themlc.com/marketshare) --- ## What this check covers - It reads TrackForge’s copy of The MLC’s public data, refreshed weekly. Every result shows the date the data is true as of. - It covers mechanical royalties from streaming and downloads in the United States only. It holds no data from PRS for Music, PPL or SoundExchange, and says nothing about performance royalties or the money your distributor pays you. - A result is a finding from registration data. It is not legal advice and not a statement of who owns a song. - TrackForge is independent of The MLC, and The MLC does not endorse this check. Each lookup is logged: the ISRCs, the result, your browser’s name, the site you came from and a keyed one-way hash of your IP address, never the address itself. No name or email address is collected. The lookup also asks Spotify about each ISRC, to name the recording. The full terms are in the [Privacy Policy](https://trackforge.studio/privacy) and the [Terms of Service](https://trackforge.studio/terms). --- ## Questions ### How do I check whether my song is registered with The MLC? Paste the ISRC of your recording into the box on this page and select Check these recordings. The result says whether The MLC’s data links the recording to a registered song and whether any share is unclaimed. You can also search for a song by its title in The MLC’s own Public Work Search. ### I release through a distributor. Does it collect my songwriting royalties? A distributor pays you for your recordings. Songwriting royalties are separate. Some companies that distribute recordings also sell a publishing administration service: if you signed up for one, it generally registers your songs with The MLC for you, and this check shows whether the registrations are there. If you did not, you look after your own songs, and nobody registers them unless you do. ### Does it cost anything to join The MLC? No. The MLC says there is no cost to become a Member. A songwriter who looks after their own songs can join as an individual, without setting up a company. ### I am already a member of ASCAP or BMI. Are my songs covered? Not for this royalty. ASCAP and BMI collect performance royalties. In the United States the mechanical royalty from streaming and downloads is paid through The MLC, which is a separate membership and a separate registration. ### What happens to unclaimed royalties in April 2027? The MLC has said it intends to begin market share distributions in April 2027, starting with royalties that remain unmatched or unclaimed from January 2021 and then taking one month at a time. For the first, it will use its records as they stand on or about 10 February 2027. Under its policy a completed distribution is final. These are its stated plans as read on 13 October 2026; its own site has the current dates. ### I do not know my ISRCs. What can I do? Look at the release or track details in your distributor account, or in the royalty reports it sends you, or ask its support team for a list. Without an ISRC, an AI assistant connected to TrackForge’s free MCP server can check a song by its title or a Spotify link. ### Does TrackForge register my songs or take a share of what I recover? No. The check is free and needs no account. TrackForge does not register songs with The MLC for you: you, your publisher or your administrator do that with The MLC directly. --- ## More from TrackForge - [ISRC Lookup](https://trackforge.studio/isrc-lookup) -- The check itself, for one recording or a whole list, with CSV and PDF export. - [For AI assistants](https://trackforge.studio/mcp) -- Ask your AI assistant to check a song by its title, a Spotify link or an ISRC. - [TrackForge Workspace](https://trackforge.studio/workspace) -- For publishers and administrators: keep your works and track each society. Free during the beta. ### Continue reading - [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy) -- Works with unclaimed US mechanical royalties at The MLC, cross-referenced against other sources. - [ISRC Registration Gaps](https://trackforge.studio/research/isrc-registration-gaps) -- How the gap between Spotify coverage and MLC work registration leaves mechanical royalties unpaid. - [Support](https://trackforge.studio/support) -- How to read an answer, and who to contact. --- Source: [https://trackforge.studio/check-my-music](https://trackforge.studio/check-my-music) --- ## research/unclaimed-economy.md # The Unclaimed Economy > 4.25 million musical works hold unclaimed US mechanical royalties at The MLC, checked against 12 sources. 67.5% are registered at ASCAP; 73% stream on Spotify. *Published by [TrackForge](https://trackforge.studio) — 2026-03-07, updated 2026-07-19* *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 stream on Spotify with no mechanical work at The MLC. 94.7% of one catalog matched on Spotify; only 50% had an MLC work. A 45-point gap. *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. A 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)* --- ## research/rowntree-v-prs.md # Rowntree v PRS: The £3 Line > Rowntree v PRS: why the Court of Appeal held black box royalties cannot be litigated back, the £3 matching floor it revealed, and what actually works instead. *Published by [TrackForge](https://trackforge.studio) — 2026-07-28* The Court of Appeal has explained why black box royalties cannot be litigated back — and in doing so, put the most useful description of the unmatched-royalty machinery ever written onto the public record. The trade press ran the headline and moved on. The valuable material is in the twenty-one pages almost nobody will read. This note is a guided tour. On 29 June 2026 the Court of Appeal dismissed the attempt by Dave Rowntree — drummer of Blur, and a songwriter member of PRS — to bring a collective claim over so-called black box royalties on behalf of roughly 165,000 UK songwriters. The claim put up to £200m in issue. It did not survive its first contested hearing, and the appeal changed nothing. The result was widely reported as a celebrity defeat. That framing misses everything useful in the judgment. Miles LJ's twenty-one pages contain the clearest account any court has given of how unidentified royalties actually arise, why no downstream legal mechanism can reach them — and, almost in passing, operational detail rights-holders have wanted for years, including the **£3 threshold that decides whether a human being ever investigates an unmatched royalty**. TrackForge works on exactly this machinery, so we read the whole judgment. What follows is what a catalogue owner, manager, or acquirer should take from it — with paragraph references throughout, so you can check us against the court. ## What did the court actually decide? A strike-out upheld — with the claimant's central premise assumed to be true. Mr Rowntree applied for a collective proceedings order under the Competition Act 1998 — the UK's class-action mechanism — on behalf of every PRS songwriter member since 9 March 2017. The target was PRS's rule for distributing *unidentified royalties*: money the society collects but cannot match to the right member, because the information needed to match it is missing or wrong (§8). Under PRS's rules that pool is shared out *pro rata* — in proportion to each member's matched royalties (§9). The claim alleged this is an abuse of dominance under the Chapter II prohibition of the Competition Act: data failures are said to fall more heavily on writers than on publishers, so a pro rata share-out systematically short-changes writers as a class (§10, §66). The Competition Appeal Tribunal struck the claim out, granted summary judgment against it, and refused certification in August 2025. The Court of Appeal has now upheld that decision on every point it needed to reach (§103). **No trial happened. No facts were found.** What makes the judgment more interesting than the headline is §33. For strike-out purposes only, PRS accepted that the court should *assume the claim's central premise to be true* — that a larger proportion of the unidentified pool would, absent data failures, have been payable to writers. The court assumed exactly that, and the claim still failed (§87–88). It did not die on its facts. It died on its structure — and the structural reasons are where the value is. ### What the case's numbers are — and are not | Figure | What it actually is | |---|---| | £3 | PRS's threshold floor for seeking to match revenues manually — lowered from an earlier £5 (§72) | | ~£55m | PRS's estimate of unidentified royalties distributed to publisher members over the class period (§50) | | +£150m | Further sum the claimant contended reached publishers directly via foreign societies and online licensing — asserted, never tested (§50) | None of these figures is "the UK black box." The £55m covers one society, one right, one distribution rule, over roughly eight years — and it was recited in court, with its provenance on the record. Industry estimates of the wider unallocated pool run far larger, but they measure a different and looser object. Knowing exactly which number you are holding is most of the discipline in this field. ## Why can the black box not be litigated back? Because a court cannot compare the actual distribution with a fairer one without the very data whose absence created the pool. The argument that killed the claim runs in four steps. It is worth following exactly, because it applies to every future attempt of this kind — not just this one. 1. **Unfairness is relative.** To say a distribution rule is abusively unfair, you must compare it with a realistic, lawful alternative. Counsel for the claimant accepted this (§77–78). 2. **The obvious comparator is disqualified by construction.** The pleaded comparison was against the "true distribution" — what every member would receive in a world of perfect data. But if PRS had that data, there would be no black box at all (§79). The true distribution is "by definition unknown and unknowable" (§68). 3. **Any alternative rule must be more accurate — which needs the same missing data.** A "fairer" counterfactual means one closer to true entitlements (§95). Closer requires information that was never captured. 4. **Litigation cannot capture it retrospectively.** Disclosure produces documents that exist. It cannot produce identifiers that were never attached. "There is no realistic basis for thinking that the processes of litigation will unearth more information, so the deficit will remain" (§85). Hence the sentence at the centre of the judgment: the very data failure that gives rise to the pool "means that there is no plausible basis for suggesting a more accurate (let alone fairer) distribution" (§84). The claim consumed itself. The pool exists because nobody can know whose money it is — and nobody can litigate it back, because litigation runs on precisely the knowledge whose absence created the pool. Put bluntly: **courts cannot manufacture information.** An appellate court has now said so in terms. Everything downstream of a data failure — damages theories, injunctions, classes — arrives too late, because there is nothing left for the law to grip. The court also stress-tested the only alternative rule anyone floated: dividing the pool equally per member. Its own example disposes of it (§80). Some writers — Ed Sheeran was the court's example — have works played billions of times; a large number of members have registered works almost never played. Equal division would take from the first group to give to the second. A rule advertised as pro-writer would injure much of the class it claims to serve. > "Statistical probabilities are not the same as entitlements." — Miles LJ, §90 That line deserves a place in every rights conference deck. Even if writers on average suffer more data failure than publishers — remember, the court assumed they do — no individual writer can point to any given pound in the pool and show it was theirs (§90–91). Averages describe a class; entitlements attach to works. The claim fell into the gap between those two things, and the gap cannot be bridged from either side. ## The bank that forgot your account — revisited The Court of Appeal has shown exactly where our favourite analogy breaks. The break is the whole point. In an earlier TrackForge briefing, [The Black Box Problem](https://trackforge.studio/black-box), we described unmatched royalties with a bank analogy: an IT migration silently breaks the link between your name and your account; money keeps arriving; the bank no longer knows it is yours. As an account of how matching failures happen — and how they feel from the outside — we stand by it. But the judgment exposes the step where the analogy fails, and the failure is instructive. A bank account has a name and a balance, so a court can order the bank to give your money back: the ledger itself knows the answer. The unmatched pool has balances and no names. The black box "arises from data failures; in other words from conditions of ignorance" (§67), and so "none of the members can properly claim that any given amount of the black box royalties 'belonged' to or was 'owned' by them" (§68) — not individually, and not by assembling into a class. There is no ledger entry that says the money is yours. That is what "unidentified" means. The missing ledger is not an obstacle to the claim. The missing ledger *is* the black box. This has a blunt commercial consequence. Any service selling "we recover your share of the black box" is now selling something the Court of Appeal has held to be conceptually incoherent — there are no shares in the pool, and no mechanism, legal or administrative, that pays them out. What exists is narrower and better: evidence that specific works, with specific identifiers, are failing to match — and a system that pays work-by-work when the failure is repaired (§85, §92). We have updated our own language to match, and we suggest the industry does the same. One further correction the judgment invites: the pool is not opaque by design. PRS's preferred term is "unidentified royalties," and the court noted there is no suggestion of a transparency failure — the problem is the absence of information, not the concealment of it (§8). The box is not black because someone painted it. It is black because nobody wrote the label. ## What is the £3 line? The society's manual-matching floor — examined in court for the first time. Paragraph 72 contains the operational disclosure of the case: PRS applies "a threshold floor of £3 for seeking to match revenues manually," lowered from an earlier £5. Automated matching runs on everything; the floor governs what happens after the machine fails. The society's published distribution policy supplies the rest of the mechanics: usage that defeats the automated match is passed to a human only once its value for a single work reaches £3 — below that, the data is held to accumulate. And if, after three years, a work's accumulated value still has not reached £3, the usage is deemed *non-distributable*: the money is folded back into everyone else's matched distributions, without ever appearing on an unclaimed list. The court treated the floor as legitimate institutional design. Weighing the cost of further matching effort against the value recovered is expressly the Distribution Committee's job (§13, §72) — and, decisively, the claimant conceded there was no allegation that PRS had struck the balance in the wrong place (§73). So no court has held that £3 is the right number. The court held something more useful: the number is a governance question, not a judicial one. Here is what the floor does *not* mean. It does not mean PRS is ignorant of what small usages are worth. It knows to the penny — it must, because a pool cannot be shared out pro rata until every line in it has been valued. The unknown was never the amount. It is the owner. Which reframes what the £3 actually prices. Machine-matching a 30p line costs the same as machine-matching a £3,000 line: effectively nothing. What costs money is a human repairing broken data by hand — searching registrations across societies, resolving conflicting records, corresponding with members — to place £1.80. A society spending £20 of its members' money on each £2 recovery would be destroying value, and it rationally declines to. **The £3 floor is not the cost of matching. It is the market price of bad metadata.** And that price is paid asymmetrically. The society faces the repair cost *per line*: it can only research failures one at a time, after the fact, forever. A rights-holder faces it *per catalogue*: correct the registration once — the right ISWC on the work, the right IPI number against every writer and publisher, a share picture that agrees with itself everywhere — and every future usage line, at every society, matches automatically at machine cost. Same failure, two economies. PRS triaging at £3 is rational. A catalogue owner tolerating the triage is not. Consider a working catalogue of 5,000 compositions whose usage arrives as 40p, £1.20, £2.50 lines — radio spins, public performance, long-tail streaming, foreign remittances. Works that keep earning will eventually accumulate past £3 and buy a manual *attempt* — an attempt, not a repair, and only as good as the underlying data allows. The long tail that accrues less than £3 in three years is simply extinguished: non-distributable, redistributed, never listed. In aggregate the catalogue is leaking real money at every distribution, and the Court of Appeal has now confirmed the system is allowed to work this way. The only actor with an incentive to fix a thousand £2 failures is the owner of all thousand — because for the owner it is not £2, it is the catalogue. Note the direction of travel: the floor fell from £5 to £3 as matching tools improved. It is a dial set by data-quality economics, not a law of nature — and the productive response is not to argue with the dial but to make it irrelevant. Clean data never meets the floor. ## Where was the other £150m? On the claim's own arithmetic, roughly three-quarters of the alleged pool never touched PRS — and sits beyond the reach of any UK court order. Follow one song through the system and the geography of the case becomes clear. A work by a PRS writer is played on French radio. SACEM, the French society, collects from the station under its blanket licence. From that moment the money splits onto two roads (§19, §29). **The writer's share takes the long road.** SACEM matches the work in its own database, remits the writer share to PRS under their reciprocal agreement, and PRS matches it again against its own records before paying the member. Two matching engines, two databases, one border crossing — and a chance to fail at every step. **The publisher's share takes the short road.** It is typically paid out in France — to the publisher's local sub-publisher, or to the publisher directly. It never touches PRS at all. Much of multi-territorial online licensing works the same way (§30, §50). Now break the data at SACEM: no ISWC linked, a wrong writer IPI, a title spelled differently from the registration. The money cannot be matched, so it enters SACEM's unidentified pool and is eventually distributed under SACEM's rules. From London the failure is invisible — no remittance ever arrives, so there is nothing in PRS's books to notice. The money is not in PRS's black box. It is in a French one. That is the anatomy of the case's own arithmetic. PRS's £55m estimate covered only the pool it held and distributed itself. The claimant's further £150m — a contention, never tested — sat in the direct-payment channels: foreign societies and online licensing structures that pay publishers without routing through PRS (§50). Even a total claimant victory, damages and injunction included, would have reached roughly a quarter of the problem it alleged. A UK court can only order a UK defendant to redistribute money the defendant actually has. Offshore, there is not even a governance lever. A UK writer is not a member of SACEM or GEMA, cannot petition their boards, and cannot realistically litigate in every territory where a work earns. The only instrument that operates inside a foreign society's matching engine is the data it receives: the ISWC on the work, the IPI of every interested party, registrations that agree with each other across the international network. Get those right at source and they propagate to every hop. Get them wrong and the work fails independently, in parallel, in every territory — invisibly. > A correct registration crosses borders. A court order does not. One more wrinkle: because writer money from abroad passes two matching engines and publisher money often passes none, the visible UK pool structurally understates the writer-side problem. That was, ironically, the claim's own premise — and it is an infrastructure observation the judgment leaves fully intact. ## What did the court say does work? While closing the litigation route, the judgment describes the working one — in a sentence built to be overlooked. **The sentence to keep — §85:** "Where it has been able to obtain the data or correct errors in the records it makes matched distributions." That is the entire remedy, stated by the Court of Appeal: supply the data, or correct the record, and the machinery pays. This is not a favour the society may grant. Work-by-work distribution to the individual members with an interest in each work is the system's governing principle — how PRS is designed to operate, and what the court credited it for doing wherever data permits (§69, §92, §97). There are no writer pots and no publisher pots; there are works, shares, and identifiers (§92). A rights-holder who repairs the record is not petitioning the system. They are invoking it. The judgment even hands over the diagnostic frame. Matching fails at one of three stages: identifying the work from usage data; establishing the share picture — who holds what; or locating payment details (§27). The evidence in the case was that none of the pool in the relevant period failed at the third stage. The entire black box, on the record before the court, is stage one and stage two — work identification and ownership data. Both live in information the rights-holder controls. | Object | Route | Detail | |---|---|---| | The rule | Governance | Changing how the pool is distributed is a Members' Council question — writers hold equal representation on the Distribution Committee (§13). The Tribunal noted no class member had even attempted the internal route (§53). | | The money | Data | Keeping your works out of the pool is a registration question — correct ISWCs, IPIs, and shares, consistent in every territory. The system then pays work-by-work (§85, §92). | | Litigation | Closed | Cannot change the rule — no lawful counterfactual can be built (§84). Cannot reach the money — no entitlement exists without the data (§68). | **The claim that sued itself.** PRS is a non-profit: members' money in, members' money out. The Tribunal put the claimant's own costs at £13m, funded under an agreement whose funder's fee "might reasonably be expected to be as much as, or more than, sums awarded in damages" (§50–51). Any damages would have come out of future distributions to the very members bringing the claim — "the class was, in a manner of speaking, suing itself" (§52). Collective litigation against your own collecting society is structurally self-defeating even before the evidential problem arrives. ## What does the judgment not decide? Reading it as "PRS is vindicated" overstates it in one direction. Reading it as a fluke overstates it in the other. - **It is not a merits ruling.** The claim was struck out and summarily dismissed at the certification stage, on assumed facts. Nothing was tried. - **The premise was assumed, not established.** Whether data failures genuinely fall more heavily on writers was never determined (§33, §87–88). The court found the claim unsustainable even if they do. - **Approval is not immunity.** §98 says expressly that Distribution Committee approval "cannot, of itself" make a rule incapable of being an abusively unfair condition — and that lawful conduct on the matched pot does not entail lawfulness on the unmatched one. The door to a differently-built claim is ajar; the epistemic problem stands in front of it. - **The £3 was conceded, not adjudicated.** Nobody alleged the cost-accuracy balance was struck in the wrong place (§73), so no court has ruled on the level — only on whose question it is. - **The scope is one society, one right, one rule.** This is PRS performing rights and its pro rata rule — not MCPS mechanicals, not platform-side pools, not foreign societies, not the United States. But the reasoning — no data, no entitlement, no counterfactual — travels everywhere unmatched money exists. The US reached the same endpoint by a different route: Congress chose a market-share allocation for unmatched mechanicals in the Music Modernization Act rather than leave the question to courts. Everywhere you look, the allocation of unmatchable money is a policy decision. Nowhere is it a justiciable entitlement. ## What should a catalogue owner do with this? Read as an operating manual, the judgment gives four instructions. 1. **Below £3, nobody is coming.** The manual floor is real, judicially examined, and rational. Below it, only the matching algorithms read your metadata — and a work that accrues under £3 for three years is extinguished as non-distributable. Make it machine-legible or lose the line. 2. **Above £3, litigation still cannot reach the pool.** The route is closed in principle, not on a technicality: no court can build the counterfactual the claim needs (§84). Waiting for a better lawsuit is not a strategy. 3. **The system pays work-by-work when data permits.** Matched distribution is the machinery's governing principle (§92), and §85 records that corrected data produces matched payments. The door is open exactly as wide as your data is clean. 4. **The fix travels only as data.** Correct ISWCs and IPIs at source, share pictures that agree across societies, registrations consistent in every territory where the work earns. Identifiers propagate. Court orders do not. The asymmetry that prompted this note is simple: the most useful material in *Rowntree v PRS* was never going to make the headlines, and twenty-one pages of competition law is an effective vault. But somewhere in most catalogues there are works earning steadily below the line, failing quietly in several territories at once. The Court of Appeal has now confirmed that no one else is coming for that money. That is not a counsel of despair. It is a job description. TrackForge's work is the upstream half of that job: finding the works that are failing to match, evidencing why, and repairing registrations at source so royalties are paid work-by-work — before they reach the pool the court has just placed beyond recovery. --- *Rowntree v Performing Right Society Ltd & PRS for Music Ltd* [2026] EWCA Civ 814 (29 June 2026); Miles LJ, with Zacaroli and Nugee LJJ agreeing; on appeal from the Competition Appeal Tribunal, [2025] CAT 49. The approved judgment is public via the [National Archives](https://caselaw.nationalarchives.gov.uk/ewca/civ/2026/814). Paragraph references (§) are to the approved judgment. Related TrackForge research: [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy) · [Where the Money Goes](https://trackforge.studio/research/royalty-leakage-map). This note is analysis, not legal advice. --- *Source: [Rowntree v PRS: The £3 Line](https://trackforge.studio/research/rowntree-v-prs)* --- ## research/irene-cara-uncollected-royalties.md # Irene Cara's $333,353 was not at her record label > Uncollected royalties: Irene Cara's estate recovered $333,353. About $246,000 sat with her music publisher and $78,000 with PPL. How to check your own songs. *Published by [TrackForge](https://trackforge.studio) — 2026-10-14* ![Irene Cara in a 1987 Elektra Records publicity photo](https://trackforge.studio/research/irene-cara-1987.jpg) *Irene Cara in a 1987 Elektra Records publicity photo. Photo: Aaron Rapoport, public domain, via [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Irene_Cara_(1987_Elektra_publicity_photo).jpg).* Nearly four years after Irene Cara died, her estate has recovered $333,353 in royalties she earned while she was alive. Most people read that as another story about record labels. The court filing says otherwise. According to probate documents obtained by TMZ and [reported by Finurah on 22 September 2026](https://finurah.com/2026/09/22/irene-caras-estate-uncovers-333k-in-uncollected-royalties-decades-after-her-music-industry-battle/), about $246,000 was held by Chappell Music, a music publisher. Another $78,000 was held by PPL (Phonographic Performance Limited), the UK society that pays performers and recording owners when records are played on radio or in public. Roughly $8,000 was held by Unidisc, a label. **So about 2% of the money was at a record label. Three quarters of it was with her publisher.** The filing does not say why the money went uncollected, and we won't guess. But where it was sitting is the lesson. | Held by | Amount | Share of the $333,353 | |---|---|---| | Chappell Music, a music publisher | $246,000 | About 74% | | PPL, the UK society for performers and recording owners | $78,000 | About 23% | | Unidisc, a record label | About $8,000 | About 2% | Figures as reported by Finurah from the probate documents, which round the three amounts. They record who held the money, not why it was still there. ## Does having a publisher mean your songs are registered? No. A publisher on record is evidence of a relationship. It is not evidence that every song was registered, in every country, with the right shares. TrackForge checks catalogues against the societies' own records. We find unregistered and wrongly registered songs in the catalogues of household-name artists signed to major global publishers. At one large administrator we examined, up to roughly one song in ten had a registration error. Administration is supposed to be a publisher's core job. It is routinely the thing they do worst, because nobody is paid to go back and check. ## Why wouldn't an audit catch it? An audit tests whether the statements you received were calculated correctly. It cannot find a song that never reached a statement, and it does not cover money held by a society on the other side of the world. Society money has to be registered for and claimed. That job gets dropped once an artist's active years are over. ## How much money is sitting like this? A lot, and the societies publish the figures themselves. PPL reported **£15.7 million** allocated to members but unpaid at the end of 2024, held up by incomplete performer registrations and missing bank details. In the US, streaming services handed The MLC (The Mechanical Licensing Collective) about **$397 million** in royalties they had been unable to match to an owner. By September 2026, The MLC had matched and paid out about $239 million of it, or 60%. About **$159 million** was still waiting. ## Does the money wait for you? No. PPL closes each year about six years after its first distribution, then stops accepting claims for it. When it closed 2017, £2.3 million of UK revenue was still undistributed. SoundExchange in the US holds unclaimed royalties for about three years. ## What should an artist or an estate do? 1. **Look up your own songs.** Songview, run by the US performing rights societies ASCAP and BMI, and The MLC's public search are free. Check every song is there, that you are on it, and that the shares match your contract. 2. **Check the performer side separately.** PPL and SoundExchange pay performers directly. No publisher or label claims that money for you. 3. **If you are handling an estate, ask.** Go to each society with the grant of probate or administration. They will pay, but only when someone asks. People trust their publisher blindly. Don't. Check. ## Sources - **Irene Cara's estate:** [Finurah, 22 September 2026](https://finurah.com/2026/09/22/irene-caras-estate-uncovers-333k-in-uncollected-royalties-decades-after-her-music-industry-battle/), citing probate documents obtained by TMZ: $333,353 in total, of which $246,000 was held by Chappell Music, $78,000 by Phonographic Performance Limited and approximately $8,000 by Unidisc Musique. - **PPL:** Phonographic Performance Limited, 2024 Transparency Report: £15.7 million allocated but unpaid at 31 December 2024 because member accounts were on hold awaiting completed performer registrations or valid bank details; undistributed UK revenue is closed six years after first distribution, after which PPL no longer accepts claims for that year; £2.3 million of UK revenue collected in 2017 remained undistributed at 31 December 2024 and that year was closed in March 2025. PPL Distribution Rules, Rule 14.2(4): a performer's money may be paid to a person who has obtained a grant of representation for a deceased performer. - **The MLC:** The Mechanical Licensing Collective, [Historical Unmatched Royalties](https://www.themlc.com/historical-unmatched-royalties), September 2026 snapshot: $238.72 million distributed of $397.29 million transferred by streaming services (60.09%). - **SoundExchange:** Performer and Sound Recording Rights Owner Membership Agreements (revised March 2025), clause 2: royalties SoundExchange cannot distribute are retained for three years, which it may extend at its discretion. - **TrackForge findings:** from TrackForge's own checks of catalogues against society records. We do not name the artists, publishers or administrators involved. --- *Source: [Irene Cara's $333,353 was not at her record label](https://trackforge.studio/research/irene-cara-uncollected-royalties)* --- ## research/doubt-in-the-rate-fact-in-the-forecast.md # Doubt in the rate, fact in the forecast > Valuations argue over the discount rate and take the income base on trust. Why a registration gap belongs in the forecast, and what buyers should check first. *Published by [TrackForge](https://trackforge.studio) — 2026-10-20* In April 2026, Chord Music Partners raised $500 million against a catalogue of more than 3,750 compositions and recordings. An independent valuer had put the catalogue at about $830 million, using a discounted cash flow at an 8% discount rate. In a recent discussion among catalogue investors, that 8% got all the attention. Nobody asked about the other input. A discounted cash flow valuation has two inputs. One is a forecast of the income the songs will earn. The other is the rate at which that income is discounted back to a value today. This article is about the first, and about a habit the industry has of putting a measurable fact into the second. ## The argument everyone has: the discount rate The discount rate is where uncertainty goes. The risk of the asset class, the risk of this catalogue, the risk that the forecast is wrong: all of it is expressed as a number of percentage points, and that number is where the argument lands. It is a powerful lever. On the simplest arithmetic, a perpetual income stream valued at 8% is worth one seventh more at 7%. Applied to the Chord figures, that is roughly $950 million for the same songs, a difference of about $120 million from one percentage point. The arithmetic is ours, not the valuer's; a real model with growth and decay assumptions would move by a different amount. The direction and the order of size are the point. The market watches the rate for the same reason. When Hipgnosis Songs Fund's board commissioned a second valuation of its portfolio in March 2024, the figures that led every report were the rates and the totals: 8.5% and $2.62 billion in the valuation it had, a midpoint of 9.63% and $1.93 billion in the new one. Two professional firms, two rates, two values for the same songs. The point here is not which was right. It is which input everyone argued about. ## The input nobody argues about: the income base The forecast starts from royalty statements. Three years of statements from societies, publishers and distributors; a growth or decay curve fitted to them; the rate applied. The statements are treated as the settled part of the exercise. This is what the songs earn. It is not. A royalty statement shows what was collected and paid to this owner. It does not show what the songs earned. The difference is income that a use of the song generated and that never reached the owner, because the song was not registered at the society where the use happened, or was registered with the wrong shares, or under a title the society could not match to a payee. That money is not hypothetical. The societies publish it. Streaming services handed The MLC (The Mechanical Licensing Collective) in the United States about $397 million in royalties they could not match to an owner; by September 2026 The MLC had paid out about $239 million of it and about $159 million was still waiting. PPL (Phonographic Performance Limited), the UK society for performers and recording owners, reported £15.7 million allocated to members but unpaid at the end of 2024, held up by incomplete performer registrations and missing bank details. TrackForge's own published analysis of The MLC's bulk matching data found that 72.5% of 954 million sound recording resources had no matched musical work. None of this appears on a statement, because a statement is a record of what a society could match to a payee. A song unregistered at a society earns on that society's books and shows nothing on its owner's. So the income base in a valuation is understated for any catalogue with registration gaps, and nobody knows by how much, because nobody looked. ## Why a rate premium is the wrong tool for a registration gap In the discussion mentioned above, the reply to this point was fair: doubts about registrations, splits or collection end up priced in a higher rate rather than in a lower forecast. That is an accurate description of practice. It is also a description of the problem. A higher discount rate can only lower a value. It is a penalty. But a song never registered at a society is income missing from the base, which means the catalogue is worth more than its statements show, not less. A rate adjustment cannot carry an upside. Whatever the premium is doing, it is not representing the registration gap. It is representing the valuer's unease about it. The shape is wrong too. A rate premium applies to every pound of forecast cash flow, in every year, for the life of the model. A registration gap is specific: this work, at that society, for these shares. It can be found, it can be fixed, and once fixed it stops. The usual rule in valuation is that asset-specific, verifiable items go in the expected cash flows, and the rate is kept for risks that apply to the whole stream and cannot be diversified away. A registration gap is the first kind of item being treated as the second. Both sides of that discussion are right, about different catalogues. For a catalogue nobody has checked, the doubt is unquantified and lives in the rate by convention, because there is nowhere else to put it. For a catalogue someone has checked, the gap is a fact: a list of works, societies and shares with a number attached. A fact belongs in the forecast. The hinge is whether anyone checks. The convention has its reasons, and they deserve saying. Song-by-song verification has not been part of a transaction, so the rate was the only tool to hand. A verified gap still needs a forecast of its own: whether the income will be collected, when, and at what cost. And observable trade prices bundle all of this together and are useful whatever the mechanism underneath. None of that argues for leaving the gap in the rate once it can be measured. It argues for measuring it. ## What a buyer should check before the letter of intent 1. **Registration per society per work.** For every work in the schedule, and every society in the territories where it earns, is there a registration, and does it name the interest being sold? A work registered at PRS and absent from ASCAP, BMI and The MLC is three gaps, not one. 2. **Shares that agree across societies.** Compare the writer and publisher splits at each society with each other and with the contracts. A 50% share at one society and a 33.33% share at another is not a rounding difference. One of them is paying the wrong person. 3. **Suspense and unclaimed positions.** Search the societies' unclaimed and suspense pools for the catalogue's titles, writers and ISRCs. Money there is earned income that is not in the base, and some of it has a deadline: PPL closes a distribution year about six years after its first payment and then stops accepting claims for it. 4. **The recording side, separately.** Neighbouring rights at PPL and SoundExchange, and the link from each recording's ISRC to its registered work, are separate systems with separate gaps. A composition registered perfectly earns nothing from a stream whose recording is not linked to it. 5. **What the pack covers, and what it never checks.** The standard diligence pack covers chain of title, agreements and encumbrances, the royalty statements and a quality-of-earnings analysis built on them. It takes the registrations for granted. No section of it asks whether each work is registered at each society with the shares the contracts say. That is the one question whose answer changes the income base. ## What it means for the valuer Checked facts in the forecast, doubt in the rate. For a checked catalogue the forecast gains a line: income the statements never showed, with a probability and a timing of collection attached, like any other forecast line. The rate loses the part of its premium that was carrying registration doubt, because the doubt has been resolved into a number. Both inputs become more observable, and the value becomes an argument about evidence rather than about a convention. It cuts both ways. A check also finds works the seller is registered as owning that the contracts do not support, and shares claimed at a society that another party disputes. Those are facts too, and they lower the base. The point is not that checking raises values. It is that a value built on checked facts can be defended line by line, and a value built on a rate premium can be defended only as a convention. A doubt goes in the rate. A checked fact goes in the forecast. Checking is what turns one into the other. ## Sources - **Chord Music Partners:** [Chord Music Partners Prices $500 Million ABS Backed by Diversified Music Catalog](https://www.apollo.com/insights-news/pressreleases/2026/04/chord-music-partners-prices-500-million-abs-backed-by-diversified-music-catalog), press release, 27 April 2026: $500 million of Series 2026-1 senior notes, backed by royalties from more than 3,750 musical compositions and master recordings, valued at approximately $830 million by an independent third-party valuation agent. [KBRA, 16 April 2026](https://www.kbra.com/publications/TbQytYrq): the catalogue was valued at $830.0 million as of 30 September 2025. [Asset Securitization Report (American Banker)](https://asreport.americanbanker.com/news/music-royalty-revenue-supports-chord-musics-500-million-in-abs), reporting the rating agency's analysis: a discounted cash flow method with an 8.00% discount rate assumption; about 34% of recent net revenue from publishing and 66% from sound recordings. The $950 million figure at 7% is TrackForge's perpetuity arithmetic on those published numbers, not a figure from the valuer or the rating agency. - **Hipgnosis Songs Fund:** [Music Business Worldwide, 4 March 2024](https://www.musicbusinessworldwide.com/hipgnosis-songs-funds-assets-are-now-valued-at-690-million-less-than-they-used-to-be-blackstone-will-be-licking-its-lips/) and [Billboard, 4 March 2024](https://www.billboard.com/pro/hipgnosis-songs-fund-lower-valuation-validated-investors-concerns), reporting the fund's announcement: Citrin Cooperman valued the portfolio at $2.62 billion as of 30 September 2023 using an 8.5% discount rate; Shot Tower Capital valued it at between $1.80 billion and $2.06 billion as of 1 March 2024, a midpoint of $1.93 billion, using a midpoint discount rate of 9.63%. - **The MLC:** The Mechanical Licensing Collective, [Historical Unmatched Royalties](https://www.themlc.com/historical-unmatched-royalties), September 2026 snapshot: $238.72 million distributed of $397.29 million transferred by streaming services. - **PPL:** Phonographic Performance Limited, 2024 Transparency Report: £15.7 million allocated but unpaid at 31 December 2024 because member accounts were on hold awaiting completed performer registrations or valid bank details; undistributed UK revenue is closed six years after first distribution, after which PPL no longer accepts claims for that year. - **TrackForge:** [How ISRC Registration Gaps Cost Labels Money](https://trackforge.studio/research/isrc-registration-gaps): of 954 million sound recording resources in The MLC's bulk work-resource matching dataset, 691.7 million (72.5%) had no matched musical work. The [due diligence bottleneck](https://trackforge.studio/docs/certification/overview/the-problem) page describes what a conventional diligence engagement costs and covers. --- *Source: [Doubt in the rate, fact in the forecast](https://trackforge.studio/research/doubt-in-the-rate-fact-in-the-forecast)* ## research/music-in-the-air-number-nobody-models.md # $198 billion, 57%, and the number nobody models > Goldman Sachs forecasts music to $198.1 billion by 2035 and stops at the society's door. The step it leaves out has a published size and, from 2027, a clock. *Published by [TrackForge](https://trackforge.studio) — 2026-10-23* *Music in the Air stops at the society's door. Goldman Sachs forecasts the music industry to $198.1 billion by 2035 and models the share that reaches rights holders. What happens after the society is paid has a published size and, from April 2027, a clock.* --- A forecast of rights-holder revenue is not a forecast of what rights holders receive. Goldman Sachs's Music in the Air 2026 takes the global music business from $112.5 billion in 2025 to $198.1 billion in 2035 (p.12), and models how much of that retail money reaches rights holders: about 57%, held flat for ten years (pp.15–16). Then it stops. The money has reached the label, the publisher or the collecting society, and the model treats that as the end of the pipe. It is not the end of the pipe. After the society is paid, whether the owner is paid depends on three things the report never mentions: whether the work is registered, whether the usage is matched to it, and whether the share is claimed. In 93 pages the report does not name a single collecting society. The words unmatched, unclaimed and black box do not appear. Its one nod to collection is an AI product (pp.9, 57, 61). This is not a complaint about the model. Its job is to forecast the industry's revenue, and it does that with care; every Goldman figure below is Goldman's, cited to its page. The complaint is about everyone who will quote the $198 billion as if it were a forecast of their own income. For a catalogue owner, the number that matters is produced by the step the report does not model, and that step has a published size. | Figure | What it is | |---|---| | $198.1bn | Goldman's forecast of global music retail revenue in 2035, from $112.5bn in 2025 (p.12) | | ~57% | the share of retail revenue Goldman models as reaching rights holders, held flat to 2035 (pp.15–16) | | $630.5m | unmatched and unclaimed US mechanical royalties held at The MLC for 2021–2025 usage, March 2026 | | April 2027 | the month The MLC starts paying unclaimed royalties to other people's shares, by market share | --- ## Two steps modelled, one not Goldman's model has two steps between a listener and a rights holder. There is a third, and it is where the owner gets paid or does not. The first step is retail revenue: what listeners and advertisers pay. Goldman grows it at 5.8% a year to 2035, with recorded music adding $45.8 billion, live music $27.7 billion and music publishing $12.1 billion at 4.8% a year (p.12, Exhibit 13). The second step is the share of that retail money which reaches rights holders. Goldman holds it at about 57% for the whole forecast, because "the industry market structure and negotiating leverage between rights holders and DSP remain largely the same" (pp.15–16). On that basis recorded-music rights-holder revenue goes from $31.7 billion to $56.1 billion (p.16). The third step is the one the report does not draw. A streaming service pays a mechanical or performing-right society a pool of money for a month's usage. The society pays out the part it can match to a registered work with a claimed share, and holds the rest. The owner receives a statement of what was paid. The report notes that rights holders "derive value from i) mechanical rights (reproduction) and ii) performance rights" (p.60); it does not model how either reaches them. **Three steps from listener to owner. Goldman models the first two.** | Step | Stage | Status in the report | |---|---|---| | 1 | Retail revenue: $112.5bn (2025) to $198.1bn (2035); listeners and advertisers pay | Modelled, p.12 | | 2 | About 57% to rights holders: labels, publishers, societies; held flat for ten years | Modelled, pp.15–16 | | 3 | Society to owner: registered, matched, claimed; or held, then reallocated | Not in the report. Its only reference to this stage is "AI forensic royalty recovery tools" (pp.9, 57, 61) | Here is the uncomfortable part. Nobody in the chain is paid to check that the owner was paid. The service has discharged its licence when the pool is paid. The society has discharged its rules when it distributes what it can identify and holds the rest for the period its rules allow. The owner reads a statement that looks complete, because it is a complete list of what matched. **A royalty statement is a record of what matched, not of what was earned.** Nothing in Goldman's 57%, and nothing on anyone's statement, says how far apart those two numbers are. --- ## How big is the step Music in the Air leaves out? For one right, in one country, the answer is in an annual report filed every year. It is $630 million and it is not shrinking. The MLC (the US collective that administers mechanical royalties from interactive streaming and downloads) is unusual among societies in publishing, by usage year and by reason, how much it is holding. Its 2025 Annual Report, with figures as of the March 2026 distribution, shows **$630.5 million** of unmatched and unclaimed blanket royalties held across 2021 to 2025 usage, plus $27.5 million in dispute. "Unmatched" means The MLC cannot tell which work a recording embodies. "Unclaimed" means it can, but less than 100% of the work's shares has been claimed by a member. This is not a society failing. The MLC's average match rate for its first five years is 91.9%, it reprocesses the remainder every month, and it publishes more about its held money than most societies do. The point is what the system settles to after years of that effort. For 2021 usage, the oldest year, $81.9 million was still unpaid in March 2026: **14.3% of the $571.9 million collected for that year**, four to five years after the streams happened. A year earlier it was $90.9 million; a year before that, $103.0 million. The residue falls by about a tenth a year, which means most of it will never be matched by effort alone. **Blanket royalties still held by The MLC, by usage year, as of March 2026 ($ millions)** | Usage year | Unmatched | Unclaimed | In dispute | Total held | Collected for the year | |---|---|---|---|---|---| | 2021 | $40.8m | $39.5m | $1.6m | $81.9m | $571.9m | | 2022 | $48.7m | $42.3m | $3.5m | $94.5m | $697.7m | | 2023 | $76.6m | $62.7m | $7.8m | $147.0m | $1,019.2m | | 2024 | $87.2m | $59.3m | $7.3m | $153.8m | $967.7m | | 2025 | $108.1m | $65.3m | $7.4m | $180.8m | $914.2m | | **Total** | **$361.4m** | **$269.1m** | **$27.5m** | **$658.0m** | **$4,170.5m** | Source: The MLC 2025 Annual Report, appendix section F, figures as of the March 2026 distribution. "Collected" is net of royalties identified as subject to direct voluntary licences after reprocessing. The 2025 column is young: its initial distributions ran to March 2026 and reprocessing had barely begun. Two more lines from the same report. **$52.7 million** had been matched, found eligible and still not paid, because the amount was below the payment threshold, the payee's details were wrong or incomplete, or the member had not finished registering. That is money with a known owner who has not been paid for a paperwork reason. And of the **$397.3 million** of pre-2021 "historical unmatched" royalties the streaming services handed over in 2021, **$240.0 million (60.4%)** had been distributed by October 2026. The rest is still waiting for someone to register and claim it. **One society, one right, one country.** The MLC administers US mechanical royalties from interactive streaming and downloads. The US performing right, and both rights everywhere else, sit with societies that report their held balances differently or not at all. CISAC's 228 member societies collected **€13.97 billion** for creators in 2024 (Global Collections Report 2025). The MLC's $630 million is the published residue of one pipe, not a total for the system. Nobody publishes the total, which is the point. --- ## The MLC's unclaimed royalties now have a clock In April 2027 The MLC starts paying unclaimed royalties to other people, by rule, on a schedule, inside Goldman's forecast window. The Music Modernization Act requires The MLC to hold unclaimed royalties for at least three years and then distribute them to copyright owners by relative market share. The MLC has held them for twice that. On 30 September 2026 it announced the start date: **April 2027**, beginning with the remaining royalties from January 2021 usage, then one usage month in each monthly distribution after that. The rules are in its Policy for the Distribution of Unclaimed Accrued Royalties (September 2026). The April 2027 distribution uses the database snapshot taken on or around **10 February 2027**. Registrations, matches and claims count only if they are processed before that snapshot. The unclaimed pool for each month, licensee and offering is allocated pro rata to the shares that were claimed in that snapshot. A completed distribution is final. A share claimed afterwards is paid for later periods, "excluding only royalties for periods that were already subject to a market share distribution". Say what that is. **It is a transfer from the unregistered to the registered, by rule, on a schedule.** The money does not vanish into a black box; it is paid, in proportion to market share, to whoever had their paperwork in order on the day of the snapshot. The statute requires a publisher that receives it to pass at least 50% of the part attributable to each songwriter back to that songwriter. Nothing requires anyone to pass any of it to the owner who never registered. **Goldman's forecast window against The MLC's market-share clock** | Date | Event | |---|---| | January 2021 | First usage under The MLC's blanket licence | | 2025–2035 | Goldman's forecast window (p.12) | | On or around 10 February 2027 | Database snapshot used for the first market-share distribution | | April 2027 | First market-share distribution: remaining January 2021 usage | | Early 2028 | 2021 usage fully redistributed, at one usage month per month | | Early 2029 to early 2035 | 2022 to 2028 usage fully redistributed, one year each, if the pace continues | The MLC has committed to the pace for 2021 usage; the closing dates for 2022 onward assume it continues at one usage month per month. Each distribution is preceded by at least 90 days' notice, and the notice, not this table, fixes the date. Put the two charts together. Goldman's window runs from 2025 to 2035. At the announced pace, every usage year from 2021 to 2028 is fully redistributed inside it. For a catalogue owner, the first deadline in the system that is set by rule rather than by effort is **10 February 2027**, and the publishing growth in the forecast arrives, year by year, through a door that closes behind it. For a buyer, this changes what an unclaimed balance is. Before the snapshot it is recoverable with statutory interest. After it, it is someone else's income, and the policy says The MLC corrects only its own errors. For a lender, it is the first date on which part of the collateral's history becomes unrecoverable by rule. For a publisher, it is the date by which "we will tidy the registrations later" stops being a plan. --- ## Where the growth is, the register is thinnest Goldman puts most of the next decade's new subscribers in emerging markets. The authors' societies there collect a rounding error. Goldman expects emerging markets to supply up to 75% of net subscriber additions by 2035, growing from 438 million to 956 million paid subscribers at 8.1% a year (p.22). Each pays rights holders about $12 a year against $30 in developed markets (p.34). Latin America is the fastest-growing region, with recorded-music revenue up 17.1% in 2025 (p.23). Recorded revenue reaches labels and distributors directly. The writer's and publisher's money takes the long way round: a local society collects it, matches it against its own repertoire, and sends it to the writer's home society under a reciprocal agreement, or to a sub-publisher. Every hop is a registration that has to exist and a match that has to be made. The third step, done abroad, is the third step done several times. | | Figure | Detail | |---|---|---| | Africa, authors' collections 2024 | €90m | 0.6% of the €13.97 billion CISAC's societies collected worldwide, up 14.2% from a small base (CISAC Global Collections Report 2025) | | Latin America, authors' collections 2024 | −0.6% | €786 million, the only region to decline (CISAC), in a year when recorded-music revenue in the region grew 22.5% (IFPI Global Music Report 2025) | | Emerging-market rights-holder revenue per subscriber | $12 | a year, against $30 in developed markets; up to 75% of net subscriber additions to 2035 are expected to come from these markets (Goldman, pp.22, 34) | Read those three together. The region adding the most listeners pays the least per listener, and its authors' societies either collect almost nothing or went backwards in a year the recorded market grew by a fifth. Goldman's model is right that the retail money will arrive. Whether the writer's share of it gets home depends on registrations in societies most Western publishers have never filed with. For a publisher counting on emerging-market growth, the forecast is the easy part. --- ## AI pays through the same register Every licensing template in the report pays by identified work and share. An opt-in is a registration. A per-generation royalty is a matching problem with a new input. Goldman's base case puts generative AI at a $3.3 billion uplift to subscription streaming rights-holder revenue by 2035, about 10%, with a 50% rights-holder share of retail against roughly two thirds in streaming today (pp.65–66). The report lists how that money would be paid: subscription and licensing fees under an opt-in structure, revenue shares, and "per-generation royalties" based on usage of licensed catalogues in user outputs (p.62). Its table of licence fee types includes an "Output Royalty", a "per-generation royalty triggered when AI model produces content influenced by licensed catalog" (p.54, Exhibit 77). It records a society building "infrastructure that identifies when songwriters' and composers' work is used by AI" (p.53). Every one of those pays a specific work and a specific share. The opt-in list is a register. The attribution system is a matching engine. The output royalty is a usage line that has to find its owner, like every usage line today. Whatever share of the $3.3 billion is real arrives through the same door as the mechanical royalties above, with a harder matching problem, and the report's own risk table already names "market share dilution of royalty payouts" as the AI-era risk for labels (p.9). The work that is registered, identifiable and claimed gets paid from this pool. The rest joins the residue. > Goldman counts to the society's door. Nobody counts past it. From April 2027, the money nobody counted is paid to the people who did. --- ## What a buyer, lender or publisher should check None of this requires a view on the discount rate. It requires asking for evidence from the society side, not the statement side. 1. **Treat the forecast as the top of the pipe.** Goldman's $198.1 billion and 57% describe money reaching rights holders as a class. They say nothing about whether a given work is registered, matched and claimed. Price the forecast on the works whose registrations you have seen. 2. **Ask for registrations, not statements.** A royalty statement lists what matched. The evidence that the owner is being paid in full is the registration at each society, for each work, with each share and each identifier, and the absence of the work from that society's unmatched or unclaimed lists. 3. **Look the catalogue up in the held pools.** The MLC publishes its unmatched and unclaimed data for members to search. Works that appear there are earning US mechanicals that are not being paid to anyone. Equivalent lists exist at other societies with less publicity and shorter windows. 4. **Date every finding against the clock.** January 2021 usage is fixed on or around 10 February 2027, then one usage month a month. A registration or claim that is submitted but not processed before the snapshot misses it. Allow at least one monthly cycle of headroom. 5. **Follow the writer's share abroad.** For income from emerging markets, establish which local society collects, under which reciprocal agreement or sub-publishing deal the money comes home, and whether the works are registered there at all. If no one can answer, the forecast for that territory is unsecured. 6. **Treat AI opt-ins as registrations.** Whatever the licence template, AI money is paid by identified work and share. A catalogue with incomplete identifiers and unclaimed shares will be as hard to pay from an output royalty as it is from a stream. The industry's best-read forecast counts to the society's door, and everyone who quotes it will quote the number at the door. The number that matters to an owner is the one on the far side, and for the first time it has both a published size and a published deadline. Check it before February 2027, or watch it become part of someone else's market share. Related: [Doubt in the rate, fact in the forecast](https://trackforge.studio/research/doubt-in-the-rate-fact-in-the-forecast), on why a registration gap belongs in a valuation's forecast rather than its discount rate. --- ## Sources **Goldman Sachs:** Goldman Sachs Global Investment Research, Music in the Air: 10 Years On, 15 October 2026, 93 pages. Page numbers in this article are the PDF's, which run one ahead of the printed footer. Global retail revenue $112.5bn (2025) to $198.1bn (2035E), 5.8% CAGR; recorded music +$45.8bn, publishing +$12.1bn at 4.8%, live +$27.7bn: p.12, Exhibits 12 and 13. Retail-to-rights-holder share of about 57% held flat: pp.15–16. Recorded-music rights-holder revenue $31.7bn to $56.1bn: p.16. Mechanical and performance rights as the sources of rights-holder value: p.60. "AI forensic royalty recovery tools" and "improvements in royalty collection": pp.9, 57, 61. Emerging markets up to 75% of net adds, 438m to 956m subscribers, 10% penetration against 42%: pp.22, 34. Rights-holder ARPU $12 against $30: p.34. Latin America recorded music +17.1% in 2025: p.23. AI licence fee types including the Output Royalty: p.54, Exhibit 77. Opt-in structures and per-generation royalties: p.62. Attribution infrastructure: p.53, Exhibit 76. Generative AI base case $3.3bn, about 10%, at a 50% rights-holder split: pp.65–66, Exhibit 86. "Market share dilution of royalty payouts": p.9, Exhibit 7. The report is distributed to the firm's clients; a public summary is at [goldmansachs.com](https://www.goldmansachs.com/insights/articles/music-in-the-air). The counts of zero mentions of The MLC, CISAC, "unmatched", "unclaimed" and "black box" are TrackForge's word search of the full text. **The MLC, held royalties:** The Mechanical Licensing Collective, [2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf), appendix section F, figures as of the March 2026 distribution: royalties held by usage year and category; royalties collected by usage year after reprocessing (2021: $571,859,897.20); $52,690,895.03 matched, eligible and undistributable; average match rate 91.9% for 2021–2025 usage; historical unmatched royalties of $397,286,419.31 collected and $229,029,821.03 distributed as of March 2026. The year-earlier figures for 2021 usage ($90.9m in March 2025, $103.0m in March 2024) are from the [2024](https://www.themlc.com/hubfs/The%20MLC%202024%20Annual%20Report.pdf) and [2023](https://www.themlc.com/hubfs/2023%20MLC%20Annual%20Report.pdf) annual reports. Historical royalties distributed by October 2026, $239,955,887.57 of $397,286,419.01 (60.40%): [HUR report, October 2026](https://www.themlc.com/hubfs/Website/HUR/HUR%20October%202026.pdf). **The MLC, market share:** [Policy for the Distribution of Unclaimed Accrued Royalties](https://www.themlc.com/hubfs/UAR%20Distribution%20Policy%20(September%202026).pdf), September 2026: same snapshot as the month's blanket distribution (§3.8); claims count only if processed before it (§6.4); pro-rata allocation to claimed shares (§5.1); finality (§6.5); correction of The MLC's own errors only (§6.6); 90 days' notice (§7). [Market Share](https://www.themlc.com/marketshare) page, read 23 October 2026: distributions to begin in April 2027 with remaining January 2021 usage, one usage month each month, snapshot on or around 10 February 2027, 2021 royalties held for at least six years, just over $6 million remaining for January 2021 after the September 2026 distribution, later claims paid "excluding only royalties for periods that were already subject to a market share distribution". [Press release, 30 September 2026](https://www.themlc.com/news/the-mlc-holds-annual-membership-meeting-highlights-more-than-4.2-billion-in-total-royalties-distributed-and-announces-date-of-first-monthly-market-share-distribution): the announcement of the April 2027 date and the one-month-at-a-time pace. The songwriter minimum of 50% is 17 U.S.C. §115(d)(3)(J)(iv). **CISAC and IFPI:** [CISAC Global Collections Report 2025](https://www.cisac.org/Newsroom/news-releases/cisac-global-collections-report-2025), 6 November 2025: €13.97 billion collected for creators in 2024 (+6.6%) by 228 societies in 111 countries; Africa €90 million (+14.2%); Latin America and the Caribbean €786 million (−0.6%). [IFPI Global Music Report 2025](https://globalmusicreport.ifpi.org/): recorded-music revenue in 2024 grew 22.5% in Latin America and 22.6% in Sub-Saharan Africa. **Disclosure:** TrackForge checks whether works are registered, matched and claimed at collecting societies, and recovers royalties that are not. No TrackForge client or catalogue figure appears in this article; every number is from the published source named beside it. --- *Source: [$198 billion, 57%, and the number nobody models](https://trackforge.studio/research/music-in-the-air-number-nobody-models)* ## research/music-catalogue-due-diligence.md # How to due-diligence a music catalogue before you buy > Music catalogue due diligence checklist: six questions to answer before you buy, the data room, red flags, and how an independent rating fits. UK and US. *Published by [TrackForge](https://trackforge.studio) — 2026-10-28* *Music catalogue due diligence comes down to six questions, asked for every right and territory: identity, title, registration, collection, risk and coverage. Here is the checklist, the data room, who does what, the red flags, and where an independent rating fits.* --- Music catalogue due diligence is the buyer's structured check, before signing, that a catalogue is what the seller says it is: that its works and recordings are clearly identified, that the seller controls them, that they are registered where they earn, that the money on the statements is real and keeps flowing, and that nothing threatens the income after closing. The short checklist is six questions, asked for every right and territory: **identity, title, registration, collection, risk and coverage**. Coverage records what was actually checked, because a check that was not done is not the same as a check that found nothing. In TrackForge's view, a standard diligence pack covers chain of title, the agreements and the royalty statements, but usually does not ask whether each work is registered at each society with the shares the contracts say. That question decides whether the income on the statements is complete. The free [TrackForge Workspace](https://trackforge.studio/workspace) is built for that part: load the catalogue and it shows each work's position at each society, so gaps can be fixed before or after closing. **Six questions, asked for every right and territory** | # | Question | What it asks | |---|---|---| | 1 | Identity | Do ISRC, ISWC and IPI codes each resolve to one identity, with no duplicates? | | 2 | Title | Does the seller control what it says it does: works, shares, rights, territories, agreements? | | 3 | Registration | Is each work registered at every society where it earns, with the right shares and parties? | | 4 | Collection | Is money flowing, consistent with usage? What sits in unmatched or unclaimed pools? | | 5 | Risk | Conflicts, counterclaims, reversions, expiring administration, time limits, samples? | | 6 | Coverage | What was checked, from where, as of when? Applies to every answer. "Not checked" is never "nothing found". | Work through them in this order, because each depends on the one before. Every later check joins on identifiers. A registration should reflect the contracts. Money follows registration. Risk looks forward from all three, and coverage runs across everything. --- ## What is music catalogue due diligence, and who does it? *Legal and financial checks are the core. A third strand, the registration and rights-data check, is where income is most often found or lost.* Music catalogue due diligence is the buyer's investigation of the rights and income it plans to acquire. The Los Angeles chapter of the Association of Independent Music Publishers puts it plainly: "the starting point of every deal is the Due Diligence inquiry, both financial and legal" ([AIMP, October 2023](https://aimp.org/blog/resources_topics/buying/)). On the legal side, Tim Cohan says the team researches "legal chain of title of the compositions, all agreements that fall under the acquisition, as well as assess the selling party". On the financial side, Cedar Boschan says advisers assess "the income of the titles, whether past payments have been correct" ([Synchtank, 2019](https://synchtank.com/blog/selling-a-legacy-considerations-for-buying-selling-and-administering-music-catalogues)). The third strand, auditing registrations and rights data, is a different skill from either. In practice the work divides like this. | Who | Typically responsible for (questions) | |---|---| | Music or IP lawyer | Chain of title; songwriter, publishing and label agreements; Copyright Office records; termination rights; warranties and indemnities *(Title, Risk)* | | Accountant or financial adviser | Rebuilding income from source statements; reconciling to cash; net publisher's share (NPS) and net label share (NLS); concentration; liabilities; the forecast *(Collection)* | | Valuation firm | An independent discounted cash flow (DCF) valuation of the forecast income *(Collection, Risk)* | | Registration and rights-data auditor | Identifier resolution; what each society holds; shares across societies; unmatched pools; a coverage statement *(Identity, Registration, Collection, Coverage)* | | Administrators, sub-publishers, labels | Supplying statements; confirming they will keep paying after a change of owner *(Collection, Risk)* | --- ## The six questions to answer for each right and territory *A catalogue is a bundle of rights, each earning in different places through different societies.* The publishing side carries performing, mechanical, synchronisation and print rights. The recording side carries the master and, separately, neighbouring rights for recording owners and performers. Each earns through different bodies: in the UK, PRS for Music (performing), MCPS (mechanical) and PPL (recordings and performers); in the US, ASCAP, BMI, SESAC and GMR (performing), The MLC (digital mechanicals) and SoundExchange (digital recording performance); elsewhere, local societies, usually reached through sub-publishers. ### 1. Identity: does every work and recording resolve to one identity? Identity is whether each work and recording is uniquely and correctly identified. An ISRC (International Standard Recording Code) identifies one sound recording ([IFPI](https://isrc.ifpi.org/isrc-standard)). An ISWC (International Standard Musical Work Code) identifies the musical work and is an ISO standard developed with CISAC ([ISO](https://www.iso.org/news/2002/04/Ref821.html)). An IPI (Interested Parties Information) number identifies a writer or publisher at the societies. Money is matched to songs through these codes, so a recording with no link to its work, two ISRCs for one recording, or a writer under two IPI numbers can leave income unmatched. **Ask for** the full lists. **Check** that each code resolves once, matches the title and artist, and links recording to work. **Good looks like** one work, one ISWC, every recording linked, no near-duplicate titles. ### 2. Title: does the seller control what it says it controls? Title, or chain of title, is whether the seller owns or controls what it is selling: which works, what share, which rights, in which territories, under which agreements. A society registration is a claim, not proof of title. Title is documented by contracts, so lawyers trace each work from the author through every assignment, licence and administration agreement. In the US, also check the Copyright Office record: under [17 U.S.C. §205](https://www.law.cornell.edu/uscode/text/17/205) the earlier of two conflicting transfers prevails only if recorded within one month of execution in the US (two months abroad) or before the later one is recorded; otherwise a later transfer taken in good faith, for value and without notice of the earlier one, and recorded first, can win. **Good looks like** a signed document behind every material work and share, matching what the societies hold. ### 3. Registration: is each work registered where it earns, with the right shares? Registration is whether each work and recording is registered at every society where it earns, in the seller's name, with the right shares and parties. A work can be correct at PRS and absent at The MLC, or registered at both with a 50% publisher share at one and 33.33% at the other. **Ask for** the seller's current registrations taken from each society's own work list or portal export, not the seller's spreadsheet, plus the CWR (Common Works Registration) files and acknowledgements used to register them. **Check** that shares total 100% for each right, parties agree across societies, and each work appears at every society where the seller says it earns. **Good looks like** every work, society and right registered consistently, or carrying a documented reason it is not. ### 4. Collection: is money flowing, and does it match how the songs are used? Collection is whether income is actually arriving, consistent with usage, and what sits unclaimed. Rebuild income from the source statements, then compare what each society paid with the songs' streaming and broadcast footprint. Then look at the pools. As of March 2026 The MLC held **$630.5 million** of unmatched and unclaimed blanket royalties for 2021 to 2025 usage, while reporting a 91.9% average match rate across that usage ([The MLC 2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf)). Both are true: most usage is matched, and the unmatched remainder is still large. Money in a pool is earned income its owner is not yet receiving, which is a risk for a buyer and, if the seller's shares are in it, upside. **Good looks like** statements that tie to cash and usage, and pools that are empty or understood. ### 5. Risk: what could take the income away after closing? Risk is whatever can reduce or interrupt income after the sale: conflicting registrations, counterclaims, reversions, expiring administration agreements, time limits on claims, and uncleared samples. For US rights, ask about termination. Under [17 U.S.C. §203](https://www.law.cornell.edu/uscode/text/17/203) an author can terminate a grant made on or after 1 January 1978, other than for a work made for hire, in a five-year window starting 35 years after the grant, by serving notice two to ten years ahead and recording it at the Copyright Office. It affects US rights only. Time limits matter too: a US copyright suit must be brought within three years of the claim accruing ([§507(b)](https://www.law.cornell.edu/uscode/text/17/507)), and societies have their own claim windows. **Good looks like** no conflicts, or conflicts that are known, sized and bounded. ### 6. Coverage: what fraction was checked, from which source, as of when? Coverage is the statement of how much of the catalogue each answer covers: the share of works and of income checked, the source (a society's own records, a public lookup, the seller's say-so) and the date. Registry data changes continually, so an undated answer goes stale. Coverage matters most where access is limited. A US check can often be done largely from public data, while much of the UK detail (shares and parties at PRS and MCPS) sits in members-only systems, so a UK answer usually needs the seller's cooperation. **Good looks like** every answer carrying its percentage, source and date, with "not checked" shown as exactly that. A report saying "no issues found" without a coverage line has told you very little. --- ## What should be in a music catalogue data room? *Ask for documents from the source of each fact, not the seller's summary of it.* A data room is the secure folder in which a seller shares what a buyer needs to complete due diligence. Ask for the longest earnings history available. Synchtank's advisers differ on how much is enough: Primary Wave's Larry Mestel looks at four to five years, while Eleven Advisory's Alun Simpson says eight to ten years is a decent foundation, ideally "down to a track-by-track level" ([Synchtank, 2019](https://www.synchtank.com/blog/for-what-its-worth-putting-a-value-on-publishing-catalogues/)). | Request | What it answers (question) | |---|---| | Schedule of works and recordings, with splits by right and territory | What exactly is being sold *(Identity, Title)* | | ISRC, ISWC and IPI lists | Whether every item resolves to one identity *(Identity)* | | Songwriter, publishing, administration, sub-publishing, label and distribution agreements, with amendments | Who controls what, for how long, where *(Title, Risk)* | | Royalty statements by source and bank receipts | What was earned and paid, by source and territory *(Collection)* | | Current work lists from each society; CWR files and acknowledgements | What each society holds against the schedule *(Registration)* | | Unclaimed, dispute and conflict lists | Earned income not reaching the owner *(Collection, Risk)* | | Copyright Office registrations and recorded transfers; termination notices; reversion schedule | Documentary title; when rights may return *(Title, Risk)* | | Sample, sync and other licences; third-party claims; audit correspondence | Encumbrances and one-off income *(Risk, Collection)* | | Confirmation from administrators and sub-publishers, with expiry dates | Whether collection continues after the sale *(Risk, Collection)* | --- ## How do you analyse a catalogue's income? *Start from the net figure, rebuild it from source, and look at its shape as well as its size.* Net publisher's share (NPS) is the amount a catalogue pays a publisher in a year after the songwriters have been paid. Its recording-side counterpart is net label share (NLS), the label's income after artist and producer royalties. Valuations are built on these net figures, so a financial adviser tests them in five steps. 1. **Rebuild from source.** Take each statement as issued by the society, publisher, label or platform and reconcile it to cash received. Differences from the seller's summary are findings. 2. **Split recurring from one-off.** Royalty Exchange's Antony Bruno says buyers "de-emphasise synchronisation because those are one-time payments that you cannot predict as repeatable" ([Synchtank, 2019](https://www.synchtank.com/blog/for-what-its-worth-putting-a-value-on-publishing-catalogues/)). 3. **Measure concentration.** What share of income comes from the top ten songs, one territory or one payer? A catalogue that depends on three songs has the risk profile of three songs. 4. **Look at age and decay.** Older songs with a flat history are easier to forecast than recent hits whose income is falling. Royalty Exchange's "dollar age" weights earnings by song age, and its "trend rate" looks at direction over the last three years. 5. **Allow for lag.** The latest periods are incomplete while societies are still matching. The MLC's 2021 usage rose from an 83.1% initial match rate to 93.9% by March 2026, and 2025 usage stood at 88.6% ([The MLC 2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf)). Do not read a young period as a decline. Then compare the statements with the registrations. A royalty statement is a record of what a society could match to a payee, not of what the songs earned. A work that earns on a platform but is missing or mismatched at a society shows less on the statement than it earned. --- ## What does the due diligence process look like, and what does it cost? *A typical sequence runs from a light screen to a post-close clean-up. Stages overlap, and deals vary.* A buyer screens the top-earning works from public records before an offer, signs a letter of intent that agrees the price basis and exclusivity, receives the data room, then runs the legal, financial and registration workstreams in parallel. The findings feed price, holdbacks, warranties and closing conditions. After closing the work becomes operational: notifying payors and societies, recording the transfer, correcting registrations and claiming pooled money. **A due diligence process in six stages** 1. **Screen.** Public-record check of the top-earning works before any offer; note what was not checked. 2. **Letter of intent.** Price basis, exclusivity, and the agreed data-room request list. 3. **Data room.** Agreements, statements by source, work lists, ISRC / ISWC / IPI lists; gaps requested back. 4. **Three workstreams in parallel.** Legal (chain of title, agreements, transfers, terminations); financial (statements to cash, NPS / NLS, concentration, decay); registration (identity, society registrations, shares, unmatched pools, coverage). 5. **Findings and price.** Adjust price; holdbacks, warranties, indemnities, conditions to closing. 6. **Close and fix.** Notify payors and societies, record the transfer, correct registrations, claim pooled money. How long it takes and what it costs depends on the size of the catalogue, the number of agreements and income sources, and the quality of the data room. We found no reliable published benchmark for fees or duration for music catalogues and do not quote one. Ask each adviser for a fixed scope against the six questions, and for what they will state as not checked. Problems found before signing can change the price or the contract. Problems found afterwards can usually only be fixed. --- ## What are the red flags in a music catalogue? *A red flag is a reason to investigate, not evidence that anything is wrong.* | Signal | Why it matters (question) | |---|---| | Statements that do not reconcile to cash or to the seller's summary | The income base may be overstated *(Collection)* | | Income concentrated in a few songs, one territory or one payer | One change can move the whole stream *(Collection, Risk)* | | A recent spike from one sync placement | One-off income should not be extrapolated *(Collection)* | | Shares that differ between societies, or do not total 100% | At least one society is paying the wrong split *(Registration)* | | A work at one society and absent from another where it earns | The missing society's income may sit unmatched *(Registration)* | | Large unmatched or unclaimed positions for the catalogue's titles | Earned money not reaching the owner, some with deadlines *(Collection, Risk)* | | No signed agreement behind a material writer or share | A registration without a contract is a claim, not title *(Title)* | | Unrecorded transfers, a US termination window opening, or administration expiring soon | Priority disputes; rights may revert or collection may move *(Title, Risk)* | | Duplicate titles, or one recording with several ISRCs | Income split across records that never match *(Identity)* | | Samples without clearance paperwork | A third party may hold a claim on the income *(Risk)* | --- ## How do you get a music catalogue independently rated or certified for investment? *Today you assemble independent reports. As far as TrackForge is aware, no common published catalogue rating exists yet, and TrackForge is building towards one.* As far as TrackForge is aware, there is currently no single, standard, published certification of a music catalogue that a buyer or lender can order. What you can do is commission separate independent reports and require each to state its scope. These are the forms that exist today. - **Independent valuation.** A valuation firm builds a DCF of forecast income. For the Chord Music Partners notes in April 2026, an independent third-party valuation agent valued the catalogue at about $830 million, using an 8% discount rate ([Apollo](https://www.apollo.com/insights-news/pressreleases/2026/04/chord-music-partners-prices-500-million-abs-backed-by-diversified-music-catalog); [Asset Securitization Report](https://asreport.americanbanker.com/news/music-royalty-revenue-supports-chord-musics-500-million-in-abs)). Valuers can differ: Citrin Cooperman valued Hipgnosis Songs Fund's portfolio at $2.62 billion at 8.5% as of September 2023, and Shot Tower Capital at a midpoint of $1.93 billion at 9.63% as of March 2024 ([Music Business Worldwide](https://www.musicbusinessworldwide.com/hipgnosis-songs-funds-assets-are-now-valued-at-690-million-less-than-they-used-to-be-blackstone-will-be-licking-its-lips/)). - **Legal and financial diligence.** Counsel's report on title and agreements; a quality-of-earnings analysis; audits of payors' accounting. - **Registration and metadata audits.** Specialist checks of identifiers and society registrations. - **Credit ratings on bonds backed by catalogues.** Kroll Bond Rating Agency (KBRA) had rated more than $12.9 billion of music royalty bonds since 2020, 81 ratings across 18 issuers, by May 2026 ([Music Business Worldwide](https://www.musicbusinessworldwide.com/as-abs-deals-reshape-the-music-rights-landscape-kbra-says-its-rated-12-9b-in-music-royalty-backed-bonds-since-2020-but-expects-issuance-to-fall-25-in-2026/)). These rate the debt, not the catalogue as an asset for a buyer to price. None of these is a portable, standard measure of how much of a catalogue's expected income is actually collectible, and why. Each is scoped by its author and priced per engagement. A rating that closed that gap would need five properties. | Property | What it means | |---|---| | Standard | The same published criteria for every catalogue, so two ratings can be compared | | Reproducible | A second party can recompute the result from the same frozen inputs | | Coverage stated | For each question, the share of works and income checked, the source and the date | | Independent | Not the seller's narrative, and not the party that fixes the catalogue grading its own work | | In components | Each of the six questions reported, not only a single grade | **What TrackForge is building.** TrackForge is developing an evidence-based catalogue rating on the questions in this guide: registration, collection, title, identity and risk, with coverage stated. It is TrackForge's work towards a common standard for valuing music catalogues. It is in development and cannot be ordered today. What you can do now is run the registration and rights-data check as a workstream of your own diligence, using the free Workspace, and require every adviser to state coverage. [About TrackForge](https://trackforge.studio/about) shows how the Workspace and the rating fit together. --- ## How can a seller prepare a catalogue for sale? *Vendor due diligence means doing the buyer's checks first and fixing what they find.* Vendor due diligence is the seller's own review of a catalogue before it goes to market. A seller can see the state of its registrations; a buyer who cannot has to assume some are wrong and price for that. Fixing and documenting gaps first replaces an unknown with a known. Start months before launch: The MLC says a change "will not impact your royalties until they have been captured" in a monthly database snapshot, and processing times vary ([The MLC](https://www.themlc.com/marketshare)). 1. **Reconcile identifiers.** One list of ISRCs, ISWCs and IPIs. Merge duplicates and link every recording to its work. 2. **Assemble title.** Signed agreements and splits, and transfers recorded where they should be. 3. **Pull what each society holds.** Export the work lists and compare shares across societies and with the contracts. 4. **Register and correct.** File missing registrations, fix wrong shares and parties, resolve conflicts. 5. **Claim what is pooled.** Search unmatched and unclaimed lists for your titles and claim your shares. 6. **Package the evidence.** Statements by source, reconciliation to cash, and a dated registration report that says what was checked. Timing now matters in the US. The MLC intends to begin market-share distribution of unclaimed royalties in April 2027, using a database snapshot on or around 10 February 2027. It says it will pay a claimed share the royalties held for past periods, with statutory interest, except for periods already subject to a market share distribution, so a share claimed late recovers less than one claimed early. Buyers should ask the same question of the seller's claims. The [Music in the Air analysis](https://trackforge.studio/research/music-in-the-air-number-nobody-models) sets out the clock in full. --- ## How does the TrackForge Workspace help with catalogue due diligence? *It shows each work's position at each society, where the societies hold something different, and what has not been checked.* The [TrackForge Workspace](https://trackforge.studio/workspace) is free during the beta: no card is needed, and anyone can sign up with LinkedIn, Google or an email code. The beta has an allowance of saved works, shown on the Account page. A seller can use it to clean a catalogue before marketing it, and a buyer can use it on the schedule of works once the seller shares it. The steps map onto the six questions. 1. **Import the catalogue** from a [spreadsheet or CWR file](https://trackforge.studio/docs/workspace/add-works/), or add works by hand. Nothing is saved until you review the import (identity, title). 2. **Choose the societies** you care about. Each work then shows a [status for each society](https://trackforge.studio/docs/workspace/catalogue/statuses), from ready and prepared to accepted or needs correction (registration). 3. **Open [Registration health](https://trackforge.studio/docs/workspace/registration-health)** to see where each society is up to and what its records hold, counted as Held, Not held or Not checked. Showing "Not checked" as such is the coverage principle in practice. 4. **Read [works registered differently](https://trackforge.studio/docs/workspace/files/registered-differently)**, where a society's accepted registration differs from your catalogue, shares included. Upload old CWR files and society replies as [registration history](https://trackforge.studio/docs/workspace/files/registration-history) to give it something to compare with (registration, risk). 5. **Check [writers, publishers and shares](https://trackforge.studio/docs/workspace/catalogue/shares)** total 100%, add [recordings with their ISRCs](https://trackforge.studio/docs/workspace/catalogue/recordings), and record [agreements](https://trackforge.studio/docs/workspace/agreements) with parties, territories and linked works (title). 6. **Fix what is flagged**, prepare CWR files and send them. An Excel or PDF report of the picture can be shared with advisers. Two limits. The Workspace works on the catalogue as loaded, and it can report what a society holds only where it has a reading, so some cells will say Not checked. It does not replace the lawyer's title work or the accountant's reconciliation. For a first look at individual recordings, [ISRC Lookup](https://trackforge.studio/isrc-lookup) and [Check my music](https://trackforge.studio/check-my-music) are quick first checks of registration data, and people working with an AI assistant can use [the TrackForge MCP server](https://trackforge.studio/mcp). The companion guides go deeper: [verify music rights ownership and metadata](https://trackforge.studio/research/verify-music-rights-ownership-metadata), [music catalogue risk assessment and tools](https://trackforge.studio/research/music-catalogue-risk-assessment), and [find and claim unpaid music royalties](https://trackforge.studio/research/find-unpaid-music-royalties). --- --- - **Diligence practice:** AIMP Los Angeles, [The Vital Importance of Due Diligence to Music Copyright Acquisitions](https://aimp.org/blog/resources_topics/buying/), 19 October 2023 (event listing). Erin M. Jacobson, [Selling a Legacy: Considerations for Buying, Selling, and Administering Music Catalogues](https://synchtank.com/blog/selling-a-legacy-considerations-for-buying-selling-and-administering-music-catalogues), Synchtank, 27 May 2019 (Tim Cohan on legal diligence; Cedar Boschan on financial advisers). Eamonn Forde, [For What It's Worth: Putting a Value on Music Publishing Catalogues](https://www.synchtank.com/blog/for-what-its-worth-putting-a-value-on-publishing-catalogues/), Synchtank, 25 January 2019 (earnings history; Antony Bruno on sync, dollar age and trend rate). - **Identifiers:** [ISRC Standard](https://isrc.ifpi.org/isrc-standard), IFPI; [New ISO standard for worldwide identification of musical works](https://www.iso.org/news/2002/04/Ref821.html), ISO, 2002 (ISO 15707, developed with CISAC). - **US law:** [17 U.S.C. §205](https://www.law.cornell.edu/uscode/text/17/205) (recordation, constructive notice, priority between conflicting transfers); [§203](https://www.law.cornell.edu/uscode/text/17/203) (termination: 35-year window, two-to-ten-year notice, recordation, US rights only, works made for hire excluded); [§507(b)](https://www.law.cornell.edu/uscode/text/17/507) (three-year limitation). - **The MLC:** [2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf), as of the March 2026 distribution: $630,534,162.23 of unmatched and unclaimed royalties held for 2021 to 2025 usage; average match rate for 2021 to 2025 usage 91.9%; 2021 usage 83.1% initial and 93.9% current; 2025 usage 88.6% current. [Market Share](https://www.themlc.com/marketshare), read 28 October 2026: distributions to begin in April 2027, database snapshot on or around 10 February 2027, changes affect royalties only once captured in a monthly snapshot, past-period royalties paid to a claimed share except periods already subject to a market share distribution. - **Valuations and ratings:** Apollo, [Chord Music Partners Prices $500 Million ABS](https://www.apollo.com/insights-news/pressreleases/2026/04/chord-music-partners-prices-500-million-abs-backed-by-diversified-music-catalog), 27 April 2026 (independent third-party valuation agent, about $830 million); [Asset Securitization Report](https://asreport.americanbanker.com/news/music-royalty-revenue-supports-chord-musics-500-million-in-abs) (DCF at an 8.00% discount rate). Music Business Worldwide, [Hipgnosis Songs Fund valuations](https://www.musicbusinessworldwide.com/hipgnosis-songs-funds-assets-are-now-valued-at-690-million-less-than-they-used-to-be-blackstone-will-be-licking-its-lips/), 4 March 2024: Citrin Cooperman $2.62 billion at 8.5% (30 September 2023); Shot Tower Capital $1.80 billion to $2.06 billion, midpoint $1.93 billion at 9.63% (1 March 2024). Music Business Worldwide, [KBRA music royalty bond ratings](https://www.musicbusinessworldwide.com/as-abs-deals-reshape-the-music-rights-landscape-kbra-says-its-rated-12-9b-in-music-royalty-backed-bonds-since-2020-but-expects-issuance-to-fall-25-in-2026/), 18 May 2026: more than $12.9 billion rated since 2020, 81 ratings, 18 issuers. - **Disclosure:** TrackForge checks whether works are registered, matched and claimed at collecting societies, runs the Workspace, and is developing a catalogue rating. No TrackForge client or catalogue figure appears in this guide. Nothing here is legal advice; take advice from a music lawyer on title, transfers and termination. --- *Source: [How to due-diligence a music catalogue before you buy](https://trackforge.studio/research/music-catalogue-due-diligence)* ## research/verify-music-rights-ownership-metadata.md # How to verify music rights ownership and metadata > How to verify music rights ownership and metadata: match chain-of-title documents to what each society register holds, then check IDs, shares and links. *Published by [TrackForge](https://trackforge.studio) — 2026-10-28* *Documents settle who owns a song. Registers settle who gets paid. This is how to check that the two agree, work by work and society by society.* --- **Verifying music rights ownership means matching the documentary chain of title (the signed agreements that move rights from writer to current owner) against what the registers hold. Verifying metadata means checking that the identifiers, titles, parties and shares for every work and recording are complete, consistent and linked in every register that pays.** A society registration is a claim, not proof of legal ownership, and the money follows the registration, so both the paperwork and the registers have to be right. The method is six steps: assemble the documents, build a master list of works and recordings with their identifiers, check each public register, reconcile shares and parties, compare across societies, then record and fix. The [TrackForge Workspace](https://trackforge.studio/workspace) is built around that job. It is free during the beta, needs no card, and anyone can sign up with LinkedIn, Google or an email code. Everything below works with a spreadsheet and a browser too. This guide is for catalogue owners, publishers, labels, managers and buyers. If you are buying a catalogue, pair it with [how to due-diligence a music catalogue before you buy](https://trackforge.studio/research/music-catalogue-due-diligence). For the wider picture of exposure, see [music catalogue risk: what to check and which tools help](https://trackforge.studio/research/music-catalogue-risk-assessment). Once you have found a gap, [how to find unpaid music royalties and claim them](https://trackforge.studio/research/find-unpaid-music-royalties) covers getting the money. ## What are the steps to verify music rights ownership and metadata? Six steps, in this order. Each one is explained below with the registers to use. 1. **Assemble the documents**: Songwriter, publishing, administration, sub-publishing, label and distribution agreements, split sheets and assignments. 2. **Build the master list**: One row per work and per recording, with every identifier, party and share you can find. 3. **Check each public register**: The MLC, ASCAP and BMI, PRS, ISWC Net, SoundExchange, PPL, MusicBrainz and the US Copyright Office. 4. **Reconcile shares and parties**: Each right totals 100% by the society's own convention, with the right people and IPI numbers. 5. **Compare across societies**: The same work registered differently in two places is common, and it costs money. 6. **Record and fix**: Log what you checked, correct the register that is wrong, and re-check after the society processes it. ## Is a society registration proof of who owns a song? No. A registration records what someone told the society. Signed documents are the proof, and the registers decide who is paid. A society registration is a claim made by a member or submitter about who wrote a work, who publishes it and how it is split. Societies pay on that claim. BMI's [Royalty Policy Manual](https://www.bmi.com/rpm) says it enters a work for the shares and participants shown on the first registration it receives, and that a later conflicting registration prompts a request for documentation from everyone affected. PRS's [music registration policy](https://www.prsformusic.com/works/how-copyright-works/music-registration-policy) makes writers and publishers responsible for registering and amending their works. Proof of title is different. In the United States, a transfer of copyright ownership is not valid unless there is a signed writing ([17 U.S.C. §204(a)](https://www.copyright.gov/title17/92chap2.html)). In the UK, an assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor ([Copyright, Designs and Patents Act 1988, s.90(3)](https://www.legislation.gov.uk/ukpga/1988/48/section/90)). US copyright registration is voluntary, and a certificate made within five years of first publication is prima facie evidence of the facts it states ([17 U.S.C. §410(c)](https://www.copyright.gov/title17/92chap4.html)). Recording a transfer is not required for it to be valid, but it carries legal advantages ([Circular 1](https://www.copyright.gov/circs/circ01.pdf)). | | Role | What it is | |---|---|---| | Documents | Proof | Signed agreements, assignments, split sheets and termination notices. They decide who owns and controls each right. | | Registers | Claim | What each society holds today. They decide who is paid, how much, and who is left unpaid. | ## What do ISRC, ISWC, IPI, ISNI and UPC each identify? Each code names one kind of thing. None of them proves ownership, and the links between them are where the money goes missing. An ISRC (International Standard Recording Code) identifies one sound recording. An ISWC (International Standard Musical Work Code) identifies one musical work, the song itself. An IPI (Interested Parties Information) number identifies a songwriter, composer or publisher, and a UPC or EAN identifies a release as sold. The [IFPI ISRC Handbook](https://usisrc.org/wp-content/uploads/2024/11/ISRC_Handbook.pdf) sets the rule that each recording gets one ISRC for life, even when ownership changes, and that remixes, live versions and edits get their own. The [IPI system](https://www.cisac.org/services/information-services/ipi) follows the standards of CISAC, the international confederation of authors' societies, and is administered by the Swiss society SUISA. The MLC explains how it uses each code in its guide to [identifiers](https://blog.themlc.com/resources/know-your-identifiers). **Four identifiers, three links. The ISRC-to-ISWC link is the one that decides whether a stream is paid to the song's owners.** Graphic: how the identifiers connect. | Level | Identifier | Held by | |---|---|---| | Writer or publisher | IPI, ISNI | IPI system (CISAC rules) and each society's members | | Link: shares and chain of title | Society registrations, backed by your agreements | Each society | | Musical work (the song) | ISWC, society work codes (for example a PRS tunecode) | Each society's work register and the ISWC database | | Link: ISRC-to-ISWC link (most often missing) | Matching of recordings to works | The MLC, ICE (for PRS and MCPS), label and publisher data | | Sound recording | ISRC | SoundExchange ISRC Search, PPL, labels, distributors | | Link: appears on | Release metadata | Distributors | | Release (the product) | UPC / EAN | Distributors, retailers and the GS1 barcode system | Without the ISRC-to-ISWC link, a recording's streams cannot be matched to the owners of its song. | Identifier | Identifies | What it proves | What it does not prove | |---|---|---|---| | ISRC | One recording (12 characters: country, registrant, year, designation) | That the recording exists and was coded by its rights owner or their agent | Who owns the master, who wrote the song, or which work it embodies | | ISWC | One musical work, whoever records it | That societies are talking about the same song | Who owns it. It does not identify recordings either | | IPI name number and base number | A writer or publisher (the base number is the person, the name number is one of their names) | Who the party is, across name variants | That they own or control anything on a given work | | ISNI | A public identity across creative fields, including artists, writers, labels and publishers | That two similar names are, or are not, the same person | Anything about a share. It does not replace the IPI in a registration | | UPC / EAN | A release (album or single) as a product | Which release a recording was sold on | Rights in the recordings or the songs on it | Societies also use their own work codes, such as a PRS tunecode or an MLC song code. Royalty statements are the best place to find them, and the Workspace keeps the ones a society's files have confirmed against each work. ## Why does an unlinked recording earn no publishing mechanicals? Streaming services report recordings. Publishing royalties belong to songs. Until something links the two, the money is held. An unlinked recording is paid no publishing mechanical royalties because the service reports usage by ISRC, while the royalty belongs to the work and its owners. The MLC, which collects US digital mechanical royalties, can only pay when a recording is matched to a registered work (see its [Matching Tool guide](https://help.themlc.com/en/support/what-is-the-matching-tool)), and calls the held remainder "unmatched" (no work found) or "unclaimed" (a work found, but less than 100% of its shares claimed). Its [2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf) shows a 91.9% average match rate by value for 2021 to 2025 usage, and still $630.5 million of unmatched and unclaimed royalties held at March 2026. The UK has the same structural gap: PRS's chief executive has called linking ISWCs to ISRCs at the point of release "crucial" and something that "has long been an obstacle for music creators" ([Complete Music Update](https://completemusicupdate.com/tag/iswc)). **What This Means For A Check.** A work can be perfectly registered and still earn nothing from streams if none of its recordings is linked to it. Verify the link in both directions: from each work to its recordings, and from each recording back to its work. ## Which documents prove who owns a music catalogue? A chain of title is complete when every transfer, from each author to the current owner, is documented and signed. A chain of title is the unbroken sequence of signed documents that moves each right from its creator to the party now claiming it. Gather these, for every work: - **Songwriter and publishing agreements**, including any co-publishing deal, with their dates, territories, retained rights and any reversion or termination terms. - **Administration and sub-publishing agreements**, with the territories, term and any post-term collection period. These decide who may collect and where. - **Label, licence and distribution agreements** for the recordings. The master is a separate right from the song and usually has a different owner. - **Split sheets and writer agreements** that record who contributed what. A verbal split is the most common cause of later conflict. - **Assignments, catalogue sale deeds and termination notices**, and any recordation at the Copyright Office. Check the three ownership layers separately: the composition (writers and publishers), the sound recording (artist, label or distributor) and performers' rights. A gap in any link, such as a writer who never signed or an agreement that ended, means the registers may be paying someone the documents do not support. For a purchase, this step is the core of [catalogue due diligence](https://trackforge.studio/research/music-catalogue-due-diligence). ## How do you build a master list of works and recordings? One row per work and one per recording, every identifier you hold, and a blank where you do not know. A master list is the working table you check every register against. For each work, record the title and alternative titles, ISWC, society work codes, each writer with their IPI name number and role, each publisher with their role (original, administrator or sub-publisher), territories and dates, and the share each party holds in each right. For each recording, record the ISRC, artist, label, release date, UPC or EAN, and the work it belongs to. Pull the data from your own records, your distributor and label reports, and your royalty statements. Validate formats as you go. An ISRC is 12 characters. An IPI name number is 11 digits (older CAE numbers had nine, so keep leading zeros). A song with two ISRCs is one work with two recordings, not two works. The Workspace follows exactly this model, with a [work editor](https://trackforge.studio/docs/workspace/catalogue/edit-a-work), [recordings with ISRCs](https://trackforge.studio/docs/workspace/catalogue/recordings) and imports from [a spreadsheet or CWR file](https://trackforge.studio/docs/workspace/add-works/). ## Where can you check who owns a song for free? Eight sources, each showing one slice. None is the whole picture, so check more than one. Several registers can be searched without paying. Each shows only what its members and rights owners told it, and each has limits you should record next to the result. | Register | What it shows | What to remember | |---|---|---| | [The MLC Public Work Search](https://portal.themlc.com/search#work) | Ownership information on more than 55 million songs, free to anyone ([The MLC tools](https://www.themlc.com/tools)) | US digital mechanical rights only. Shows claims, not contracts, and unclaimed shares appear as gaps | | [ASCAP Repertory](https://www.ascap.com/repertory/about), [BMI Repertoire](https://repertoire.bmi.com/) and [Songview](https://songview.com/) | Writers, publishers and shares for US performing rights. Songview reconciles ownership data from ASCAP, BMI, GMR and SESAC and feeds the public ASCAP and BMI databases | US performing rights only. Share data covers the US, and a work can be absent while its shares are disputed | | [PRS for Music Search works](https://www.prsformusic.com/terms-of-use/search-works) | Writers, publishers and the shares registered with PRS, for members | Members' service, for checking your own interests. PRS and MCPS are separate societies, so check mechanical rights there too | | [ISWC Net](https://iswcnet.cisac.org) (CISAC) | Whether a work has an ISWC, and the title and creators against it | A registry of identifiers and credits, not of contracts or shares | | [SoundExchange ISRC Search](https://isrc.soundexchange.com/#!/search) | Recording metadata by ISRC, artist, title, release or UPC and EAN | Recordings only. Says nothing about the song's writers or publishers | | [PPL Repertoire Search](https://repsearch.ppluk.com/ars/faces/pages/audioSearch.jspx) | UK recording rightsholder for public performance and broadcast, by artist, title or ISRC | PPL calls it "a general guide only". A missing result does not prove a recording is unregistered | | [MusicBrainz](https://musicbrainz.org/doc/About) | Community-edited database with ISRCs on recordings and ISWCs on works | Edited by volunteers. Use it to find leads, then confirm elsewhere | | [US Copyright Office Public Records System](https://publicrecords.copyright.gov) | Registrations and recorded documents from 1978 to now ([announcement](https://copyright.gov/newsnet/2025/1071.html)) | Registration is voluntary, so no record does not mean no copyright. Records carry no ISWC or ISRC, so you match by title and names | [ISRC Lookup](https://trackforge.studio/isrc-lookup) is a quick way to check a single recording: it cross-references an ISRC across Spotify, MusicBrainz and The MLC. [Check my music](https://trackforge.studio/check-my-music) does a similar job for US mechanical royalties. For a whole catalogue, the Workspace's [Registration health](https://trackforge.studio/docs/workspace/registration-health) tab shows, per society, which works the society's own records hold, do not hold, or have not been checked. ## How do you reconcile shares, parties and IPI numbers? Each right must total 100% by the society's own convention, and every party must be the right person. Reconciling shares means making the writer and publisher percentages in every register agree with the documents, and total correctly for each right. The conventions differ by society, so a figure copied from one register into another can be wrong even when it is arithmetically fine. | Where | Convention | Source | |---|---|---| | A CWR (Common Works Registration) file | Ownership shares for each right total 100%, within a 0.06% tolerance | [The MLC CWR User Guide](https://themlc.com/hubfs/CWR%20User%20Guide_May%202024_FINAL.pdf) | | BMI performing rights | Writers and publishers are one 200% unit: writers total 100% and publishers total 100% | [BMI Royalty Policy Manual](https://www.bmi.com/rpm) | | PRS performing rights | Writers receive no less than 50% of the royalty; if no split is given, 50% writer and 50% publisher | [PRS registration policy](https://www.prsformusic.com/works/how-copyright-works/music-registration-policy) | | MCPS mechanical rights | Published music pays 100% to the publisher; unpublished pays 100% to the writers who are members | [PRS registration policy](https://www.prsformusic.com/works/how-copyright-works/music-registration-policy) | | The MLC mechanical rights | Shares claimed below 100% leave the remainder unclaimed, which The MLC holds | [The MLC 2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf) | Then check the parties. Confirm each writer's full name and IPI name number, and that two people with similar names are not merged. Confirm the publisher chain: one original publisher, with administrators and sub-publishers shown with their territories and dates. Watch rounding too: three equal shares must be written 33.33, 33.33 and 33.34, not three of 33.33. The Workspace checks this for you in [writers, publishers and shares](https://trackforge.studio/docs/workspace/catalogue/shares), totalling each right on its own and warning on an IPI whose last two digits do not fit. ## Why does the same work look different at different societies? Each society keeps its own database, and registrations reach each one separately. Differences are normal, and they cost money. A work registered differently is the same song held at two societies, or in a society and your records, with different shares, parties, titles or identifiers. It happens because each society keeps its own database and registrations arrive at different times through different routes, such as a direct member registration at one society and a sub-publisher's file at another. Songview, the shared ASCAP and BMI platform, exists to reconcile data that each society holds separately. Common differences are a different split, a publisher present at one society and absent at another, a missing ISWC, and an old administrator still listed. For every work, compare what each register holds with your master list, and with each other. Where two societies disagree, work out which is right using the documents, not which is newer. In the Workspace, [Works registered differently](https://trackforge.studio/docs/workspace/files/registered-differently) lists works where a society's accepted registration differs from your catalogue. For each, you can update your catalogue, keep it and record why, or prepare a revision for the society. To bring the societies' accepted registrations into that comparison, you [upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history): the CWR file and the society's response that accepted it. **What to do when documents and registers are compared.** Graphic: comparing documents with registers. | Outcome | What to do | |---|---| | 1. They agree | Record what you checked, where, and on what date. | | 2. The register is wrong or incomplete | Correct it at that society: portal, CWR file or sub-publisher. | | 3. The documents are missing or unclear | Find the signed paper before you change any register. | | 4. Another party claims the same share | Use that society's dispute process, with the documents. | Never overwrite a register to match your own spreadsheet. Settle which side is right first. ## How do you record and fix what you find? Log every check, correct the right register, and check again once the society has processed the change. Recording and fixing means keeping an evidence log and making each correction at the source that is wrong. For every check, record the register, the date, the result and a saved copy. Then correct the register: the owner or publisher updates a society registration through that society's portal, a CWR file or their sub-publisher, and foreign societies are usually reached through sub-publishers. Where another party claims the same share, each society has its own dispute process. PRS's registration policy points to its Duplicate Claims and Disputes policy, for example. Allow time for changes to land. PRS says registrations are generally set up on its works database within two working days, and payment follows on a later distribution. Check the register again afterwards and keep the new result. The Workspace keeps this record for you in [registration history](https://trackforge.studio/docs/workspace/files/registration-history) and in each work's [saved versions](https://trackforge.studio/docs/workspace/catalogue/history). If the fix is a new registration, you can [prepare a CWR file](https://trackforge.studio/docs/workspace/files/prepare), send it, and read the society's reply. ## What does good music metadata look like? A field-by-field checklist for a metadata audit: what good looks like, how it fails, and what the failure costs. | Field | What good looks like | Common failure | Consequence | |---|---|---|---| | Title | One main title, with alternates recorded as alternates, spelt the same in every register | Variants, "(Live)" pasted into titles, duplicate records for one song | Split records, failed matching, royalties spread across duplicates | | ISWC | One ISWC per work, the same everywhere | Missing, or two ISWCs for one song | Works cannot be joined across societies; matching falls back on title and names | | Writers | Full legal name, IPI name number and role for every writer | Missing or wrong IPI, name only, writer merged with a namesake | Share cannot be paid to the right person; may sit unclaimed | | Publisher chain | One original publisher; administrators and sub-publishers with territories and dates | Publisher at one society and not another; expired administrator still registered | Money to the wrong party, or held while the societies disagree | | Shares | Each right totals 100% by the society's convention | Totals of 90% or 110%; rounding; a PRS split copied into a US registration | Unclaimed or over-claimed shares, rejected or disputed registrations | | Territories and dates | Match the agreement exactly | World rights claimed on a UK-only deal; no end date | Over-claims abroad; payments continuing after a deal ends | | Recordings | Every released recording has an ISRC linked to its work | Unlinked ISRCs; one ISRC on two recordings; two ISRCs on one | Unmatched usage and held royalties | | Release | UPC or EAN on every release, tied to its recordings | Missing barcodes; re-issues with new codes and no cross-reference | Weaker matching and harder audits | | Society codes | Each society's work code stored against the work | Not recorded anywhere | You cannot compare or revise the registration | | Agreement reference | Each registration points to the agreement behind it | No agreement number quoted | A weaker registration that can be harder to defend if another party challenges it | ## What are the most common music metadata failures? Eight patterns account for most of the cost. Each can be spotted from the registers. - **Missing ISWC.** Search the work at ISWC Net and at each society. If the society holds it but the ISWC is blank, the work may be harder to join elsewhere. - **Wrong or missing IPI.** Look for writers with a name but no IPI, and for IPI numbers that fail their check digits. - **Splits that do not total 100%.** Add up each right, using the society's convention, and look for 99.99 and 100.01. - **Title variants and duplicates.** Search by writer as well as title, and look for several records of one song. - **Unlinked ISRCs.** Search each ISRC at The MLC and SoundExchange and confirm it resolves to the right work. - **A publisher at one society but not another.** Compare the publisher chain across PRS, The MLC and ASCAP or BMI. - **Expired administration still registered.** Check each administrator's end date against the register, allowing for any post-term collection period. - **Conflicting claims.** Look for works where two parties claim the same share, which societies usually hold until the parties settle it. ## How does the TrackForge Workspace help verify ownership and metadata? It puts the master list, the society comparison and the fixes in one place. It does not decide ownership: that stays with your documents. The [TrackForge Workspace](https://trackforge.studio/workspace) is a free catalogue workspace for exactly this job. Import your catalogue and it shows each work's status at each society, with checks that flag what is missing. It records the facts of your deals alongside the works, but it does not read your contracts or settle a dispute for you. | Step | In the Workspace | Docs | |---|---|---| | 1. Documents | Agreements: type (publishing, administration, sub-publishing), parties with IPIs, territories, dates and society numbers, linked to the works they cover | [Agreements](https://trackforge.studio/docs/workspace/agreements) | | 2. Master list | Import a spreadsheet, CWR file or work by hand; recordings with ISRC, label, release date and EAN or UPC; reminders on works with no ISWC or no ISRC | [Recordings](https://trackforge.studio/docs/workspace/catalogue/recordings) | | 3. Registers | Registration health: what each society's own records hold (held, not held, not checked); a US Copyright Office panel that finds records naming the same title and parties, as leads not proof | [Registration health](https://trackforge.studio/docs/workspace/registration-health), [Additional details](https://trackforge.studio/docs/workspace/catalogue/additional-details) | | 4. Shares and parties | Writers, publishers and shares with a 100% total checked for each right, IPI checks and a rounding fix | [Shares](https://trackforge.studio/docs/workspace/catalogue/shares) | | 5. Compare societies | Works registered differently: the differences laid out, with three ways to settle each | [Registered differently](https://trackforge.studio/docs/workspace/files/registered-differently) | | 6. Record and fix | Fix problems on a work, saved versions of every edit, prepare and send a CWR file, upload and read society responses, registration history | [Fix problems](https://trackforge.studio/docs/workspace/catalogue/fix-problems), [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare) | To start, follow [your first file in six steps](https://trackforge.studio/docs/workspace/start-here). For a single recording, [ISRC Lookup](https://trackforge.studio/isrc-lookup) is quicker. If you work with an AI assistant, TrackForge also runs an [MCP server](https://trackforge.studio/mcp) that can look up a recording's registration data. TrackForge is also building an evidence-based catalogue rating, working towards a common standard for how a catalogue's rights and registrations are assessed. It is in development and is not available yet. ## Where does verification fit with due diligence, risk and recovery? Verification is the evidence layer the other three jobs rely on. 1. **Due diligence**: [How to due-diligence a music catalogue before you buy](https://trackforge.studio/research/music-catalogue-due-diligence): the buyer's checklist, built on this verification. 2. **Risk**: [Music catalogue risk: what to check and which tools help](https://trackforge.studio/research/music-catalogue-risk-assessment): where exposure sits and which tools help. 3. **Recovery**: [How to find unpaid music royalties and claim them](https://trackforge.studio/research/find-unpaid-music-royalties): what to do once a gap is found. ## Frequently asked questions ### How do I verify who owns a song? Match the signed documents that move rights from the writer to the current owner against what the registers hold. Gather the agreements, build a list of works with identifiers, then check The MLC, ASCAP and BMI, PRS, ISWC Net, SoundExchange and the US Copyright Office. A register entry is a claim, not proof. ### Is a society registration proof of ownership? No. A society registration records what a member or submitter told the society, and the society pays on that claim. Proof of title is the signed chain of agreements and assignments. ### What is the difference between an ISRC and an ISWC? An ISRC identifies one sound recording and an ISWC identifies one musical work, the song itself. A song has one ISWC however often it is recorded, while each recording version has its own ISRC. Publishing royalties from streams need the two linked. ### How do I check music metadata quality? Build a master list of every work and recording, then check each field against the registers: one main title, one ISWC, full writer names with IPI numbers, a documented publisher chain, shares totalling 100% by each society's convention, and every ISRC linked to its work. ### Where can I search who owns a song for free? Free public sources include The MLC Public Work Search, the ASCAP and BMI repertory searches and Songview, ISWC Net, SoundExchange ISRC Search, PPL Repertoire Search, MusicBrainz and the US Copyright Office Public Records System. PRS Search works is for members. Each shows only part of the picture. ### Why must shares add up to 100%? Each right is a whole divided between parties, so a CWR registration's shares for each right total 100% within a 0.06% tolerance. Below that the remainder is unclaimed and held; above it the claims overlap and may be disputed. Conventions differ by society: BMI treats writers and publishers as a 200% unit. ### What happens if a recording is not linked to a work? Streaming services report recordings by ISRC, while publishing royalties belong to the work. If the recording is not matched to a registered work, the society cannot pay the work's owners and holds the money. The MLC reported $630.5 million of unmatched and unclaimed royalties held at March 2026. ## Sources and disclosure **The MLC:** [2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf): 91.9% average match rate by royalty value for 2021 to 2025 usage as of the March 2026 distribution; unmatched and unclaimed royalties held, by usage year ($630.5 million across 2021 to 2025). [Tools](https://www.themlc.com/tools), [identifiers guide](https://blog.themlc.com/resources/know-your-identifiers) and [CWR User Guide, May 2024](https://themlc.com/hubfs/CWR%20User%20Guide_May%202024_FINAL.pdf). **US law and Copyright Office:** [17 U.S.C. Chapter 2](https://www.copyright.gov/title17/92chap2.html) (§204(a), §205), [Chapter 4](https://www.copyright.gov/title17/92chap4.html) (§408, §410(c)), [Circular 1](https://www.copyright.gov/circs/circ01.pdf), and the [Public Records System announcement](https://copyright.gov/newsnet/2025/1071.html) of 24 June 2025. **UK law and PRS:** [Copyright, Designs and Patents Act 1988, s.90](https://www.legislation.gov.uk/ukpga/1988/48/section/90); PRS [music registration policy](https://www.prsformusic.com/works/how-copyright-works/music-registration-policy) and [Search works terms](https://www.prsformusic.com/terms-of-use/search-works); [Complete Music Update](https://completemusicupdate.com/tag/iswc) on PRS and ISWC-ISRC linking. **US performing rights:** BMI [Royalty Policy Manual](https://www.bmi.com/rpm); [Songview](https://songview.com/); [ASCAP Repertory](https://www.ascap.com/repertory/about). **Identifiers:** [IFPI ISRC Handbook (4th edition, 2021)](https://usisrc.org/wp-content/uploads/2024/11/ISRC_Handbook.pdf); [CISAC IPI system](https://www.cisac.org/services/information-services/ipi); [SoundExchange ISRC Search](https://isrc.soundexchange.com/#!/search); [PPL Repertoire Search](https://repsearch.ppluk.com/ars/faces/pages/audioSearch.jspx); [MusicBrainz](https://musicbrainz.org/doc/About). **Disclosure:** TrackForge builds the Workspace described above. No TrackForge client or catalogue figure appears in this guide; every number is from the published source named beside it. --- *Source: [How to verify music rights ownership and metadata](https://trackforge.studio/research/verify-music-rights-ownership-metadata)* ## research/music-catalogue-risk-assessment.md # Music catalogue risk: what to check and which tools help > Music catalogue risk assessment: the 13 risks to check, how to detect each, what settles it, and which tools help, from society registers to valuation models. *Published by [TrackForge](https://trackforge.studio) — 2026-10-28* Music catalogue risk assessment is the work of testing, risk by risk, whether the seller owns what it is selling, whether the income is fully collected, and whether that income will last. The main risks are title, reversion and termination rights, expiring deals, registration and collection leakage, conflicting claims, sample clearance, litigation, counterparty exposure, income concentration, decay, rate and platform change, currency and territory mix, and gaps in the review itself. No one tool covers them all: public registers settle what is registered, statements show what was paid, lawyers settle title, and valuation models only price what the others find. Most of these risks are decided by documents: agreements, statements and society records. Two of them, registration and collection leakage and conflicting claims, are decided by what each collecting society actually holds, and a royalty statement cannot show that. The [TrackForge Workspace](https://trackforge.studio/workspace) is built for that part. Import the catalogue, see what each society holds against it, fix the differences and send the registrations again. It is free during the beta, needs no card, and anyone can sign up. This is the third of four guides. For the buy-side process read [how to due-diligence a music catalogue before you buy](https://trackforge.studio/research/music-catalogue-due-diligence). To test a single work, read [how to verify music rights ownership and metadata](https://trackforge.studio/research/verify-music-rights-ownership-metadata). For money that is already missing, read [how to find unpaid music royalties and claim them](https://trackforge.studio/research/find-unpaid-music-royalties). ## What are the main risks in a music catalogue? Thirteen risks, grouped by the question each one answers. Each is explained below with how to detect it, what settles it and how it hits value. Music catalogue risk is the chance that a catalogue's income is lower, later or less secure than its royalty statements suggest, or that the seller cannot pass on what it claims to sell. A catalogue is a bundle of rights: the song copyright (the composition, administered through publishers and through performing-right and mechanical-right societies) and the recording copyright (the master, whose performance income is collected by bodies such as PPL, Phonographic Performance Limited, in the UK and SoundExchange in the US). Each right can fail in its own way. Some failures remove a work from the sale, some quietly cut what is collected, and some change the forecast without touching today's income. The thirteen risks fall into four groups: does the seller own and control the rights (1 to 3), are they registered, cleared and collected (4 to 8), will the income last (9 to 12), and what did the review not cover (13). | # | Risk | The question it asks | Mainly hits | |---|---|---|---| | 1 | **Title and chain of title** | Can the seller prove it owns, or controls, each right it is selling? | Whether a work can be sold at all | | 2 | **Reversion and termination** | Can the author or the author's heirs take rights back, and when? | Years of ownership left | | 3 | **Expiring terms** | When do the administration, sub-publishing and licence deals end? | Control of income after expiry | | 4 | **Registration and collection leakage** | Is each work registered where it earns, with the right shares, and is the money arriving? | The income base | | 5 | **Duplicate and conflicting registrations** | Does anyone else claim a share, or hold a second registration of the same work? | Income base and timing | | 6 | **Sample and interpolation clearance** | Is every borrowed element licensed? | Individual works, plus exposure | | 7 | **Litigation and infringement** | Is any claim made, or likely, that the catalogue copies or has been copied? | Cash and individual works | | 8 | **Counterparty and administrator** | Who holds the money, and what if they pay late, short or not at all? | Cash in transit and control | | 9 | **Income concentration** | How much of the income rests on a few songs, platforms or payers? | Range of outcomes | | 10 | **Revenue decay and catalogue age** | How fast does income fall, and from what base? | The forecast curve | | 11 | **Rate and platform** | What if regulated rates or platform pricing change? | Every pound in that right | | 12 | **FX and territory mix** | Where is the income earned, in which currency, and is it registered there? | Reported value and collection | | 13 | **Data and coverage** | What did the review itself not check? | Confidence in all the above | ## Which risks matter most, and which can you see from statements? Plot each risk by its possible effect on value and by how well a royalty statement reveals it. The costly, hidden corner is where to start. **Risk heat map: value impact against visibility on royalty statements.** Placement is TrackForge's editorial judgement of typical positions for a streaming-era catalogue, not measured data. | # | Risk | Value impact if real (editorial) | Visible on statements? (editorial) | Quadrant | |---|---|---|---|---| | 1 | Title and chain of title | higher | hidden | hidden and costly: check first | | 2 | Reversion and termination | higher | hidden | hidden and costly: check first | | 3 | Expiring terms | higher | visible | visible and costly: model it | | 4 | Registration and collection leakage | higher | hidden | hidden and costly: check first | | 5 | Duplicate and conflicting registrations | higher | hidden | hidden and costly: check first | | 6 | Sample and interpolation clearance | lower | hidden | hidden, smaller: clear | | 7 | Litigation and infringement | lower | hidden | hidden, smaller: clear | | 8 | Counterparty and administrator | lower | visible | visible, smaller: monitor | | 9 | Income concentration | higher | visible | visible and costly: model it | | 10 | Revenue decay and catalogue age | higher | visible | visible and costly: model it | | 11 | Rate and platform | higher | visible | visible and costly: model it | | 12 | FX and territory mix | lower | visible | visible, smaller: monitor | | 13 | Data and coverage | higher | hidden | hidden and costly: check first | The heat map places each risk by two things: how much it can move the value of a catalogue if it is real, and how well royalty statements reveal it. The right-hand side is the dangerous one, because the risks there leave no trace on a statement. A work that was never registered earns nothing that appears as a line, a reversion date appears on no statement, and a review that skipped a society reports nothing about it. Risks on the left, such as concentration and decay, can be read straight from the numbers, and buyers already price them. The placements are TrackForge's editorial judgement of typical positions for a streaming-era catalogue, not measured data. Any one catalogue will differ: a catalogue of pre-1990 grants moves reversion up, and a one-artist catalogue moves concentration up. > The risks that matter most are the ones a royalty statement cannot show. ## Does the seller own and control what is being sold? Title, reversion and expiring terms decide how much of a catalogue the buyer actually gets, and for how long. ### 1. Title and chain-of-title risk Chain of title is the documented sequence of transfers that carries each right from its writers or performers to the current owner. Title risk is a missing, unsigned or conflicting link in that sequence. In the UK an assignment of copyright is not effective unless it is in writing and signed by or on behalf of the assignor ([Copyright, Designs and Patents Act 1988, s.90(3)](https://www.legislation.gov.uk/ukpga/1988/48/section/90)), and the government states that [there is not a register of copyright works in the UK](https://www.gov.uk/copyright), so title rests on the contracts themselves. In the US, transfers can be recorded at the Copyright Office. Where two transfers conflict, section 205(d) ranks them by execution and recording dates, and a recorded document gives public notice only if the work is itself registered ([17 U.S.C. §205](https://www.law.cornell.edu/uscode/text/17/205)). **How to detect it.** Build a schedule of every work and recording, each right in it, and the document that gives the seller that right. Trace the works that earn most back to signed agreements with every writer, producer and featured performer, and search the Copyright Office's [public records](https://publicrecords.copyright.gov/) for recorded documents naming the title. **What settles it.** Signed, complete agreements, read together with the society registers. A register entry is a claim, not proof of title. **How it hits value.** A broken link can take a work out of the sale or leave the buyer with a disputed claim, so it is usually priced work by work, through a price holdback or a condition of sale, rather than through the discount rate. The full process is in [how to due-diligence a music catalogue](https://trackforge.studio/research/music-catalogue-due-diligence), and the one-work test is in [how to verify music rights ownership and metadata](https://trackforge.studio/research/verify-music-rights-ownership-metadata). ### 2. Reversion and termination rights Reversion and termination rights are statutory rules that return rights to a creator, or the creator's heirs, after a fixed time whatever the original contract said. In the US, section 203 lets an author terminate a grant made on or after 1 January 1978 (works made for hire are excluded) during a five-year window that starts 35 years after the grant. If the grant covers the right of publication, the window starts at the earlier of 35 years from publication and 40 years from the grant. Notice must be served 2 to 10 years before the effective date and recorded at the Copyright Office before it, and no contract can waive the right ([17 U.S.C. §203](https://www.law.cornell.edu/uscode/text/17/203)). Section 304(c) gives a similar right over pre-1978 grants, in a five-year window starting 56 years after the copyright was originally secured. Section 304(d) is a second chance, with a window starting at 75 years, for grants whose first window had closed unused when the 1998 term extension took effect ([17 U.S.C. §304](https://www.law.cornell.edu/uscode/text/17/304)). **Rights-recapture clocks.** | Rule | Starting event | Window in which termination can take effect | Notice | |---|---|---|---| | US s.203, grants made on or after 1 January 1978 | The grant (or publication, if the grant covers publication) | Years 35 to 40 after the grant (earlier of 35 years from publication and 40 from the grant if publication is covered) | Served 2 to 10 years before the effective date and recorded before it | | US s.304(c), grants made before 1978 | Copyright originally secured | Years 56 to 61 | As s.203 | | US s.304(d), second chance | Copyright originally secured | Years 75 to 80 | As s.304(c) | | UK, assignments by the author as first owner made after the 1911 Act and before 1 June 1957 (CDPA 1988 Sch 1 para 27) | The author's death | The assignment stops operating 25 years after death; the reversionary interest belongs to the author's estate | None in the statute | Termination does not erase the past. A derivative work prepared under the grant before termination, such as an existing recording of a song, may continue to be used on the old terms (§203(b)(1) and §304(c)(6)(A)), and in [*Mills Music v. Snyder*](https://www.law.cornell.edu/supremecourt/text/469/153) (1985) the Supreme Court let a publisher keep its contractual share of royalties from such recordings. Both statutes also say termination affects only rights arising under the US Act. In January 2026 the Fifth Circuit held in [*Vetter v. Resnik*](https://www.musicbusinessworldwide.com/the-majors-and-bmg-asked-the-us-supreme-court-to-overturn-a-ruling-that-lets-songwriters-reclaim-copyrights-worldwide-five-things-to-know-about-vetter-v-resnik/) that terminating a 1963 grant under section 304(c) returned the rights worldwide. The Supreme Court's [order list of 19 October 2026](https://www.supremecourt.gov/orders/courtorders/101926zor_q8l1.pdf) records that judgment as affirmed under 28 U.S.C. §2109 because the Court lacked a quorum, with the same effect as affirmance by an equally divided court. Treat worldwide recapture as a live question, not a settled one, outside the Fifth Circuit. The UK has no general equivalent of section 203 for later grants, but an older rule survives for pre-1957 assignments. Where an author who was first owner assigned copyright after the 1911 Act and before 1 June 1957, the assignment gives the assignee nothing beyond 25 years from the author's death. The reversionary interest then belongs to the author's estate, unless the author assigned it during life. Collective works are excluded ([CDPA 1988, Schedule 1, paragraph 27](https://www.legislation.gov.uk/ukpga/1988/48/schedule/1)). **How to detect it.** Record, for every work, the authors, the date of each grant, the date of first publication, whether the work was made for hire, whether each author is alive and, for UK works, the date of death. Then compute the windows. On the statute's arithmetic (ours), a grant signed on 1 June 1990 can be terminated from 1 June 2025 to 31 May 2030, and a notice naming a 2030 effective date could be served from 2020 to 2028. Grants signed from 1978 to about 1991 have reached their windows, and a notice can already be served for grants signed up to about 2001. Search the Copyright Office's [recorded notices of termination](https://www.copyright.gov/recordation/termination.html) for the catalogue's titles. The Workspace's US Copyright Office panel does that search work by work. **What settles it.** The grant documents, work-for-hire status and a lawyer's reading. **How it hits value.** Reversion removes income after the effective date, less the income from pre-termination recordings that the old terms still cover. It weighs most in catalogues of songs signed away in the 1980s and 1990s, whose windows are open now or open within a few years. ### 3. Expiring administration, sub-publishing and licence terms An administration agreement lets an administrator register, collect and account for a publisher's songs for a term. A sub-publishing agreement does the same for a territory, and a licence grants limited rights. When the term ends, the right to collect, and sometimes the income itself, moves elsewhere, often after a post-term collection period in which the outgoing party keeps collecting. **How to detect it.** List every agreement with its parties, territories, start and end dates, any retention or post-term collection period, renewal and notice mechanics, assignment and change-of-control clauses, and audit rights. Link each work to its agreement. Then compare with the societies: the administrator or sub-publisher of record in each territory should match the contract in force. **What settles it.** The signed agreements and the societies' records of who is registered to collect. **How it hits value.** A buyer pays only for income it will control. Rights that fall away in two years are worth two years of income plus whatever the buyer can renegotiate, and a change-of-control clause can stop the sale until the counterparty consents. The Workspace's [agreements](https://trackforge.studio/docs/workspace/agreements) record publishing, administration and sub-publishing deals with their parties, territories and dates, and link each to the works it covers. ## Is every work registered, cleared and collected? These five risks decide whether the income that songs and recordings earn is the income that arrives. ### 4. Registration and collection leakage Registration and collection leakage is income that a catalogue's songs and recordings earn but the owner does not receive, because a work is unregistered at a society, registered with the wrong shares or details, not linked to its recording, or held in a pool of unmatched or unclaimed money. The scale is published. The 2025 Annual Report of the Mechanical Licensing Collective (The MLC) shows [$630.5 million of unmatched and unclaimed US mechanical royalties](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf) held for 2021 to 2025 usage as of March 2026. That sits beside an overall match rate by value of [91.9%](https://www.copyright.gov/rulemaking/mma-designations/2024/MLC-Ex-Parte-Meeting-Summary-2025-11-20.pdf), reported to the Copyright Office in November 2025: most money matches, and the residue is where registration data is missing or incomplete. At PRS for Music, unidentified royalties are shared out in proportion to matched royalties, and on 29 June 2026 the Court of Appeal dismissed a collective challenge to that rule ([analysis](https://trackforge.studio/research/rowntree-v-prs); [judgment](https://caselaw.nationalarchives.gov.uk/ewca/civ/2026/814)). Litigation is not how this money comes back. Registration is how the loss is prevented. **How to detect it.** Take the catalogue schedule and, for every society where each work earns, check the society's own record. Is the work registered? Are the writers, publishers and shares those the contracts give? Does it carry the right ISWC (the international work code)? Is each recording, identified by its ISRC (the recording code), linked to the work? Free portals answer one work at a time; a catalogue needs the comparison in bulk. **What settles it.** The society's own record, dated, and its acknowledgement of a registration. **How it hits value.** It lowers the income base, and a statement cannot show it, because a statement records what matched, not what was earned. Unlike a discount-rate premium it is specific, findable and fixable, as set out in [Doubt in the rate, fact in the forecast](https://trackforge.studio/research/doubt-in-the-rate-fact-in-the-forecast). For recovery of what is already missing, see [how to find unpaid music royalties](https://trackforge.studio/research/find-unpaid-music-royalties). This is the risk the TrackForge Workspace is built for, described under the tools below. ### 5. Duplicate and conflicting registrations and counterclaims A duplicate is one work registered more than once, at one society or across several, so that income and statements split. A conflict, or overclaim, is more than one party claiming the same share, or claimed shares adding up to more than 100%. The two problems have the same effect: income in the affected share waits. The MLC provides an Overclaims Tool that finds works where the shares submitted by all members total more than 100% ([The MLC 2023 Annual Report](https://www.themlc.com/hubfs/2023%20MLC%20Annual%20Report.pdf)), and its 2025 Annual Report shows $27.5 million held in dispute for 2021 to 2025 usage as of March 2026. **How to detect it.** Search each work in the public registers (The MLC's Public Work Search shows each claimant and the total share claimed), compare shares across societies, read acknowledgements for conflict and possible-duplicate responses, and check that one work has one ISWC and that different works do not share one. **What settles it.** The underlying agreements decide who is right. The registration is then corrected with the society and the correction acknowledged. **How it hits value.** A conflicted share earns nothing until it is resolved. If the seller's chain is weaker than the counterclaimant's, the share is lost rather than delayed. ### 6. Sample and interpolation clearance A sample reuses part of an earlier recording. An interpolation re-performs part of an earlier song. Each needs a licence from the owner of what was taken: the master owner for the sampled recording, and the song owner for the underlying song or an interpolation. US courts differ on how little is too little. The Sixth Circuit held in [*Bridgeport Music v. Dimension Films*](https://law.resource.org/pub/us/case/reporter/F3/410/410.F3d.792.02-6521.03-5738.html) (2005) that sampling a sound recording needs a licence ("Get a license or do not sample"), while the Ninth Circuit held in [*VMG Salsoul v. Ciccone*](https://cdn.ca9.uscourts.gov/datastore/opinions/2016/06/02/13-57104.pdf) (2016) that a de minimis copy is not infringement. **How to detect it.** Read the credits and release metadata for sampled or interpolated material, check whether the original writers appear as shareholders in the registrations, ask for the clearance paperwork for every top earner, and listen to the rest. **What settles it.** A licence or split agreement that names the work and the share. **How it hits value.** An uncleared element can bring a claim for a share of the song, a withdrawn release or a damages claim. It is priced as a haircut on that work, with clearance as a condition, not spread across the catalogue. ### 7. Litigation and infringement exposure Litigation and infringement exposure covers claims that a catalogue song copies another work, and the owner's ability to enforce its own rights. Outcomes turn on the facts and on the court. A jury found that "Blurred Lines" infringed "Got to Give It Up", and the Ninth Circuit largely affirmed in [*Williams v. Gaye*](https://cdn.ca9.uscourts.gov/datastore/opinions/2018/03/21/15-56880.pdf) (2018). The same circuit, sitting en banc, found for Led Zeppelin in [*Skidmore v. Led Zeppelin*](https://cdn.ca9.uscourts.gov/datastore/opinions/2020/03/09/16-56057.pdf) (2020). The High Court of England and Wales found no copying of "Oh Why" in [*Sheeran v Chokri*](https://www.bailii.org/ew/cases/EWHC/Ch/2022/827.html) [2022] EWHC 827 (Ch). Time limits matter: in [*Warner Chappell Music v. Nealy*](https://www.law.cornell.edu/supremecourt/text/22-1078) (2024) the Supreme Court, assuming that the discovery rule applies, held that the Copyright Act's three-year limit on bringing suit does not itself cap damages, so a timely claim can reach further back. On enforcement, a work of US origin generally must be registered before its owner can sue ([*Fourth Estate v. Wall-Street.com*](https://www.law.cornell.edu/supremecourt/text/17-571), 2019), and statutory damages of $750 to $30,000 per work, up to $150,000 if wilful, depend on timely registration ([§504(c)](https://www.law.cornell.edu/uscode/text/17/504), [§412](https://www.law.cornell.edu/uscode/text/17/412)). **How to detect it.** Search court dockets for the owners and titles, and ask for every demand letter, settlement, and platform or society dispute. Check the US registration status of the top works. **What settles it.** Dockets, settlement agreements and written disclosure backed by warranties. **How it hits value.** The usual tools are an indemnity or escrow for known claims and a haircut on songs under claim. An unregistered US work is weaker as an asset because its owner may be unable to sue, or to claim statutory damages, when it needs to. ### 8. Counterparty and administrator risk Counterparty and administrator risk is the chance that the party holding the money, whether an administrator, sub-publisher, distributor or label, pays late, short or not at all. Income often passes through one or two intermediaries before it reaches the owner, and each statement the owner receives is that party's account of what it received. **How to detect it.** Reconcile the intermediary's statements, territory by territory, against the society statements and platform reports that feed them. Read the audit clause, its time limit and the right to appoint a replacement. Check who is the administrator of record at each society, and the intermediary's financial standing and payment history. **What settles it.** An audit or reconciliation, and contract protections such as direct-payment letters. **How it hits value.** Cash in transit is a credit exposure. A weak counterparty or a restrictive audit clause justifies a haircut, a direct-payment arrangement or a transition plan. None of this is a statement about any particular company. ## Will the income last, and what could cut it? Concentration, decay, rates and currency do not change who owns what. They change how much the income is worth and how wide the range of outcomes is. ### 9. Income concentration Income concentration risk is the share of a catalogue's income that depends on a few songs, artists, platforms, territories or payers. **How to detect it.** Rank works by trailing 12 and 36 months' income from line-level statements. Compute the share held by the top 1, top 10 and top 10% of works, then repeat by platform, territory and source of income (streaming, performance, sync). Stress-test by removing the top song, or the top platform, and re-running the forecast. **What settles it.** Line-level statements, which show work by period by source. Summary statements hide concentration. **How it hits value.** Concentration does not change average income, but it widens the range of outcomes, so lenders typically size an advance on the downside case rather than the average. It also multiplies the other risks: the title, reversion and sample questions on a catalogue's top few songs become questions about the whole catalogue. ### 10. Revenue decay and catalogue age Revenue decay is the pace at which a song's income falls as it ages, and catalogue age is the age mix of the income. New releases dominate headlines, but older music still carries most listening. Luminate's 2025 Year-End Music Report found that [43% of US on-demand audio streams](https://luminatedata.com/wp-content/uploads/2026/01/2025-Year-End-Music-Report-1.2026.pdf) (PDF page 17) were of tracks released in the five years 2021 to 2025, down from 49.6% for the previous five-year window in the 2024 report, so most streams were of older tracks. **How to detect it.** Cohort the income by release year of the work. Follow each top earner's income across at least three to five years. Compare the trend in audience with the trend in income: a fall in income with steady streams points to a collection problem rather than decay. **What settles it.** Statements together with audience data. The decay curve in a valuation is an assumption, not a finding. **How it hits value.** The decay and growth assumptions are among the inputs that set a discounted-cash-flow value, which is why two valuers can reach different prices for the same songs. ### 11. Rate and platform risk Rate and platform risk is the exposure of every pound of income to prices set outside the catalogue: regulated rates, tariffs, and the pricing and bundling decisions of streaming platforms. In the US, the Copyright Royalty Judges set mechanical rates for interactive streaming and downloads in five-year proceedings. The current Phonorecords IV rates phase the streaming headline rate up to 15.35% of US revenue by 2027. Phonorecords V, for 2028 to 2032, is under way. Parties filed written testimony and rate proposals on 5 October 2026, some songwriter groups backing a flat $0.0030 per interactive stream from 2028. A hearing is scheduled to begin on 22 March 2027 absent a settlement, and the Judges' initial determination is due by 17 December 2027 ([Music Business Worldwide, 7 October 2026](https://www.musicbusinessworldwide.com/phono-v-streaming-rate-proposals-filed-with-us-copyright-royalty-board-as-dima-points-to-30-growth-in-publishing-revenues-since-2022/)). A settlement filed on 29 June 2026 by the major record companies, independent labels and publisher and songwriter bodies would keep the physical and download rate structure through 2032 with inflation adjustments ([Music Business Worldwide, 13 July 2026](https://www.musicbusinessworldwide.com/us-copyright-royalty-board-proposes-extending-physical-and-download-mechanical-rates-through-2032/)). **How to detect it.** Split income by right and by rate regime, then run scenarios: what if the mechanical rate, or a major platform's payout per stream, moved by 10%? **What settles it.** Nothing settles a future rate. The answer is a stated range. **How it hits value.** It applies to every pound in that right, so it belongs in the scenario range or the discount rate, not in a deduction on one work. ### 12. FX and territory mix FX (foreign exchange) and territory risk is the exposure to exchange-rate movements and to differences in how well each territory's collection works. CISAC's Global Collections Report 2025 shows [€13.97 billion collected for creators in 2024](https://www.cisac.org/Newsroom/news-releases/cisac-global-collections-report-2025) by 228 societies in 111 countries: Europe €7.6 billion, North America €3.5 billion, Asia-Pacific €1.9 billion, Latin America and the Caribbean €786 million (down 0.6%) and Africa €90 million (up 14.2%), with digital 37% of the total. A catalogue that earns mostly in sterling and euros but is valued in dollars carries currency exposure in its valuation. One that earns in territories where its works are unregistered carries a collection gap. **How to detect it.** Split income by territory and currency from line-level statements. For each territory, check that the works are registered at the local society or through a sub-publisher, and note the lag between a society's payment and the money reaching the owner. **What settles it.** Statements and the registration check. **How it hits value.** Currency moves the reported value, whether or not it is hedged. Territory gaps are leakage, and leakage can be fixed. ## What did the review not cover? Every review has limits. The risk is not stating them. ### 13. Data and coverage risk Data and coverage risk is the risk that the review itself missed something: a sample instead of the full catalogue, a society not checked, recordings examined but not compositions, or three years of statements when the problem is older. It is the one risk every review carries and few review reports state. **How to detect it.** Write down, for each risk above, what was checked: how many works and what share of income by value, which societies and territories, which dates, and which source taken when. Write down what was not checked. **What settles it.** Only more checking, or pricing the unknown explicitly instead of ignoring it. **How it hits value.** A review that does not state its coverage cannot be compared with another review, or relied on by a lender. That is the reason TrackForge is building an evidence-based catalogue rating that states coverage for every component, described below. ## Which tools help assess music catalogue risk? Six kinds of tool, each good at some risks and blind to others. Tools for assessing music catalogue risk fall into six categories. Public registers and portals show what a society or office holds. Statement and income analysis shows what was paid. Audience and streaming data shows what was listened to. Valuation models and advisers price the risks. Legal title review settles who owns what. Registration-truth checking compares what each society holds with the catalogue. The matrix shows which category answers which risk: a filled dot means it is the main evidence, a half dot means it supports, and a dash means it does not help. **Which kind of tool answers which risk.** Columns: A public registers and portals; B statement and income analysis; C audience and streaming data; D valuation models and advisers; E legal title review; F registration-truth checking. ● main evidence, ◐ supports, – does not help. This is TrackForge's editorial assessment. | Risk | A | B | C | D | E | F | |---|---|---|---|---|---|---| | 1. Title | ◐ | – | – | – | ● | ◐ | | 2. Reversion | ◐ | – | – | ◐ | ● | ◐ | | 3. Expiring terms | ◐ | ◐ | – | ◐ | ● | ◐ | | 4. Leakage | ◐ | ◐ | ◐ | – | – | ● | | 5. Conflicts | ◐ | – | – | – | ● | ● | | 6. Samples | ◐ | – | – | – | ● | – | | 7. Litigation | – | – | – | – | ● | – | | 8. Counterparty | ◐ | ● | – | ◐ | ● | ◐ | | 9. Concentration | – | ● | ◐ | ◐ | – | – | | 10. Decay and age | – | ● | ● | ◐ | – | – | | 11. Rate and platform | – | ◐ | ◐ | ● | – | – | | 12. FX and territory | – | ● | ◐ | ◐ | – | ◐ | | 13. Coverage | – | – | – | ◐ | – | ◐ | ### Public society registers and portals These are free and primary, but they answer one work and one society at a time. Examples: The MLC's Public Work Search needs no login and shows each claimant, the total share claimed, the songwriters represented and the recordings matched, searchable by title, songwriter or publisher and filterable by ISWC, MLC song code and IPI (the interested-party number that identifies a writer or publisher) ([The MLC 2024 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202024%20Annual%20Report.pdf)). [Songview](https://songview.com/), developed by the US performing-right organisations ASCAP and BMI, presents public performance copyright information on more than 40 million works. CISAC's [ISWC Net](https://iswcnet.cisac.org/) is a public search of work metadata by ISWC, title or creator, and publisher details are not part of ISWC metadata. The [PRS for Music works database](https://www.prsformusic.com/works/searching-works) shows registered authors, publishers and UK copyright status, with access that differs for members, licensees and others. IFPI's [ISRC search](https://isrcsearch.ifpi.org/) and SoundExchange's [ISRC search](https://isrc.soundexchange.com/) look up recordings by ISRC. The US Copyright Office's [Public Records System](https://publicrecords.copyright.gov/) holds registrations and recorded documents. Open identifier indexes such as [MusicBrainz](https://musicbrainz.org/) and [Credits.fm](https://credits.fm/) add credits. A register shows what is claimed, not whether the claim is right. ### Statement and income analysis Line-level statements from societies, publishers, distributors and labels, analysed in spreadsheets, royalty-accounting software or by a royalty auditor, show what arrived: income by work, period, source and territory. This is the evidence for concentration, decay, currency mix and counterparty reconciliation. Statements show what matched, not what was earned, so they cannot reveal a work that was never registered. ### Audience and streaming data platforms These platforms report listening, not income. [Chartmetric](https://www.chartmetric.com/) describes a platform that combines streaming, social, playlist and chart data from more than 40 services. [Viberate](https://www.viberate.com/) describes analytics on artists, songs, playlists, audiences and radio airplay across services such as Spotify, TikTok and YouTube. Luminate publishes consumption data in its annual and midyear music reports. Use them to compare the trend in audience with the trend in income. A gap between the two points to a collection problem, but audience data cannot say which society owes the money. ### Valuation models and advisers A valuation turns forecast income and a discount rate into a price. Independent valuers commonly use discounted cash flow, and rating agencies publish analyses when a catalogue backs a bond. Chord Music Partners' April 2026 issue of $500 million of notes was backed by a catalogue an independent valuation agent put at about $830 million ([Apollo press release](https://www.apollo.com/insights-news/pressreleases/2026/04/chord-music-partners-prices-500-million-abs-backed-by-diversified-music-catalog); [KBRA](https://www.kbra.com/publications/TbQytYrq)), using an 8.00% discount rate ([Asset Securitization Report](https://asreport.americanbanker.com/news/music-royalty-revenue-supports-chord-musics-500-million-in-abs)). Two professional valuations of the Hipgnosis Songs Fund portfolio, as of September 2023 and March 2024, gave $2.62 billion at an 8.5% discount rate and a midpoint of $1.93 billion at 9.63% ([Music Business Worldwide, 4 March 2024](https://www.musicbusinessworldwide.com/hipgnosis-songs-funds-assets-are-now-valued-at-690-million-less-than-they-used-to-be-blackstone-will-be-licking-its-lips/)). The lesson is not which was right. A model prices the risks it is given. It does not find them. ### Legal title review Specialist music lawyers review the agreements, trace chain of title, analyse termination and reversion windows and check sample clearances, supported in the US by Copyright Office searches. This is the category that settles ownership, and nothing replaces it. It is also slow and expensive, so it is usually applied to a sample of the catalogue, and it often takes the society registrations as given unless it is asked to compare them with the contracts. ### Registration-truth checking and the TrackForge Workspace Registration-truth checking compares, work by work and society by society, what is registered with what the catalogue's contracts say should be. The TrackForge Workspace does this for registration and collection risk. You import the catalogue from a spreadsheet, a CWR (Common Works Registration) file or by hand, choose your societies, and each work shows its status at each one: prepared, sent or accepted. 1. **See what each society holds.** [Registration health](https://trackforge.studio/docs/workspace/registration-health) shows where each society is up to and what each society's own records hold, read from a work list you upload or, for some societies, from the society's records directly. Each work is marked held, not held or not checked, so the coverage is visible. 2. **See where it differs.** [Works registered differently](https://trackforge.studio/docs/workspace/files/registered-differently) lists works where a society's accepted registration differs from your catalogue, usually in the shares. You update the catalogue, keep it and record why, or prepare a revision for the society. 3. **Fix and send again.** The checks flag missing or inconsistent details. Writers, publishers and shares must total 100%, and recordings carry their ISRCs. A corrected file is sent from the Workspace through a saved society connection (for example PRS for Music and MCPS, the Mechanical-Copyright Protection Society, via ICE, and The MLC), or downloaded and sent by you. See [fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again). 4. **Read the response.** Upload the society's response, the acknowledgement or ACK, and the Workspace [reads it in plain words](https://trackforge.studio/docs/workspace/files/understand-a-response): accepted, needs correction, conflict, possible duplicate. On each work, a [US Copyright Office panel](https://trackforge.studio/docs/workspace/catalogue/additional-details) marks records worth a second look, such as a claimant who is not on your work or a recorded termination notice. Every send and response is kept in [registration history](https://trackforge.studio/docs/workspace/files/registration-history), and the Ask TrackForge assistant explains a response or a problem. [ISRC Lookup](https://trackforge.studio/isrc-lookup) and [Check my music](https://trackforge.studio/check-my-music) are free quick first checks. The Workspace does not review contracts, value a catalogue or analyse royalty statements, so it sits beside the other five categories rather than replacing them. A society's registration is a claim, not proof of title. Sign-up is free during the beta, with no card, using LinkedIn, Google or an email code. If you work with an AI assistant, TrackForge's [MCP server](https://trackforge.studio/mcp) lets it check a recording's registration and unclaimed MLC shares and validate a CWR file. **In development: one rating for these risks.** TrackForge is building an evidence-based catalogue rating: one standard, reproducible measure that brings these risks together, with the coverage stated for each component, what was checked and what was not. It is in development and is not available yet. The aim is that two reviews of the same catalogue can be compared, because each one says what it covered. ## What is a practical risk-review checklist for a buyer, lender or owner? Eleven checks in priority order. The first three come before any price is discussed. | Order | Check | What to do | Evidence that settles it | Risks | |---|---|---|---|---| | 1 | **State the scope and coverage first** | List the works, recordings, rights and territories. Decide what share of income, by value, each check must cover, and write down what is out of scope. | A written scope | 13 | | 2 | **Rank the income** | From 36 months of line-level statements, rank works, platforms, territories and payers. Compute the top-1, top-10 and top-10% shares and run the stress test. | Line-level statements | 9, 10, 12 | | 3 | **Test title on the works that earn most** | Trace each to signed agreements with every writer, producer and featured performer. Search recorded documents at the Copyright Office. | Agreements; recorded documents | 1 | | 4 | **Build the recapture schedule** | Record author, grant date, publication date, work-for-hire status, whether the author is alive, and the windows. Search recorded termination notices. Flag UK assignments made before 1 June 1957. | Grant documents; Copyright Office | 2 | | 5 | **Build the contract schedule** | List administration, sub-publishing and licence deals with end dates, post-term collection periods, change-of-control clauses and audit rights. | Signed agreements | 3, 8 | | 6 | **Check registration at every society where each work earns** | Is it registered? Do writers, publishers and shares match the contracts? Is the ISWC right and is each recording (ISRC) linked? What sits in unmatched or unclaimed pools? | Each society's own record; acknowledgements | 4 | | 7 | **Look for conflicts and duplicates** | Claimed shares above 100%, conflict and possible-duplicate responses, one work with several ISWCs or several works with one. | Registers; acknowledgements | 5 | | 8 | **Check clearance on the top earners** | Compare sample and interpolation credits with the registrations and the licences on file. | Licences and split agreements | 6 | | 9 | **Search for claims and disputes** | Court dockets, demand letters, platform and society disputes, written disclosure with warranties, and the US registration status of the top works. | Dockets; disclosure; warranties | 7 | | 10 | **Reconcile the intermediaries** | Compare administrator and distributor statements with society and platform data, territory by territory. Read the audit clause and its time limit. | Reconciliation or audit | 8 | | 11 | **Run rate, decay and currency scenarios, then state coverage** | Show a range, not a point. Write down what was checked, what was not, and price the unknowns instead of ignoring them. | Scenario model; coverage statement | 10, 11, 12, 13 | - **Buyer.** Use the findings to set the price, holdbacks, indemnities and conditions to completion. Price title and clearance gaps work by work; put scenario risks in the range. - **Lender.** Size the advance on checked income and the downside case. Ask for the coverage statement, direct-payment arrangements, and a covenant to keep registrations current. - **Owner.** Fix registrations and document title before a sale. A catalogue that can show its coverage and its fixes is easier to sell and to borrow against. Checks 1 to 5 are decided by documents. Checks 6 and 7, registration and conflicts, are the ones that need what each society actually holds, and they are the ones the [TrackForge Workspace](https://trackforge.studio/workspace) is built to run across a whole catalogue. For the full buy-side process, read [how to due-diligence a music catalogue before you buy](https://trackforge.studio/research/music-catalogue-due-diligence). To test ownership and metadata one work at a time, read [how to verify music rights ownership and metadata](https://trackforge.studio/research/verify-music-rights-ownership-metadata). To recover money that is already missing, read [how to find unpaid music royalties and claim them](https://trackforge.studio/research/find-unpaid-music-royalties). **What this guide is and is not.** This guide describes evidence and where to find it. It is not legal advice, and the legal points are summaries of the primary sources linked beside them, which should be read for the facts of a particular grant. A society register shows what is claimed. It does not prove who owns a work. **Start with the risk the statement cannot show.** Registration and collection leakage and conflicting claims are the risks that sit in the hidden, costly corner of the heat map, and they are the ones you can check across a whole catalogue today. The [TrackForge Workspace](https://trackforge.studio/workspace) is free during the beta, needs no card, and anyone can sign up with LinkedIn, Google or an email code. ## Frequently asked questions ### What are the main risks in a music publishing or catalogue investment? The main risks are title and chain of title, reversion and termination rights, expiring administration or sub-publishing terms, registration and collection leakage, duplicate or conflicting registrations, sample clearance, litigation, counterparty risk, income concentration, revenue decay, rate and platform changes, currency and territory mix, and gaps in the review itself. Some remove a work from the sale, some quietly cut collections, and some change the forecast. ### What tools are used to assess risk in music publishing and catalogue assets? Six kinds of tool are used: public society registers and portals, statement and income analysis, audience and streaming data platforms, valuation models and advisers, legal title review, and registration-truth checking that compares what each society holds with the catalogue. No single tool covers every risk. Registers and registration checks settle registration, statements show what was paid, lawyers settle title, and valuation models only price what the others find. ### Is a society registration proof that someone owns a song? No. A registration is a claim made to a society or an office, not proof of title. In the UK an assignment of copyright must be in writing and signed by the assignor, and there is no public register of copyright works, so title rests on the contracts. In the US, a recorded transfer gives public notice only for a registered work. Read registers and contracts together. ### Can an author take back the rights to a song after assigning them? Sometimes. In the US, section 203 of the Copyright Act lets an author terminate a grant made on or after 1 January 1978 in a five-year window beginning 35 years after the grant, with notice served 2 to 10 years ahead. Section 304 covers pre-1978 grants. In the UK, an assignment by an author made after the 1911 Act and before 1 June 1957 stops operating 25 years after the author's death. Existing recordings may keep the old terms. ### What is income concentration risk in a music catalogue and how is it measured? Income concentration risk is the share of a catalogue's income that depends on a few songs, artists, platforms, territories or payers. Measure it from line-level statements by ranking works on trailing 12 and 36 months' income, computing the top-1, top-10 and top-10% shares, repeating by platform and territory, and stress-testing by removing the top song or platform. Lenders typically size advances on the downside case. ### How do you find royalties a catalogue is not collecting? Compare the catalogue schedule with what each society holds, work by work: is the work registered, are the writers, publishers and shares correct, does it carry the right ISWC, and is each recording linked to it. Royalty statements cannot show this, because a statement records what matched, not what was earned. Public portals check one work at a time. The TrackForge Workspace does the comparison across a catalogue. ### Is there a standard risk rating for a music catalogue? Not yet. TrackForge is building an evidence-based catalogue rating that would bring these risks into one standard, reproducible measure, with the coverage stated for each component. It is in development and is not available. Today a catalogue review is a set of separate checks, which is why stating coverage matters. ## Sources **Statute and Copyright Office** - [17 U.S.C. §203, termination of transfers and licenses granted by the author](https://www.law.cornell.edu/uscode/text/17/203): Window of five years beginning 35 years after the grant (or earlier of 35 years from publication and 40 years from the grant), notice 2 to 10 years ahead and recorded before the effective date, cannot be waived, derivative works exception, effect limited to rights under the Act. - [17 U.S.C. §304, duration of copyright in pre-1978 works](https://www.law.cornell.edu/uscode/text/17/304): Section 304(c) five-year window from 56 years after the copyright was originally secured; section 304(d) window from 75 years; conditions of (c) apply. - [US Copyright Office, Notices of Termination](https://www.copyright.gov/recordation/termination.html): Where termination notices are recorded and searched. - [17 U.S.C. §205, recordation of transfers](https://www.law.cornell.edu/uscode/text/17/205): Constructive notice only for registered works; priority between conflicting transfers by recording. - [17 U.S.C. §504 and §412](https://www.law.cornell.edu/uscode/text/17/504): Statutory damages of $750 to $30,000 per work, up to $150,000 if wilful; §412 links statutory damages to timely registration. - [Copyright, Designs and Patents Act 1988, s.90 and Schedule 1 paragraph 27](https://www.legislation.gov.uk/ukpga/1988/48/schedule/1): Assignments must be written and signed; 25-years-from-death reversion for pre-1 June 1957 assignments by first-owner authors. - [GOV.UK, Copyright](https://www.gov.uk/copyright): There is not a register of copyright works in the UK. **Cases** - [Mills Music v. Snyder, 469 U.S. 153 (1985)](https://www.law.cornell.edu/supremecourt/text/469/153): Publisher kept its share of royalties from pre-termination derivative works. - [Vetter v. Resnik (5th Cir. January 2026), reported by Music Business Worldwide](https://www.musicbusinessworldwide.com/the-majors-and-bmg-asked-the-us-supreme-court-to-overturn-a-ruling-that-lets-songwriters-reclaim-copyrights-worldwide-five-things-to-know-about-vetter-v-resnik/): Fifth Circuit held a section 304(c) termination of a 1963 grant reverted worldwide rights; petition to the Supreme Court filed June 2026. - [Supreme Court order list, 19 October 2026 (No. 25-1391, BMG Rights Management v. Vetter)](https://www.supremecourt.gov/orders/courtorders/101926zor_q8l1.pdf): Judgment affirmed under 28 U.S.C. §2109 for want of a quorum, with the effect of affirmance by an equally divided court. - [Bridgeport Music v. Dimension Films, 410 F.3d 792 (6th Cir. 2005)](https://law.resource.org/pub/us/case/reporter/F3/410/410.F3d.792.02-6521.03-5738.html): Sampling a sound recording needs a licence: "Get a license or do not sample." - [VMG Salsoul v. Ciccone, 824 F.3d 871 (9th Cir. 2016)](https://cdn.ca9.uscourts.gov/datastore/opinions/2016/06/02/13-57104.pdf): De minimis exception applies to sound recording copying in the Ninth Circuit. - [Williams v. Gaye, 895 F.3d 1106 (9th Cir. 2018)](https://cdn.ca9.uscourts.gov/datastore/opinions/2018/03/21/15-56880.pdf): Ninth Circuit largely affirmed the infringement verdict over Blurred Lines. - [Skidmore v. Led Zeppelin, 952 F.3d 1051 (9th Cir. 2020) (en banc)](https://cdn.ca9.uscourts.gov/datastore/opinions/2020/03/09/16-56057.pdf): En banc judgment for the defendants. - [Sheeran v Chokri [2022] EWHC 827 (Ch)](https://www.bailii.org/ew/cases/EWHC/Ch/2022/827.html): High Court judgment on Shape of You and Oh Why. - [Warner Chappell Music v. Nealy, 601 U.S. 366 (2024)](https://www.law.cornell.edu/supremecourt/text/22-1078): Three-year limitation period does not cap damages for a timely claim. - [Fourth Estate Public Benefit Corp. v. Wall-Street.com, 586 U.S. 296 (2019)](https://www.law.cornell.edu/supremecourt/text/17-571): Registration must be made by the Copyright Office before an infringement suit. - [Rowntree v PRS, Court of Appeal, 29 June 2026 ([2026] EWCA Civ 814)](https://caselaw.nationalarchives.gov.uk/ewca/civ/2026/814): Collective claim over PRS's unidentified-royalty distribution rule dismissed. **Data and market sources** - [The MLC 2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf): $630.5 million unmatched and unclaimed and $27.5 million in dispute for 2021 to 2025 usage, as of the March 2026 distribution. - [The MLC, ex parte meeting summary, 20 November 2025 (Copyright Office)](https://www.copyright.gov/rulemaking/mma-designations/2024/MLC-Ex-Parte-Meeting-Summary-2025-11-20.pdf): Overall match rate across all usage periods 91.9%. - [The MLC 2023 and 2024 Annual Reports](https://www.themlc.com/hubfs/The%20MLC%202024%20Annual%20Report.pdf): Public Work Search, Overclaims Tool and other member tools as described by The MLC. - [Luminate, 2025 Year-End Music Report](https://luminatedata.com/wp-content/uploads/2026/01/2025-Year-End-Music-Report-1.2026.pdf): 43% of US on-demand audio streams from tracks released 2021 to 2025, against 49.6% for the preceding five-year window in 2024 (page 17). - [CISAC Global Collections Report 2025](https://www.cisac.org/Newsroom/news-releases/cisac-global-collections-report-2025): €13.97 billion collected in 2024; regional split; digital 37%. - [Music Business Worldwide, Phonorecords V streaming proposals, 7 October 2026](https://www.musicbusinessworldwide.com/phono-v-streaming-rate-proposals-filed-with-us-copyright-royalty-board-as-dima-points-to-30-growth-in-publishing-revenues-since-2022/): 5 October 2026 filings, $0.0030 flat-rate proposal, hearing from 22 March 2027, initial determination by 17 December 2027. - [Music Business Worldwide, Phonorecords V physical and download settlement, 13 July 2026](https://www.musicbusinessworldwide.com/us-copyright-royalty-board-proposes-extending-physical-and-download-mechanical-rates-through-2032/): Settlement filed 29 June 2026; Phonorecords IV streaming headline rate rising to 15.35% by 2027. - [Apollo press release, 27 April 2026; KBRA, 16 April 2026; Asset Securitization Report](https://www.apollo.com/insights-news/pressreleases/2026/04/chord-music-partners-prices-500-million-abs-backed-by-diversified-music-catalog): Chord Music Partners $500 million notes, about $830 million valuation, 8.00% discount rate. - [Music Business Worldwide, Hipgnosis Songs Fund valuations, 4 March 2024](https://www.musicbusinessworldwide.com/hipgnosis-songs-funds-assets-are-now-valued-at-690-million-less-than-they-used-to-be-blackstone-will-be-licking-its-lips/): $2.62 billion at 8.5% against a $1.93 billion midpoint at 9.63%. **Tools described** - [Songview](https://songview.com/): Developed by ASCAP and BMI; public performance copyright information on over 40 million works. - [CISAC ISWC Net](https://iswcnet.cisac.org/): Public search of ISWC work metadata; publisher information is not part of ISWC metadata (ISWC Net User Guide). - [PRS for Music, searching works](https://www.prsformusic.com/works/searching-works): Works database access and what it shows. - [Chartmetric](https://www.chartmetric.com/): Self-description: music data from more than 40 platforms. - [Viberate](https://www.viberate.com/): Self-description: analytics on artists, songs, playlists, audiences and radio airplay. **Disclosure.** TrackForge builds the Workspace described in this guide and is developing the catalogue rating. No TrackForge client or catalogue figure appears here; every number is from the published source named beside it. Third-party tools are described only as they describe themselves or as their own documentation shows. Heat-map and tool-matrix placements are TrackForge's editorial judgement, not measurements. --- *Source: [Music catalogue risk: what to check and which tools help](https://trackforge.studio/research/music-catalogue-risk-assessment)* ## research/find-unpaid-music-royalties.md # How to find unpaid music royalties and claim them > Find unpaid music royalties by checking each society's register against your catalogue, fixing registrations and claiming in time. Covers The MLC's 2027 clock. *Published by [TrackForge](https://trackforge.studio) — 2026-10-28* *Unpaid royalties usually sit with a collecting society or The MLC because a usage could not be matched to a registered owner. This guide shows where each income stream holds its unmatched money, how to check each register against your catalogue, and which clocks apply.* --- Unpaid music royalties usually sit with a collecting society or The MLC because a usage could not be matched to a registered owner. Finding them means checking each income stream's register against your catalogue, fixing the registration where it differs, and claiming within that body's window. Most windows are short, three years is common, and The MLC starts paying its unclaimed pool to other people's market shares from April 2027. The money is rarely missing. The streaming service, broadcaster or venue paid; the society is holding it because it could not tell whom to pay, or could pay only some of the owners. The industry calls these holdings *black box* royalties. They can be found, because the registers that explain them are largely public, and they can be claimed, because the cause is almost always a registration that is absent, incomplete or different from the catalogue. The [TrackForge Workspace](https://trackforge.studio/workspace) covers the registration half of this job. It is free during the beta, needs no card, and anyone can sign up with LinkedIn, Google or an email code. You load your works, see where each society stands on each one, find the works a society holds differently, fix them, and prepare and send corrected registration files. It prepares and records registrations; it does not log in to a society's claiming portal for you, so the claim steps below stay with you or your adviser. This guide gives the full method, including steps that no single tool does. A registration is a claim, not proof of title: nothing here settles who owns a song, and it is not legal advice. | Figure | What it is | |---|---| | $630.5m | unmatched and unclaimed US mechanical royalties held at The MLC for 2021–2025 usage, March 2026 | | 91.9% | The MLC's average match rate for 2021–2025 usage: the matching works, and a large residue remains | | 10 Feb 2027 | on or around: the database snapshot for The MLC's first market-share distribution | --- ## How do you find unpaid royalties and claim them? Six steps, in this order. Each is expanded in the sections that follow. 1. **List what you own and control.** One sheet: every work with title, ISWC, writers, IPI numbers and shares for each right; every recording with its ISRC; and who controls what, in which territory. Every register is tested against this sheet. 2. **Check each register for each right.** Search each society that should pay you, for performance, mechanical, neighbouring rights and abroad, and read the owners, shares and identifiers it holds. 3. **Sort what you find.** Four piles: not registered, registered differently, registered but unclaimed or unlinked, and held and claimable. Rank by value and by how soon the window closes. 4. **Fix the registration at source.** Correct IPI numbers, make each right total 100%, link ISRCs to works, add alternate titles. Then register or revise through each society's own route. 5. **Claim inside the window.** Use each body's claim route and keep your evidence. A claim on a registration that is still wrong reproduces the leak, so step 4 comes first. 6. **Read the answer and check again.** Read each society's acknowledgement, correct what was rejected or is in conflict, and look at the register again after the next processing cycle. --- ## Where does unpaid royalty money get stuck? Four stages sit between a play and a payment. Each has a leak, and each leak has a cause an owner can fix. Unpaid music royalties are royalties that a licensee has paid to a collecting society or collective, but which the body holds because it cannot pay all or part of them to an owner. The holdings come in three kinds. *Unmatched* money is a usage the body cannot tie to a work or recording. *Unclaimed* money is a usage tied to a known work where less than 100% of the shares has been claimed. *Undistributable* money has a known owner whose payment is blocked, for example by missing payee details. The MLC uses the first two terms in exactly this sense. **Where money gets stuck between a play and a payment** | Stage | What should happen | Where it leaks | |---|---|---| | 1. Usage | A service pays a pool and reports each play | Thin report: no ISRC or ISWC, artist or title variants, a cover under a new title | | 2. Match | The society links the play to a recording and work | Not linked: ISRC not tied to a work, no work record to match to, alternate titles not registered | | 3. Registration | Owners, shares and IPI numbers are on the register | Incomplete: work never registered here, shares total under 100%, wrong IPI, or one territory only | | 4. Distribution | The money is paid to a member with full payee details | Payee blocked: not a member of that society, below the payment threshold or details missing, registration left unfinished | Money caught at any leak is held as unmatched or unclaimed. When the society's window closes, it is shared out by market share to the registered. Leak 4 draws on The MLC's own list of reasons a matched, eligible royalty stays unpaid: the amount is below the payment threshold, the payee's details are wrong or incomplete, or the member has not finished registering (MLC 2025 Annual Report). Two of the four leaks sit upstream of anything an owner controls: the service's report and the society's matching. Two sit in the owner's own data and membership. That second pair is where recovery work usually starts, because it is the part a claimant can change. Leak 3 is typical: a work that exists at one society but is missing, part-claimed or filed under different details at another. [The Royalty Leakage Map](https://trackforge.studio/research/royalty-leakage-map) breaks the same pipeline into twelve lifecycle stages if you want the full taxonomy. --- ## How much unmatched and unclaimed money is there? Only The MLC publishes its held balance by usage year and by reason. It is the best public measure of what the pile looks like. The MLC's 2025 Annual Report shows **$630.5 million** of unmatched and unclaimed blanket royalties held for 2021 to 2025 usage as of the March 2026 distribution: $361.4 million unmatched and $269.1 million unclaimed, plus $27.5 million in dispute. About 43% of the $630.5 million (269.1 divided by 630.5) is unclaimed shares on works already in The MLC's database, which is the part an owner fixes by claiming. A further **$52.7 million** had been matched, found eligible and still not paid, for paperwork reasons. None of this means the system is failing. The MLC's average match rate across its first five years is 91.9%, and it reprocesses what is left every month. The residue is what matching alone does not clear. Other societies report their held balances differently, or not at all, so the figures below describe one right in one country, not a total for the system. For the full breakdown by year, see [$198 billion, 57%, and the number nobody models](https://trackforge.studio/research/music-in-the-air-number-nobody-models); for how unclaimed shares arise between performance and mechanical registration, see [The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy). **What The MLC held for 2021–2025 usage, as of March 2026 ($ millions)** | Category | Amount | |---|---| | Unmatched | $361.4m | | Unclaimed shares | $269.1m | | Matched, not paid | $52.7m | | In dispute | $27.5m | Source: [The MLC 2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf), appendix section F, as of the March 2026 distribution. The $52.7m is reported separately from the held balances and is not part of the $630.5m. --- ## Which income streams can hold unpaid royalties? Songwriters and publishers have up to seven places to check. Recording owners and performers have two. A song earns through two separate copyrights, and each pays through different bodies. The *composition* (words and music) earns performance royalties when it is played or streamed, and mechanical royalties when it is reproduced. The *sound recording* earns neighbouring-rights royalties when it is broadcast or publicly performed. Joining a society for one right does not register you for another, and a registration in one territory does not reach another. That is why the same work can be paid in full in one stream and held in the next. Check every row that applies to you. | Income stream | Who collects | What identifies you | Where unmatched or unclaimed money sits | |---|---|---|---| | **Performance, UK** (writers, publishers) | PRS for Music | IPI number, work registration with agreed shares, tunecode or ISWC | Unidentified works that PRS lists for members to claim; the potential publisher share of an unregistered work | | **Performance, US** (writers, publishers) | ASCAP, BMI, SESAC and GMR, each for its own members | Membership of the society that holds your share, IPI, ISWC | Held under each society's own rules. Shares that ASCAP and BMI do not hold show as "Other" in Songview | | **Mechanical, UK** (writers, publishers) | MCPS, administered with PRS for Music | MCPS membership, work registered with your share | Mechanical income MCPS cannot allocate to a registered owner, including physical-product income claimed back later | | **Mechanical, US digital** (streaming, downloads) | The MLC | MLC membership, work registered with shares totalling 100%, recording matched by ISRC | Unmatched recordings and unclaimed shares, searchable by members | | **Mechanical, US physical** (CDs, vinyl) | Not The MLC. Licences by notice, or an agent such as HFA | Agent membership or a direct licence with the label | With the agent or label, not in a central pool. The MLC's mandate is digital only | | **Abroad** (writers, publishers) | Local societies, paid through a sub-publisher, your home society's reciprocal agreement, or direct membership | The same work registered and linked in each local society, with ISWC and IPI | In the local society, until the work is registered or linked there. Each hop is another registration to check | | **YouTube** (compositions) | YouTube, through publishers and administrators with Content ID access, plus societies for performance | Composition data the publisher supplies to YouTube | Videos using your song where nobody has supplied the composition data | | **Neighbouring rights, UK** (record owners, performers) | PPL | ISRC in the PPL repertoire; performer on the line-up | Recordings missing from the repertoire; performers missing from the line-up | | **Digital performance, US** (record owners, featured artists) | SoundExchange | SoundExchange registration as artist or sound recording copyright owner; ISRC | Held for unregistered artists and owners, then expires after three years | Sources: [The MLC tools](https://www.themlc.com/tools); [Songview launch, Music Connection, 21 December 2020](https://www.musicconnection.com/ascap-and-bmi-launch-songview-resource/); [SoundExchange FAQ](https://www.soundexchange.com/frequently-asked-questions/); [PPL performers](https://www.ppluk.com/royalties/uk-royalties/performers/); [YouTube, 17 August 2011](https://blog.youtube/news-and-events/creating-new-opportunities-for/). Societies publish different levels of detail on what they hold, so a blank cell means unpublished, not empty. The table also shows a common surprise: a writer who is a member of ASCAP or BMI may be paid performance royalties in full while the mechanical share at The MLC has never been registered. Recording owners face a mirror image. A recording can earn in the UK through PPL and sit unregistered with SoundExchange in the US. For a sub-publisher or a direct membership abroad, the practical test is the same as at home: does the work exist in that society's register, with your share, linked to the recording? --- ## Why does royalty money go unmatched or unclaimed? Eight causes account for most unpaid royalties. Each leaves a recognisable trace and has a specific fix. A society pays what it can identify, so an unpaid royalty is a data fault with a price on it. The faults are not random. The same eight show up across societies and catalogues, and most can be spotted by comparing your own sheet with the register. The identifier fixes in the table, IPI, ISWC and ISRC, are covered step by step in [How to verify music rights ownership and metadata](https://trackforge.studio/research/verify-music-rights-ownership-metadata). | Cause | How it shows up | The fix | |---|---|---| | **Work never registered** | Usage cannot match to any owner; the money is held as unmatched or unpaid | Register the work at each society, for each right you hold | | **Not a member of the society at all** | Nobody can be paid for your share. Membership start dates also limit how far back a claim reaches | Join directly, or appoint a publisher, administrator or sub-publisher who is a member. Check the start date first | | **Missing or wrong IPI number** | The share is attributed to nobody, or to a different person with a similar name | Confirm each writer's and publisher's IPI with their own society; correct it on every registration | | **Shares not totalling 100%** | A part-claimed work. The remainder is "unclaimed". Over 100% creates an overclaim that blocks payment | Make each right total exactly 100%; agree the split with co-owners | | **ISRC not linked to ISWC or work** | A registered work, an active recording, and no link between them: the recording stays unmatched | Add the ISRC to the work registration; propose the match at The MLC; use the ISWC | | **Title variants** | "Song (feat. X)", "Song - Radio Edit" or a translated title fails to match the registered title | Register alternate titles; match on identifiers, not names | | **Registered in one territory, not another** | Paid in the UK, held in the US; or covered by one sub-publisher but not the one that collects in that country | Map who controls each territory and register in each society; check the agreements | | **A co-owner's share never claimed** | Your registered share is paid; the other owner's share sits unclaimed and shows as a partial work | Claim your part; The MLC lets identified owners notify unidentified ones of their unclaimed shares | Sources: The MLC [Policy for the Distribution of Unclaimed Accrued Royalties](https://www.themlc.com/hubfs/UAR%20Distribution%20Policy%20(September%202026).pdf), September 2026, §4.1(ii)(C), for the notification tool; [PRS for Music help centre](https://help.prsformusic.com/s/article/will-i-get-paid-for-uses-of-my-music-before-my-join-date) for membership start dates. --- ## Which public tools show what is registered and what is held? Every major body publishes something you can search. Some tools are open to anyone; the claiming tools need membership or registration. Step 2 of the method is a search society by society. The tools below exist and do what the table says, checked against each body's own pages on 28 October 2026 where the page could be read. Some society pages load only for a signed-in browser, so check the current wording before relying on a detail. A tool that shows what a society holds tells you what is registered; it does not tell you who owns the song. | Tool | Who can use it | What it does | |---|---|---| | **The MLC Public Work Search** ([portal.themlc.com/search](https://portal.themlc.com/search)) | Anyone, free, no login | Shows ownership information, including shares and matched recordings, for the songs in The MLC's database | | **The MLC Claiming Tool** | Members ([free to join](https://www.themlc.com/membership)) | Finds partially claimed songs and lets you claim the missing shares | | **The MLC Matching Tool** | Members and songwriters | Lists unmatched sound recordings. You propose matches to your registered songs; if approved, the royalties accrued for those uses are paid to you, with future uses | | **The MLC Top Unmatched Sound Recording Uses list** | Members | The month's 3,000 highest-value unmatched recordings, as described in The MLC's [2024 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202024%20Annual%20Report.pdf) | | **SoundExchange "Are you owed royalties?" search** ([Artists, Labels & Producers page](https://www.soundexchange.com/what-we-do/for-artists-labels-and-producers/)) | Anyone not yet registered | Lets unregistered artists, partially unregistered artists, unregistered performers and unregistered sound recording owners check whether they are owed royalties | | **SoundExchange Search & Claim** ([how it works](https://www.soundexchange.com/2021/02/09/my-catalog-update-search-claim-rights-owner/)) | Registered artists and rights owners, in SoundExchange Direct | Searches the repertoire and unmatched broadcast usage; you claim recordings with a percentage and dates, and match unmatched items to repertoire you own | | **PPL Repertoire Search** ([repsearch.ppluk.com](https://repsearch.ppluk.com/ars/faces/pages/audioSearch.jspx)) | Open to the public, free; aimed at licensees | Finds a recording by artist, title or ISRC and shows its line-up. Results are capped and are not a full picture of PPL's repertoire | | **PPL Performer Claims** ([guide](https://www.ppluk.com/wp-content/uploads/2025/10/PPL-Perfomer-Claims-Guide.pdf)) | Performers, in myPPL | Search the repertoire, check the line-up, put a recording in the Claims Basket and submit the claim. Performers cannot add recordings; the rightsholder does | | **PRS for Music "Check unpaid royalties"** ([prsformusic.com](https://www.prsformusic.com/royalties/claim-unpaid-royalties)) | Members claim; the lists are viewable | Lists unidentified works with their value bands that a member can claim. Back claims have their own [page](https://www.prsformusic.com/royalties/your-statement/back-claims) | | **ASCAP and BMI Songview** ([ascap.com/songview](https://www.ascap.com/songview), [bmi.com/songview](https://www.bmi.com/songview)) | Anyone, free | Shows the share split between ASCAP, BMI and "Other" for the songs in both repertoires, with writers, publishers, ISWC and IPI codes | | **SESAC and GMR catalogue searches** | Anyone | Each publishes its own search: [SESAC](https://www.sesac.com/repertory/) and [GMR](https://globalmusicrights.com/search). Use them to see which share each holds | [Check my music](https://trackforge.studio/check-my-music) is a quick, free first look at the US mechanical stream: paste ISRCs and it shows, recording by recording, whether The MLC links each one to a registered song and whether any share is unclaimed. It reads The MLC's public data only and registers nothing. For a catalogue across several societies and rights, the Workspace is the recommendation, because the answer you need is a comparison, not a single lookup. If you work through an AI assistant, TrackForge's free [MCP server](https://trackforge.studio/mcp) lets it run the same MLC check by ISRC. --- ## How long do you have to claim unpaid royalties? Each body runs its own clock. The shortest are measured from the date of a distribution, not from the date of the stream. There is no single deadline for claiming unpaid music royalties. Each society's rules set one, and the starting point differs: the distribution date, the release date, the first payment or the end of a financial year. The table gives the windows that can be sourced to a body's own rules. A late claim is not always lost, and an early one is never worse, so treat the dates as the latest sensible time to act, and check the current rules for your case before relying on one. | Body | The window | Source | |---|---|---| | **The MLC** | A claim can be made at any time, but a completed market-share distribution of unclaimed royalties is final. First distribution April 2027, snapshot on or around 10 February 2027 | [The MLC market share page](https://www.themlc.com/marketshare) | | **PRS for Music** | Distributions are final unless a valid claim is made within three years of the distribution date. No adjustment for a backdated contract | PRS Distribution Policy, Rule 2(i)(i); [help centre](https://help.prsformusic.com/s/article/how-far-back-can-i-claim-for-music-used) | | **MCPS, physical products** | Back claims are limited to six years from the product's release date, and cannot reach before your membership start date | [PRS and MCPS help centre](https://help.prsformusic.com/s/article/how-far-back-can-i-claim-for-music-used) | | **SoundExchange** | Royalties expire after three years; the regulation sets three years from the first distribution of the relevant payment | [SoundExchange FAQ](https://www.soundexchange.com/frequently-asked-questions/); 37 CFR 380.4(b) | | **PPL, performer claims** | 50 days to finish a claim once started; evidence due within 45 days of PPL's request | [PPL Performer Claims Guide](https://www.ppluk.com/wp-content/uploads/2025/10/PPL-Perfomer-Claims-Guide.pdf) | | **EU societies** | Amounts not distributed within three years of the end of the financial year of collection can be treated as non-distributable; rightholders' claims remain subject to national limitation periods | [Directive 2014/26/EU, Article 13](https://eur-lex.europa.eu/eli/dir/2014/26/oj) | **The MLC: the clock set by rule.** The Music Modernization Act requires The MLC to hold unclaimed royalties for at least three years and then distribute them to copyright owners by relative market share. On 30 September 2026 The MLC announced it intends to begin in **April 2027**, with the remaining January 2021 usage, then one usage month in each monthly distribution. The April 2027 distribution uses the database snapshot taken on or around **10 February 2027**, and registrations, claims and matches count only if they are processed before it. The MLC says claims are typically processed in 21 days or less, but not guaranteed, so we suggest submitting by early January 2027. A completed distribution is final; a share claimed afterwards is paid for later periods only. The unclaimed money does not vanish: it is paid to whoever was registered and claimed on the day of the snapshot. For a buyer or lender, an unclaimed balance has a date after which it becomes someone else's income, which is why it belongs in [catalogue due diligence](https://trackforge.studio/research/music-catalogue-due-diligence) and in a [catalogue risk assessment](https://trackforge.studio/research/music-catalogue-risk-assessment). For an owner, the same fact makes the first step the cheapest one: check The MLC before February. --- ## Should you use a royalty recovery service? You can do all of this yourself, and some owners prefer not to. If you hire help, six questions separate a clear offer from a vague one. A royalty recovery service is a firm, adviser or software product that audits your registrations and claims unpaid money for a fee, usually a share of what it recovers. They differ widely: some are software that checks registers, some are people who file claims, some are both. None of that is a reason to avoid them; it is a reason to ask what you are buying. These questions work for any provider, including TrackForge. | Ask | Why it matters | A clear answer | |---|---|---| | **How are you paid?** | A percentage of "recovered" money can include income you would have received anyway | The fee base is defined: which money counts, for how long, and what happens after the contract ends | | **What exactly do you check?** | Checking statements finds only what was paid; checking registers finds what was not | A list of societies, rights and territories, compared against the registers work by work, with the evidence per work | | **Who files each claim, and in whose name?** | A mandate or administration agreement can change who is paid and who can see the data | Which claims you file, which they file, what authority they need, and how to withdraw it | | **What do I keep afterwards?** | Corrected data is worth more than a single recovery | You receive the corrected registrations, the evidence and the status by society, in a form you can reuse | | **What do you need from me?** | No provider can create title. Societies ask for contracts and splits | A short list of ownership documents, with the reason for each | | **How will I see results?** | Money can arrive months after a claim | Reports by society and work: filed, accepted, rejected, paid, with society responses attached | --- ## Where does the TrackForge Workspace fit? It is the one place that holds your catalogue, shows each society's position, and prepares the corrected registrations. The [TrackForge Workspace](https://trackforge.studio/workspace) is where steps 1 to 4 and step 6 happen in one system, and it prepares the registration that most claims depend on. It is free during the beta, with no card, and anyone can sign up. Step by step: **Step 1.** [Load your works](https://trackforge.studio/docs/workspace/add-works/) from a spreadsheet, a CWR file or by hand, with writers, publishers and recordings with ISRCs. **Steps 2 and 3.** [Registration health](https://trackforge.studio/docs/workspace/registration-health) shows where each society is up to with your catalogue and what each society's own records hold, where a reading is available. [Works registered differently](https://trackforge.studio/docs/workspace/files/registered-differently) lists what a society holds that differs from your catalogue, with three ways to settle each difference. The differences it lists are your starting list for step 4. **Step 4.** The checks flag problems on each work, such as [shares that do not total 100%](https://trackforge.studio/docs/workspace/catalogue/shares) or a missing IPI. You fix them, then prepare a CWR file for the society and [send it](https://trackforge.studio/docs/workspace/files/send) through a saved [society connection](https://trackforge.studio/docs/workspace/settings/society-connections) (for PRS for Music and MCPS via ICE, The MLC, and the SFTP logins some societies issue), or download it and send it yourself. **Step 6.** [Upload the society's response](https://trackforge.studio/docs/workspace/files/upload-a-response) and [read it in plain words](https://trackforge.studio/docs/workspace/files/understand-a-response): accepted, needs correction, conflict, possible duplicate. What the Workspace does not do today is search The MLC's unmatched list, file claims in a society's portal, or tell you who owns a song. Those are steps 2 and 5, which this guide shows how to do with the society's own tools. TrackForge is also building an evidence-based catalogue rating, in development and not yet available, towards a common standard for how a catalogue's registrations are evidenced. > A royalty statement is a record of what matched, not of what was earned. The cheapest unpaid royalty to recover is the one whose cause you can fix before a deadline. --- ## Sources **The MLC:** [2025 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202025%20Annual%20Report.pdf), appendix section F, figures as of the March 2026 distribution: royalties held by category for 2021–2025 usage (unmatched $361.4m, unclaimed $269.1m, in dispute $27.5m; total unmatched and unclaimed $630.5m); $52,690,895.03 matched, eligible and undistributable; average match rate 91.9%. The 43% share is TrackForge's arithmetic on those figures. Market share: [Market Share](https://www.themlc.com/marketshare) page (distributions intended to begin April 2027; snapshot on or around 10 February 2027; claims typically processed in 21 days or less, not guaranteed) and the [Policy for the Distribution of Unclaimed Accrued Royalties](https://www.themlc.com/hubfs/UAR%20Distribution%20Policy%20(September%202026).pdf) (September 2026: claims count only if processed before the snapshot, §6.4; finality, §6.5; notification tool, §4.1(ii)(C)). Tools: [The MLC tools](https://www.themlc.com/tools), [membership](https://www.themlc.com/membership), and the [2024 Annual Report](https://www.themlc.com/hubfs/The%20MLC%202024%20Annual%20Report.pdf) for the Top Unmatched list. **SoundExchange and PPL:** [SoundExchange FAQ](https://www.soundexchange.com/frequently-asked-questions/) (royalties expire after three years); 37 CFR §380.4(b) and §382.5(b) (unclaimed funds held three years from the first distribution of the relevant payment); [Artists, Labels & Producers](https://www.soundexchange.com/what-we-do/for-artists-labels-and-producers/); [Search & Claim for rights owners](https://www.soundexchange.com/2021/02/09/my-catalog-update-search-claim-rights-owner/). PPL: [Performer Claims Guide](https://www.ppluk.com/wp-content/uploads/2025/10/PPL-Perfomer-Claims-Guide.pdf) (50-day claim window, 45-day evidence window) and the [Repertoire Search](https://repsearch.ppluk.com/ars/faces/pages/audioSearch.jspx). **PRS for Music and MCPS:** PRS Distribution Policy Guide, Adjustments (Rule 2(i)(i): distributions final and binding save for valid claims made within three years of the date of the distribution; no adjustment for backdated contracts); PRS and MCPS help centre, [How far back can I claim for music used?](https://help.prsformusic.com/s/article/how-far-back-can-i-claim-for-music-used) (physical-product back claims limited to six years from release; membership effective start date 1 January or 1 July); [Check unpaid royalties](https://www.prsformusic.com/royalties/claim-unpaid-royalties) and [Back claims](https://www.prsformusic.com/royalties/your-statement/back-claims). These pages load only in a browser; the quoted rules are as held in TrackForge's knowledge base from the society's published documents, read 28 October 2026. **Other:** [ASCAP and BMI Launch Songview Resource](https://www.musicconnection.com/ascap-and-bmi-launch-songview-resource/), Music Connection, 21 December 2020 (free; ownership splits by ASCAP, BMI and Other; ISWC and IPI codes). [YouTube Official Blog](https://blog.youtube/news-and-events/creating-new-opportunities-for/), 17 August 2011 (Content ID identifies compositions using information publishers provide). [Directive 2014/26/EU](https://eur-lex.europa.eu/eli/dir/2014/26/oj), Article 13. The Copyright Office's July 2021 *Unclaimed Royalties* report notes that GMR publishes a catalogue search. Physical mechanicals sit outside The MLC, whose mandate is digital only (17 U.S.C. §115(d)). **Disclosure:** TrackForge checks whether works are registered, matched and claimed at collecting societies, and makes the free Workspace for fixing registrations. No TrackForge client or catalogue figure appears in this article; every number is from the published source named beside it. Societies change their rules and pages, so check the current wording for your case. --- *Source: [How to find unpaid music royalties and claim them](https://trackforge.studio/research/find-unpaid-music-royalties)* --- # Workspace Manual --- ## docs/workspace.md # What the Workspace is > See what the TrackForge Workspace holds, that today you send each file to the society yourself, and who can change things and who can only look. The TrackForge Workspace is where you keep your catalogue of works, see where each work stands with the [societies](https://trackforge.studio/docs/cwr/glossary#society) you register with, and prepare the [CWR](https://trackforge.studio/docs/cwr/glossary#cwr) files that register them. It prepares files and keeps a record of what you do with them. Today you send each file to the society yourself. Sending it for you is [coming shortly for premium subscribers](#coming-shortly-for-premium-subscribers). ## What it holds - **Catalogues of works.** Your saved works, in one catalogue or several. You can save a work before it is complete and finish it later. - **A status for each society.** Each work shows where it stands with each society you have chosen. [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) explains them. - **Prepared files.** The registration files you build from your works, ready to download. - **Society responses.** The replies you upload, and what each society said about each work. ![The Catalogue list with a status for each society beside every work, such as Details missing, Ready, Needs correction, Accepted and Registration differs from catalogue.](https://trackforge.studio/docs/img/workspace/catalogue-list.png) ## What it does not do TrackForge sends a file to a society only when you ask it to. To register works you do four things: 1. Prepare a file in the Workspace. 2. Send the file to the society. For PRS for Music, MCPS and The MLC, you can send it from the Workspace through a [society connection](https://trackforge.studio/docs/workspace/settings/society-connections). For other societies, download it and send it by that society's own route. Each society can take a different route: see [Different routes for different societies](https://trackforge.studio/docs/workspace/files/send#different-routes-for-different-societies). 3. Come back and record that you sent it. 4. When the society replies, upload its response. The Workspace then shows what the society said about each work. If a society rejects a work, there is no button to send the file again. You fix the work, save it, prepare it in a new file, send that file and record the send again. [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again) walks through it. ### Coming shortly for premium subscribers TrackForge will be able to send a prepared file to the society for you and collect the society's response, as a premium service. It is not open yet. It will not be all or nothing: TrackForge can send to the societies it connects to while you go on sending to the others yourself, by email or their portal. This manual will cover it when it is. Until then, every page here describes sending the file yourself. ## Who can change things What you can do depends on your role in the workspace. - **Owners and editors** can change things: add and edit works, choose societies, prepare files, record sends and upload responses. - **Everyone else is view-only.** You can look at saved works, prepared files and response history, but you cannot change anything. If you are view-only, a notice at the top of the Workspace says so, and the buttons that change things are left out. On **Today**, the next-step panel reads **Your catalogue at a glance** instead of telling you what to do. If you need to make changes, ask the workspace's owner. ## From your catalogue to an accepted work The steps from your catalogue to a work a society has accepted, in three stages. Two steps happen outside TrackForge: you send the file yourself, and the society replies to you. **Get ready** 1. [Add your works](https://trackforge.studio/docs/workspace/add-works/) 2. [Choose your societies](https://trackforge.studio/docs/workspace/settings/societies) 3. [Add your publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) 4. [Fix what is missing](https://trackforge.studio/docs/workspace/catalogue/fix-problems) **Prepare and send** 5. [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare) 6. [Download the file](https://trackforge.studio/docs/workspace/files/send) 7. Send it to the society *(outside TrackForge)* 8. [Record that you sent it](https://trackforge.studio/docs/workspace/files/send) **The society's answer** 9. The society replies to you *(outside TrackForge)* 10. [Upload the response](https://trackforge.studio/docs/workspace/files/upload-a-response) 11. [Read what the society said](https://trackforge.studio/docs/workspace/files/understand-a-response) A work the society accepted is done. For a work it did not accept, [fix the work and save it](https://trackforge.studio/docs/workspace/files/fix-and-send-again), then go back to step 5 and prepare it in a new file. ## Where to go next - [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here): follow the **Get set up** card from an empty workspace to a prepared file. [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way) shows where everything is. - [Signing up](https://trackforge.studio/docs/workspace/signing-up) and [Signing in](https://trackforge.studio/docs/workspace/signing-in): create your workspace, and get back into it. - [What Today shows](https://trackforge.studio/docs/workspace/today/): the screen you land on, and what needs you next. - [Ways to add works](https://trackforge.studio/docs/workspace/add-works/): by hand, from a spreadsheet or from a CWR file. - [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find): search your saved works and narrow the list. - [Agreements](https://trackforge.studio/docs/workspace/agreements): record the facts from an agreement and link the works it covers. - [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare): build a file for a society. - [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details): your publisher name and IPI number, needed before you prepare a file. - [Getting help](https://trackforge.studio/docs/workspace/help/): help links, field tips and how to contact support. --- *Source: [https://trackforge.studio/docs/workspace/](https://trackforge.studio/docs/workspace/)* --- ## docs/workspace/start-here.md # Your first file in six steps > Follow the six steps on the Get set up card, from adding your works to seeing what the societies hold and preparing your first file. The **Get set up** card at the top of **Today** lists six steps from an empty workspace to your first prepared file. It marks the step to do now and counts the ones that are done. Work down the card in order. Each step below links to the page that covers it in full. ## Before you start Only owners and editors see the buttons on the card. If you can only look, the card shows your progress without buttons. [What the Workspace is](https://trackforge.studio/docs/workspace/) explains the difference. ![The Get set up card on Today in a new workspace, with step 1, Add your works, marked Now and the five other steps still to come.](https://trackforge.studio/docs/img/workspace/get-set-up.png) ## The six steps 1. **Add your works**. Press **Add a work** to add one by hand, or choose **Import a file (CSV, TSV, Excel or CWR)**. A work does not have to be complete to be saved. Once you have saved some, the step shows how many. See [Ways to add works](https://trackforge.studio/docs/workspace/add-works/). 2. **Choose your societies**. Press **Choose societies**, which opens **Workspace settings**. Your works are saved without this, but they are checked only for the [societies](https://trackforge.studio/docs/cwr/glossary#society) you choose. See [Societies](https://trackforge.studio/docs/workspace/settings/societies). 3. **Add your publisher details**. Press **Add details**, which also opens **Workspace settings**. You need your publisher name and [IPI](https://trackforge.studio/docs/cwr/glossary#ipi) number before you can prepare a file. See [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details). 4. **Fix what is missing**. Press **Fix works** to open the works that need information. See [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). 5. **See what the societies hold**. Press **See what they hold**, which opens **Registration health**. Bring in the files you sent before and the societies' replies, so you send only what is new. The step counts as done once a file or reply is brought in, a society's records give a reading, or a file is prepared. See [Registration health](https://trackforge.studio/docs/workspace/registration-health). 6. **Prepare and send a file**. Press **Choose works**, which opens **Catalogue**. Choose the works for the file and prepare it. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). ## What you will see - A progress bar labelled **Setup progress** counts the steps done, for example 2 of 6 done. - Each step has a badge: **Done**, **Now** for the step to do next, or **Step** and its number for steps still to come. - Only the step marked **Now** has a button. - If you are an owner or editor, the card's button is the one main button on Today until steps 1 to 3 are done, and the **Your next step** panel is hidden. After that, the panel comes back and the card's button is quieter. - Step 4 reads "Nothing missing" when no work needs information. It counts as done only once you have chosen societies, because works are not checked until then. - When all six steps are done, the card disappears. ## Preparing a file is not the last step The card counts step 6 as done as soon as a file is prepared. TrackForge sends nothing itself. You download the file, send it to the society yourself and record that you sent it. Until you do, Today lists the file under **Files in progress**. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send) and [Upload a response](https://trackforge.studio/docs/workspace/files/upload-a-response). ## If something goes wrong - **A step has no button.** You are view-only, or it is not the step marked **Now**. Only the current step has a button. - **Step 4 is not marked done though nothing seems missing.** Check step 2. Works are checked only for the societies you choose. - **The card has gone.** All six steps are done. Use [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you) to see what is left to do. ## Related - [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way) - [What Today shows](https://trackforge.studio/docs/workspace/today/) - [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) --- *Source: [https://trackforge.studio/docs/workspace/start-here](https://trackforge.studio/docs/workspace/start-here)* --- ## docs/workspace/signing-up.md # Signing up > Read the beta offer, enter your name, your business and first catalogue name, and create your TrackForge Workspace. There is no separate sign-up form. You sign in, and the first time you do, the Workspace asks for your name, a business name and a catalogue name, and creates your workspace. ## Before you start Decide which email address your workspace will be under, and use it every time. A workspace is found by email address, so a Google or LinkedIn account under a different address will not open it. ## Steps 1. Go to `trackforge.studio/workspace` and sign in with LinkedIn, Google or a code sent to your email. [Signing in](https://trackforge.studio/docs/workspace/signing-in) covers that page. 2. The screen **Set up your TrackForge Workspace** opens. Under the heading, **Signed in as** shows the address your workspace will be under. If it is not the one you want, press **Sign out** and sign in again with the right one. 3. Read the offer in the panel **Free during the beta**. The next section quotes it. 4. Type your **First name** and **Last name**. The account button in the top bar shows your initials and first name. 5. Type your **Business or publisher name**. It is shown as your workspace name. You can use your own name if you publish yourself. 6. Check the **First catalogue name**. It starts as **Main catalogue** and you can change it. You can add more catalogues later. 7. Tick **I've read the beta offer above and want to join on those terms.** 8. Press **Create my workspace**. The button stays switched off until all four boxes are filled in and the offer is ticked. ## What the beta offer says These are the panel's own words, which the tick box asks you to accept: - It names the number of works you can keep, and says you can **check them, track each society's status and prepare files you send yourself**. - **No card needed.** - **Before paid plans start we'll give you at least 60 days' notice, and you'll never be charged unless you choose a plan.** - **Your data stays yours: you can download it at any time. We only delete it if you close your account, or after an emailed warning if the workspace has gone unused for 11 months.** [Your data](https://trackforge.studio/docs/workspace/help/your-data) says how to download it. [Close your account](https://trackforge.studio/docs/workspace/settings/close-your-account) covers closing. ## What you will see The button reads **Creating your workspace…** for a moment. The Workspace then opens on **Today** with your first catalogue, which is empty. The **Get set up** card lists what to do next, and [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here) follows it. You can change your own name later on the Account page, and the workspace's owner can change its name in **Workspace settings**. See [Your account](https://trackforge.studio/docs/workspace/account) and [Change the workspace's name](https://trackforge.studio/docs/workspace/settings/workspace-name). ## If something goes wrong - **The screen says **New sign-ups are paused**.** TrackForge is not taking new accounts at the moment. Choose **Email TrackForge support** to be told when you can join, then press **Sign out**. - ****Create my workspace** is switched off.** One of the four boxes is blank, or the offer is not ticked. - **A message appears above the buttons after you press it.** The message says what went wrong. Press the button again. If it keeps happening, choose **Contact support** at the foot of the screen. - **A workspace opened and you were not asked to set anything up.** That address already has a workspace, and you are signed in to it. ## Related - [Signing in](https://trackforge.studio/docs/workspace/signing-in) - [Your account](https://trackforge.studio/docs/workspace/account) - [What the Workspace is](https://trackforge.studio/docs/workspace/) - [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here) - [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues) --- *Source: [https://trackforge.studio/docs/workspace/signing-up](https://trackforge.studio/docs/workspace/signing-up)* --- ## docs/workspace/signing-in.md # Signing in > Sign in to your TrackForge Workspace with LinkedIn, Google or a code sent to your email, and sign out when you have finished. You sign in to the Workspace with LinkedIn, Google or a code sent to your email. New or returning, you sign in the same way. ## Before you start Use the email address your workspace is under. A workspace is found by email address, so a Google or LinkedIn account under a different address will not open it. ## Steps 1. Go to `trackforge.studio/workspace`. If you are not signed in, a sign-in page opens. Sign-in is run by Cloudflare, not by TrackForge, so the page carries Cloudflare's name. 2. Choose LinkedIn or Google and sign in there. Or type your email address and press "Send login code". 3. If you asked for a code, it comes by email. Type it into the page that asks for it. A code can take a minute to arrive. 4. The Workspace opens. If your address has no workspace yet, you are asked to set one up: see [Signing up](https://trackforge.studio/docs/workspace/signing-up). ## Signing out Press the account button at the right-hand end of the top bar and choose **Sign out** from its menu. The screen reads **Signing out…** and you are signed out. **Sign out** is switched off while an operation is still in progress. Wait for it to finish. Before the Workspace has opened, and on the screen that sets up a new workspace, **Sign out** is a button of its own. ## If you are asked to sign in again If your sign-in ends while the Workspace is open, the screen **Sign in to TrackForge Workspace** covers it. Any open edits stay in the tab. 1. Choose **Sign in**. The sign-in page opens in a new tab. 2. Sign in there with the same account. 3. Go back to the first tab. If the Workspace has not come back by itself, press **Continue in this tab**. If the screen also says **Keep this tab open: an operation is in progress or browser recovery is unavailable.**, do not close or reload the tab before you have signed in again. ## If something goes wrong - **The code has not arrived.** Wait a minute, then choose Resend on the page that asks for the code. - **You are told the account does not have access.** Email support@trackforge.studio from the address your workspace is under, and TrackForge will look into it. - **The page reads **This account has been blocked**.** TrackForge has stopped this account's access to the Workspace. The page gives no reason and offers **Sign out**. If you think this is a mistake, email support@trackforge.studio. - **You are asked to set up a workspace, but you already have one.** You have signed in with a different address. Press **Sign out** and sign in with the address your workspace is under. - **The screen stays on **Opening TrackForge Workspace…** with a message.** Press **Try again**. If the message stays, press **Sign out** and sign in again. ## Related - [Signing up](https://trackforge.studio/docs/workspace/signing-up) - [Your account](https://trackforge.studio/docs/workspace/account) - [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way) - [Getting help](https://trackforge.studio/docs/workspace/help/) - [Your data](https://trackforge.studio/docs/workspace/help/your-data) --- *Source: [https://trackforge.studio/docs/workspace/signing-in](https://trackforge.studio/docs/workspace/signing-in)* --- ## docs/workspace/finding-your-way.md # Finding your way around > Move between Today, Catalogue, Files and responses and Registration health, open Workspace settings, switch catalogue or workspace, and see how many works you have used. Four tabs take you between a catalogue's sections. **Workspace settings**, which applies to every catalogue, is in the account menu. Two choosers switch catalogue or workspace, and a meter shows how many works you have used. This page shows where each one is. ![The top of the Workspace: the Works meter, the catalogue chooser, the breadcrumb, the Search button, the Help for this page link and the four tabs, Today, Catalogue, Files and responses and Registration health.](https://trackforge.studio/docs/img/workspace/workspace-top.png) ## The four tabs ![The four tabs, Today, Catalogue, Files and responses and Registration health, with Today selected.](https://trackforge.studio/docs/img/workspace/workspace-tabs.png) The tabs run across the top of every screen of a catalogue and stay in view as you scroll. They stay on **All catalogues** too, with **Catalogue** selected: another tab there opens that page of the catalogue you last used, as the logo does. **All catalogues** has no breadcrumb. To work in a catalogue, choose it in the chooser, which opens that catalogue's **Today**. - **Today** shows what needs doing now. See [What Today shows](https://trackforge.studio/docs/workspace/today/). - **Catalogue** lists your saved works, and is where you add, find and edit them. - **Files and responses** is where you prepare a file, record that you sent it, upload the society's response and bring in your registration history. - **Registration health** shows where each society is up to with your works and what each society holds, with every figure opening the works behind it. **See the full picture** on **Today** opens it too. See [Registration health](https://trackforge.studio/docs/workspace/registration-health). **Agreements** has no tab. Open it with the button of that name on **Catalogue**; the **Catalogue** tab stays selected while you are there. ## Workspace settings **Workspace settings** has no tab, because it applies to every catalogue in the workspace. Open the account menu and choose **Workspace settings**, with the workspace's name beneath it. Every member can open it; only an owner or editor can change it. It holds the workspace's name (for the owner), your publisher details, your societies and the way to **Society connections**. Like the Account page, it takes the catalogue's place on the screen, so the tabs are not shown while it is open. **Back to catalogue** returns you to where you were, and **Search** stays in the top bar. See [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) and [Societies](https://trackforge.studio/docs/workspace/settings/societies). **Society connections** opens from **Open society connections** on **Workspace settings**. Its breadcrumb reads **Workspace settings**, then **Society connections**, and **Back to Workspace settings** takes you back. See [Society connections](https://trackforge.studio/docs/workspace/settings/society-connections). Choosing the tab you are already on takes you back to that section's own page, for example from an open work. ## Switch catalogue or workspace ![The Catalogue chooser and, beside it, the button Create another catalogue.](https://trackforge.studio/docs/img/workspace/workspace-chooser.png) Choose a catalogue from the chooser beside the breadcrumb. It lists your catalogues and **All catalogues**. If you are an owner or editor, a **Create another catalogue** button sits beside it. Choosing a catalogue opens its **Today**. Choosing **All catalogues** opens the works from every catalogue together. Deleted works are reached only from there. See [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues) and [History, undo and deleted works](https://trackforge.studio/docs/workspace/catalogue/history). If your account has two or more workspaces, a **Workspace** chooser sits above the catalogue chooser. With one workspace there is nothing to switch. ## Where you are ![The breadcrumb, reading Example Music Publishing then Today.](https://trackforge.studio/docs/img/workspace/workspace-breadcrumb.png) The breadcrumb shows where you are. It starts with the catalogue's name, which takes you back to its Today, then the section, then, inside a work, the work's title. Choose an earlier step to go back. A work opened from Today, the catalogue or a file shows a back button at the top: **Back to Today**, **Back to catalogue** or **Back to submission**. It returns you to where you came from. ## Your works allowance ![The Works meter, showing how many works are saved out of the most the account may hold.](https://trackforge.studio/docs/img/workspace/works-meter.png) Under the top bar, the **Works** meter shows how many works you have saved and the most your account may hold. The count covers every catalogue in the workspace. Deleted works do not count towards the limit. With several workspaces, the meter belongs to the one chosen in **Workspace**. When you reach the limit, the badge **Full** appears with a link, **ask for more**. It opens an email to TrackForge asking for more works. ## The top bar and footer The top bar starts with the product's name, followed by a grey **Beta** badge while the Workspace is in beta; the badge also sits beside the logo on the sign-in and sign-up pages. It is a label, not a status to act on. The **Search** button, the **Help for this page** and **Contact support** links and the account button are in the top bar. **Search**, or Ctrl+K (⌘K on a Mac), opens a box that goes to any section, finds a work, or searches the help: see [Getting help](https://trackforge.studio/docs/workspace/help/). **Help for this page** opens the page of this manual for the part of the Workspace you are in. The account button shows your initials and first name. It opens a menu with **Workspace settings**, **Profile**, **Plan and billing** and **Sign out**: see [Your account](https://trackforge.studio/docs/workspace/account). On a narrow screen the top bar leaves the two links out and the account button shows your initials alone. The footer has **Help and guides**, which opens the front page of these docs, the support link, and links to **Terms** and **Privacy**. Guides and reference pages open in a new tab, so you keep your place. See [Getting help](https://trackforge.studio/docs/workspace/help/). ![The right-hand end of the top bar: the Search button, Help for this page, Contact support and the account button, with initials and a first name.](https://trackforge.studio/docs/img/workspace/workspace-top-bar.png) ![The top of the Workspace on a phone, where the Search button shows a magnifying glass alone, above the Works meter, the catalogue chooser and the four tabs.](https://trackforge.studio/docs/img/workspace/workspace-top-phone.png) ## If something goes wrong - **The tabs and choosers are greyed out.** You have unsaved changes, or a save is under way. Save or close what you are working on first. - **A bar says **A newer version of this page is ready**.** Save your work, then choose **Reload now**. **Later** puts the bar away until you next load the page. - **No catalogue is open.** Choose one from the catalogue chooser. If the workspace has none yet, an owner or editor can create the first. ## Related - [What the Workspace is](https://trackforge.studio/docs/workspace/) - [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here) - [Your account](https://trackforge.studio/docs/workspace/account) - [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you) --- *Source: [https://trackforge.studio/docs/workspace/finding-your-way](https://trackforge.studio/docs/workspace/finding-your-way)* --- ## docs/workspace/today.md # What Today shows > See what needs doing now: your catalogue in numbers, what needs you, files to send or answer, society responses and charts. **Today** is the first screen you see. It shows the catalogue you have open, with how many works it holds, what to do next, and where your files and works stand. ## What you will see From the top of the screen down: - **A search box, **Find a work**.** It appears once the catalogue has works. Type a title, work reference, [ISWC](https://trackforge.studio/docs/cwr/glossary#iswc), ISRC, writer or publisher, then press Enter or choose **Search**, and the Catalogue opens with that search applied. - ****Get set up**.** The six-step card for a new workspace. It disappears when every step is done. See [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here). - ****Your next step**.** One panel with one button. See [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you). - ****Your catalogue in numbers**.** Counts of your works, each a way into what is behind it. - ****Needs you**** and ****Recent saved changes****, side by side on a wide screen. - ****Files in progress**.** Files you have prepared and not yet finished with. See below. - ****Society responses**.** The responses you have uploaded and the updates about them, each list folded shut under a count. See below. - ****From saved to accepted**.** A chart of where your works stand with one society. It appears once you have chosen your societies. - ****Month by month**.** Four charts of the last 12 months. It appears once the catalogue holds ten works. The figures and **Needs you** come before the files and responses, so what needs doing is never pushed down the page by a long list of responses. Where each society is up to with the whole catalogue, and what each society holds, is the tab **Registration health**. **See the full picture**, under **Your catalogue in numbers**, opens it. See [Registration health](https://trackforge.studio/docs/workspace/registration-health). ![Today for a catalogue with works, showing Find a work, Get set up, Your next step, Your catalogue in numbers, Needs you, Recent saved changes, Files in progress, Society responses, From saved to accepted and Month by month.](https://trackforge.studio/docs/img/workspace/today-overview.png) ### Your catalogue in numbers Once you have chosen your societies, the card starts with **Where your works are up to**, which splits your works by status. Each work is counted once, under the most pressing status any of your societies gives it. Choose a part, on the bar or in the list under it, to open those works in the Catalogue. A status with no works is left out. With fewer than ten works the card shows the figures as a list, with no bar. ![The card Your catalogue in numbers, with the bar Where your works are up to above six tiles of counts.](https://trackforge.studio/docs/img/workspace/today-numbers.png) The tiles below the bar count differently: a work is counted under every heading that applies. They count works, not files, so a file of five works adds five. **Needs information**, **Saved works**, **Registered differently** and **Not held by a society** open the Catalogue list. **Needs correction**, **Awaiting response** and **Accepted** open **Files and responses**. - **Needs information**: works with details to add. You can still save them. - **Needs correction**: works a society rejected or queried. - **Awaiting response**: works you have sent and have no response for yet. If exactly one file is waiting, the tile opens that file. - **Accepted**: works accepted in the latest response. - **Saved works**: everything in the catalogue. - **Registered differently**: works where a society holds different details from your catalogue. This tile appears only when the number is above zero. - **Not held by a society**: works that a society's own records do not list, from a work list you uploaded. It opens the Catalogue filtered to **Society position**, **Not held by the society**. This tile appears only when the number is above zero. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). The counts come from your TrackForge history, so a work with nothing recorded may already be registered elsewhere. [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) explains each one. ### Recent saved changes A table with the columns **Work**, **Change** and **Saved**, newest first. **Change** reads **Added** for a new work, or **Version** and a number for an edit. Choose a title to open the work. ### Files in progress TrackForge sends nothing itself, so a prepared file stays here until you have sent it and uploaded the society's reply. Each file shows the society, how many works it holds, its file name and a badge: - **Prepared — not sent**. Send the file to the society yourself, then press **Record that you sent it**. - **Awaiting response**. You have recorded the send. When the society replies, press **Upload the response**. If no response has come after 30 days, the line reads **No response after 30 days**. If you can only look, the button on each file reads **Open file**. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send). ![The Files in progress card on Today on a phone, with one file prepared and not sent and one file awaiting a response.](https://trackforge.studio/docs/img/workspace/today-phone.png) ### Society responses The card holds two folded lists, each under a label that counts what is in it. Open a fold to read the list. - **Uploaded responses**, under a label such as "3 uploaded responses". Each response you have uploaded, newest first, with the society and what it said, for example one work needing correction and four accepted. A response that changed nothing, because a later one stands, sits below the others. **Open the file** takes you to the file it answers. See [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response). - **Updates**, under a label such as "3 updates, 1 new". Notices such as **New society response received**, **A society response needs review** and **Automatic response checks paused**, newest first. The label says how many you have not read yet. **Mark as read** on an update clears it from the count, here and on the bell in the top bar. Until you upload a response, the card says so. ### From saved to accepted This card follows your works through one society. **Saved works** is on the left and the society's answer on the right. Works that have not gone to the society yet are gathered under **Still with you**, and works it has answered under **Answered**. Each work is counted once, by where it stands with that society. With more than one society, choose which in **Society**. Choose a part of the chart to open those works in the Catalogue. On a narrow screen the card shows one bar in place of the chart, and with fewer than ten works a list of figures. ![The card From saved to accepted for one society, with Saved works on the left flowing to the statuses the works are in.](https://trackforge.studio/docs/img/workspace/today-flow.png) ### Month by month Four charts of the last 12 months. They are there to look at and open nothing. Each gives its figure in words above the drawing. - **Works added**: works first saved in each month. - **Sends recorded**: sends you recorded in each month. - **Answers from societies**: a work is counted once for each society, under its latest answer, in the month that answer arrived. - **Accepted so far**: works a society has accepted, counted once for each society and added up month by month. A chart with nothing to show says so in words, for example **No sends recorded in the last 12 months.** ![The card Month by month, with the four charts Works added, Sends recorded, Answers from societies and Accepted so far.](https://trackforge.studio/docs/img/workspace/today-months.png) ## If something goes wrong - **Today could not be loaded.** Press **Try again**, or **Open saved catalogue** to carry on in the Catalogue. - **A part of a chart opens nothing.** On **From saved to accepted**, **No TrackForge history** opens the list only when the list would show exactly the works the chart counts. The charts in **Month by month** open nothing. ## Related - [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you) - [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way) - [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find) --- *Source: [https://trackforge.studio/docs/workspace/today/](https://trackforge.studio/docs/workspace/today/)* --- ## docs/workspace/today/needs-you.md # What needs you next > Follow your next step, open the works that need information, and continue or discard an unfinished import. **Today** works out the one thing to do next and lists everything else that is waiting. Use this page to follow your next step, open the works that need information, and deal with an unfinished import. ## Follow your next step 1. Open **Today**. 2. Read the panel marked **Your next step**. Its heading says what to do and the line below says why. 3. Press the button, which opens the screen where you do it. If you can only look, the panel reads **Your catalogue at a glance**, with a **View catalogue** button. While the **Get set up** card still has works, societies or publisher details to do, owners and editors see the card's button instead. See [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here). Under the step, a line may read "Upload your PRS work list so TrackForge can show what PRS holds", with a link **Open Registration history**. It appears for owners and editors when one of your societies publishes a work list TrackForge can read and you have not uploaded one yet. It is not the step: what a society holds is something to know, not something to do. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). Today picks the first of these that applies: 1. **Continue import**, when an import has works left to review. 2. Something a society or a check has raised: a rejected work (**Review society response**), a work registered differently from your catalogue (**Review the differences**), a work TrackForge could not check (**Review incomplete checks**), or a file whose response is overdue (**Open recorded delivery**). These come before works that need information. 3. **Fix what is missing**, when works need information before they can go in a file. 4. **Prepare work**, when a work is ready and none needs information. 5. **Import your first works**, when the catalogue is empty. 6. **See what the societies hold**, step 5 of the **Get set up** card, while nothing has been brought in, no reading of a society's records exists and no file has been prepared. It opens **Registration health**. See [Registration health](https://trackforge.studio/docs/workspace/registration-health). 7. Your files: **Review preparation issues**, **Record that you sent your file** or **Open the file you sent**. 8. **Choose works to prepare**, when nothing else is waiting. ## Open the works that need information 1. On **Today**, find the card **Needs you**, under **Your catalogue in numbers**, and its **Needs information** group, which shows how many works. A single work has its own card with **Open work**. 2. With two or more works, the table **What is missing** lists each cause and its works. 3. Press **Fix what is missing**. The catalogue opens filtered to **Needs information (any society)**, with the panel **What is holding your works up** above the list. 4. To go straight to one work, choose **Show the works** in the group, then a title. **Back to Today** returns you. 5. Fix the work using its explanation. See [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). A work's chip in the catalogue list calls this same state **Details missing**. ![The Needs you card with a Needs information group of three works, the What is missing table and the Fix what is missing button.](https://trackforge.studio/docs/img/workspace/needs-you.png) ## What else Needs you holds A cause covering several works or files is one group with a count and one button, for owners and editors. - **Couldn't check**: **Open Workspace settings**. - **Registration differs from catalogue**: **Review the differences**. - **Ready**: **Prepare a file**. - Overdue **Awaiting response**: **Open your files**. - **Needs correction**: **Open Files and responses**. A single work or file is a card with the reason, the next action and buttons such as **Open work** (**View work** if you can only look), **Continue correction** and **View response and history**. There is no button to send a file again. For a rejected work you fix and save it, prepare a new file, send it yourself and record the send. See [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again). ## Continue or discard an unfinished import An import you did not finish appears as an **Unfinished import** card with the file name, upload date and number of works saved. - **Continue import** reopens it where you left off. See [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review). - **Discard import** asks you to confirm. If some works are already saved, the confirmation says it will keep them, and its button reads **Skip the rest**. Discarding never removes works you have already saved. ## If something goes wrong - **Needs you is empty.** It holds missing details, society corrections and overdue responses. A file waiting for a reply is under **Files in progress**. - **A note says some items are not shown.** Choose **Open the catalogue** to review the rest. ## Related - [What Today shows](https://trackforge.studio/docs/workspace/today/) - [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) --- *Source: [https://trackforge.studio/docs/workspace/today/needs-you](https://trackforge.studio/docs/workspace/today/needs-you)* --- ## docs/workspace/add-works.md # Ways to add works > Choose how to add works: by hand, from a spreadsheet or CWR file, from a Workbench draft, or as old files kept as a record. You can fill a catalogue in several ways. Choose the one that matches what you already have. Incomplete work is welcome, so save what you know now and complete the rest later. ![The Catalogue heading with the buttons Agreements, Import a file, Add a work, Download and Registration health.](https://trackforge.studio/docs/img/workspace/catalogue-add-buttons.png) ## Choose a way **By hand.** Choose **Add a work** on the **Catalogue** tab to type in a work. See [Add a work by hand](https://trackforge.studio/docs/workspace/add-works/by-hand). **From a spreadsheet.** Choose **Import a file (CSV, TSV, Excel or CWR)** when your works are in a CSV, TSV or Excel file. You match its columns, then check the result before saving. See [Import a spreadsheet](https://trackforge.studio/docs/workspace/add-works/spreadsheet) and [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review). **From a CWR file.** The same button takes a `.V21` file made for a society. The Workspace keeps the original and lets you choose which works to save. See [Import a CWR file](https://trackforge.studio/docs/workspace/add-works/cwr-file). **From a Workbench draft.** If you started in the free [CWR Workbench](https://trackforge.studio/cwr-tool), its **Save to workspace** button brings the draft here. See [Bring in a draft from the Workbench](https://trackforge.studio/docs/workspace/add-works/from-the-workbench). **Old files as a record.** Registration files you sent before, and the societies' replies, are not a way to add works. They are kept as a record and compared with your catalogue. Once your catalogue has works, **Registration health** offers **Bring in old files and replies** under **Add what you know**. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). **Add a work** and **Import a file (CSV, TSV, Excel or CWR)** are also in the **Get set up** card on **Today** while you are setting up. ## What happens when you import What happens when you import works: you choose a file, check each item and choose what happens to it, and nothing reaches your catalogue until you save. What happens when you import, as the sentence above says: you choose a file, match the columns of a spreadsheet, check each item, choose to match it, create a separate work or skip it, and save. ```d2 direction: down file: Choose a file kind: Which kind? columns: Match the columns check: Check each item choose: "For each item,\nchoose" match: "Match an\nexisting work" separate: "Create a\nseparate work" skip: Skip this item save: Save done: "The works are in\nyour catalogue" file -> kind kind -> columns: Spreadsheet kind -> check: CWR file columns -> check check -> choose choose -> match choose -> separate choose -> skip match -> save separate -> save skip -> save save -> done ``` ## Good to know - With view-only access to a workspace you do not see these buttons. - Works count towards your allowance across all catalogues. See [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way). - Adding works sends nothing to a society. You prepare a file and send it, from the Workspace or yourself. ## Related - [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here) - [Societies](https://trackforge.studio/docs/workspace/settings/societies) --- *Source: [https://trackforge.studio/docs/workspace/add-works/](https://trackforge.studio/docs/workspace/add-works/)* --- ## docs/workspace/add-works/spreadsheet.md # Import a spreadsheet > Upload a CSV, TSV or Excel file of works, check how its columns are matched and preview the changes before anything is saved. Use this page to bring works from a spreadsheet into a catalogue. Uploading does not change your catalogue. Works are added only when you save, as [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review) explains. ## Before you start - You need to be able to edit the workspace. With view-only access the import button is not there. - Open the catalogue the works should go into. [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues) shows how to make a new one. - Your file can be an Excel file (.xlsx), a CSV or a TSV. CSV and TSV are plain text files that any spreadsheet program can save. - Name each column at the top, such as Title or [ISWC](https://trackforge.studio/docs/cwr/glossary#iswc). The Workspace suggests where it goes from the name. - The largest file size and the most rows are listed on the screen under **Sizes and file types**. A file over the size limit is refused before it uploads. ## Steps 1. Go to **Catalogue** and choose **Import a file (CSV, TSV, Excel or CWR)**. The **Import works** panel opens. 2. Under **Import file**, choose your file, then choose **Upload and review**. 3. If an Excel file has more than one sheet, pick one under **Workbook sheet** and choose **Open selected sheet**. If you reopened a saved import, the screen asks you to choose the original file again first. 4. Under **Check your columns**, open **Match your columns**. For each column the table shows **Your column**, a sample from the **First row**, and where it **Goes to**. Check every suggestion. Change a destination from its list, or choose **Not imported** for a column you do not need. 5. Choose **Preview changes**. The works appear below for review. ![The Match your columns table of a spreadsheet import, listing each column of the file and the place the Workspace suggests for it.](https://trackforge.studio/docs/img/workspace/import-columns.png) ## How columns are matched The Workspace matches by name, and capital letters, underscores and hyphens do not matter. Title and Song title suggest **Work title**. Work reference and Work code suggest **Your work reference**. ISWC, ISRC, Label, Album and Publisher match the details of those names. Numbered columns such as Writer 2 IPI become the second writer on each work, and publishers and recordings work the same way. You can have up to 10 of each. A destination takes one column: give it to another and the first becomes **Not imported**. The Workspace does not guess when a column name is blank, appears twice or fits two details, or when a column holds writers' full names. Choose those yourself, and split full names into first-name and last-name columns first. A suggestion changes nothing until you choose **Preview changes**. ## A work with several recordings A song with two or more ISRCs is one work with two or more recordings. Give a sheet's recordings to their work in any of these three ways. Each gives one work holding every recording, not one work per ISRC. - **List the ISRCs in one cell.** Separate them with a semicolon, a comma, a vertical bar or a line break, as in AOA4Y2600105; USL4R2557287. Each ISRC becomes a recording of the work, and a repeated ISRC is read once. A label, album, release date or other recording detail on the same row cannot say which recording it belongs to, so the row is refused. Give those details in one of the two ways below. - **Give each recording its own row, with the same work reference.** Rows that share a **Your work reference** become one work, and each row's ISRC, label and release date make one of its recordings. Later rows can leave the title, writers and publishers blank. A title, ISWC or other work detail given again must be the same as on the first row. A row with no work reference is a work of its own, so fill in the reference on every row. - **Use numbered columns.** ISRC 2, Label 2 or Recording 2 ISRC become the work's second recording, up to 10. If the Workspace does not suggest one, open that column's **Goes to** list and choose ISRC under Recording 2. | Work reference | Title | ISRC | Label | |---|---|---|---| | W001 | My Song | AOA4Y2600105 | Label A | | W001 | My Song | USL4R2557287 | Label B | These two rows make one work, My Song, with two recordings. ## The CWR Workbench's template The Workspace reads every column of the CWR Workbench's template spreadsheet, and the works make the same CWR file they would from the Workbench, with these differences: - The template's Version Type column says whether each work is original or modified. Write ORI or Original for an original work, and MOD, Modified, Arrangement, Adaptation or Translation for a modified version. When the column is missing or a cell is empty, the Workbench assumes an original work and the Workspace asks you; [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many) sets it for all the works together. Templates downloaded before 14 October 2026 have no Version Type column: add one with that name, anywhere in the sheet. - The template's Music Arrangement and Lyric Adaptation columns say what happened in a modified version, and become **Music in this version** and **Lyrics in this version**. For the music, write ARR or Arranged, NEW or New music, ADM or Music added to lyrics, ORI or Original, or UNS or Unspecified. For the lyrics, write TRA or Translated, MOD or Modified, REP or Replaced, NEW or New lyrics, ADL or Lyrics added to music, ORI or Original, NON or Instrumental, or UNS or Unspecified. Societies reject a modified version without both, or without a writer whose role is arranger, adaptor or translator. The template's second work is an arrangement that shows all three. Leave both columns empty for an original work. - The template's Duration column becomes the work's **Duration**. Give a recording its own length in a **Recording duration** column. - The template's Release EAN/UPC column, or a column named EAN, UPC or Barcode, becomes the recording's **Release barcode (EAN or UPC)**: a 13-digit EAN is kept as it is, and a 12-digit UPC is written with a leading 0, which is how the CWR file holds it. - An alternative title gets a language only from an **Alternative title language** column. The Workbench gives each one the work's language. - The template's optional Lyrics column (tick **Include a Lyrics column** when you download it) keeps each work's lyrics for LyricFind. Both sides read it the same way and neither puts lyrics in the CWR file. See [Lyrics and LyricFind](https://trackforge.studio/docs/workspace/catalogue/lyrics). Each Sub-Publisher group is read as the next publisher on its row. It is placed under the publisher named in its **Parent publisher** column or, when that cell is empty and its role is sub-publisher or administrator, under the row's own publisher. A sub-publisher named under two publishers of a work is kept once under each. If its role is empty, the Workspace leaves the role for you to choose. In any spreadsheet, a cell can list several alternative titles or several performers, separated by a semicolon, a vertical bar or a line break. Each becomes its own entry, and a repeated name is read once. A cell can list several ISRCs the same way, or separated by commas: see [A work with several recordings](#a-work-with-several-recordings). ## Other choices on this screen - **Advanced: catalogue source** holds **Source catalogue system**, a name that keeps work references from different sources apart. Keep it the same when you import updates from one system. - **When updating saved works, let empty cells remove saved values** lets a blank cell clear a saved detail. If you tick it, most columns offer **Empty cells remove the saved value**, and the preview shows each removal first. ## If something goes wrong - **Preview changes** is switched off. At least one column must go somewhere, and the source name cannot be empty. - "No works were found in the mapped rows" means the columns you chose do not hold work details. Change them and preview again. - A row is refused because its ISRC column lists several recordings. A label, release date or other recording detail on that row cannot say which recording it is for. Give each recording its own row with the same work reference, or its own numbered columns. See [A work with several recordings](#a-work-with-several-recordings). - The preview shows the same song as two works, one for each ISRC. Their rows have different work references, or none. Give them the same work reference and preview again. - **Reload saved import** appears with a message. Choose it, then preview again. - The file has too many rows. After you choose **Upload and review**, a message says the file or worksheet exceeds the limit of data rows. The limit is listed under **Sizes and file types**. Split the works across smaller files and import them one after another. - You leave before saving. The import waits under **Saved imports** as **Match columns**, or **Continue review** once previewed. ## Related - [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review) - [Import a CWR file](https://trackforge.studio/docs/workspace/add-works/cwr-file) - [Ways to add works](https://trackforge.studio/docs/workspace/add-works/) --- *Source: [https://trackforge.studio/docs/workspace/add-works/spreadsheet](https://trackforge.studio/docs/workspace/add-works/spreadsheet)* --- ## docs/workspace/add-works/cwr-file.md # Import a CWR file > Import a CWR file you already have, check its works against your saved works and choose which to save. Use this when you already have a [CWR](https://trackforge.studio/docs/cwr/glossary#cwr) file and want its works in your catalogue. The Workspace keeps your original file exactly as it is, then lets you review and save its works. ## Before you start - You need the original `.V21` file, as it was made, for example `CW260003TST_000.V21`. Only that file works here. - Society replies and old files that you only want to keep as a record do not belong here. Use [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). - The same size limit applies as for spreadsheets. It is listed under **Sizes and file types** on the import screen. A file is also refused, before it is read, when it has more than 250,000 lines or more than 30,000 works: more than a genuine CWR file holds. The message says which, and asks you to check the file or split it. The Workbench applies the same limits. - You need to be able to edit the workspace. ## Steps 1. Go to **Catalogue** and choose **Import a file (CSV, TSV, Excel or CWR)**. 2. Under **Import file**, choose the `.V21` file, then choose **Upload and review**. Uploading does not change your catalogue. 3. Check the file name and the number of works and records in the file. **Original source preservation** says whether the Workspace can open the file without changing it. **Download original .V21** gives you the file back exactly as you uploaded it. 4. Under **Review works before saving**, each work is compared with the works you have saved. Untick any you do not want. The count shows how many are selected. 5. Open **Choose how to import this work** on any item that needs a choice. When you change a choice, **Review matching choices** appears. Choose it before you save. 6. Choose the button that begins **Save** and shows how many works are selected. ![Review works before saving for a CWR file, with one work marked Choose a match because a similar saved work exists, and the next work marked New work.](https://trackforge.studio/docs/img/workspace/import-review-cwr.png) ## What you will see Each work gets a state such as **New work**, **Updates saved work** or **Choose a match**. [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review) explains each state, how to match, separate or skip a work, and what happens after you save. There are no columns to match with a CWR file. A CWR file never overwrites a saved work on its own. You confirm each update. A similar work can stay separate when it has a different CWR reference. ## If something goes wrong - **The file cannot be opened for editing.** The screen says the source is kept exactly but cannot safely be opened. It is listed as **Kept for download** and has no works to review or save. The screen gives a plain sentence for each problem. The exact detail sits under **Technical details**, for whoever made the file. - **The file is too big.** You see a message asking for a smaller file before anything uploads. - **You leave before saving.** The import waits under **Saved imports**. Choose its file name to carry on. ## Related - [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review) - [Import a spreadsheet](https://trackforge.studio/docs/workspace/add-works/spreadsheet) - [Ways to add works](https://trackforge.studio/docs/workspace/add-works/) --- *Source: [https://trackforge.studio/docs/workspace/add-works/cwr-file](https://trackforge.studio/docs/workspace/add-works/cwr-file)* --- ## docs/workspace/add-works/review.md # Review an import before saving > Read the state of each imported work, deal with anything that stops a save, save the works you want and undo an import that was wrong. After you choose **Preview changes** on a spreadsheet, or upload a CWR file, the Workspace lists each row or work as an item to check. Nothing reaches your catalogue until you save. Saving sends nothing to a society. ## What you will see Counts at the top total the items in each state. A work with no reference of its own is numbered when you save (W000001 and so on); you can change it on the work's page before you send a file. **Details to check (you can still save)** counts works with no title, no writers or no writer role, and an ISWC, ISRC or IPI that looks mistyped. They do not stop a save. Fix them afterwards: see [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). Each item shows its title, its row numbers and a state: | State | What it means | |---|---| | **New work** | It will be added when you save. | | **Updates saved work** | It matches a work you have saved. Saving updates that work and keeps its earlier version. | | **Unchanged** | It matches a saved work and nothing differs, so no new version is needed. | | **Choose a match** | The Workspace cannot tell which work this is. | | **Needs attention** | It cannot be saved yet. The message on the item says why. | | **Skipped** | You left it out. | | **Saved** and **Undone** | It was added, or removed again by an undo. | To see what an update changes, open the section under the item that begins **Review**. It compares the **Saved value** with the **Proposed value** for each **Field**. **Not supplied** means nothing is saved there; **Clear saved value** means the update would empty it. A publisher's territory rows are matched by what they cover, not by their wording. When a re-imported row collects a right in a country where a saved row of the same publisher already collects it, the new row is the file's newer statement of that row: it replaces the saved row, exclusions included, rather than being added beside it. So a sheet re-imported with one country corrected gives the work one row, not two rows that both collect across most of the world. A row for other countries or other rights is added as before, and a row whose countries cannot be read for certain never replaces anything. ![Review, then save for a spreadsheet import, with the counts of new works and updates above the first three works, each marked New work.](https://trackforge.studio/docs/img/workspace/import-review-sheet.png) ## What stops a save Items marked **Choose a match** or **Needs attention** cannot be ticked. Save also stays off while nothing is ticked, or after you change a choice and before you preview again. 1. On the item, open **Choose how to import this work**. 2. Under **Matching choice**, choose **Create a separate work**, **Match an existing work** or **Skip this item**. To match, find the work with **Search all saved works** and pick it under **Existing work**. 3. Choose **Preview changes** again. For a CWR file it is **Review matching choices**. Where a row has one similar saved work, one button matches every such row. Where it has several, choose for each. An item that would remove saved details is not ticked and says **Removes**. Tick it only if you mean that. ## Save Choose the button that begins **Save** and shows how many works are selected. A save is all or nothing. From 100 works the screen shows a progress bar and an estimate; keep the page open. You can save the ready works now and return for the rest. If the works you ticked would take you over your works limit, the save is refused and nothing is saved. The message says how many works there is room for. Untick some works and save again, or see **ask for more** in [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way). ## After you save The panel says **This import is complete.** and how many works are now in your catalogue. The next step is **Next: choose your societies**, or **See your next step** once you have chosen them. **View your works** shows the catalogue. If some items are unresolved, the import stays open. Continue it from **Saved imports**, or from the **Unfinished import** card on **Today** with **Continue import**. **Discard import** sets it aside; if some works are already saved, its confirmation button reads **Skip the rest** and they stay. ## Undo an import When an import has added works, choose **Undo this import**. In the **Confirm undo** window, choose the button that begins **Delete** and counts the works. The works leave every catalogue and stop counting towards your limit. Restore them from **Deleted works** under **All catalogues**: see [History, undo and deleted works](https://trackforge.studio/docs/workspace/catalogue/history). Changes the import made to works you already had stay. ## Related - [Import a spreadsheet](https://trackforge.studio/docs/workspace/add-works/spreadsheet) - [Import a CWR file](https://trackforge.studio/docs/workspace/add-works/cwr-file) - [Societies](https://trackforge.studio/docs/workspace/settings/societies) --- *Source: [https://trackforge.studio/docs/workspace/add-works/review](https://trackforge.studio/docs/workspace/add-works/review)* --- ## docs/workspace/add-works/by-hand.md # Add a work by hand > Add one work by hand, fix any format messages, and save what you know now so you can complete the rest later. Use this to put one work into a catalogue by typing it in. You do not need every detail. Save what you know now and complete the rest later. ## Before you start You need to be able to edit the workspace. With view-only access the button is not there. Have the title to hand. Add writers, recordings and publishers now if you have them. ## Steps 1. Go to **Catalogue** and choose **Add a work**. If you left a new work unsaved, the button reads **Resume new work**. Unsaved changes are kept on this device for 24 hours. 2. Type the **Work title**. If you have one, type **Your work reference**, the code that identifies this work in your catalogue. Each work needs its own. If the save is refused because that reference already belongs to a saved work, type a different one, or open the existing work if it is the same work. Below them the form is in sections that fold: **Writers**, **Recordings**, **Publishers**, **Work details every society needs** and **Alternative titles, performers and lyrics**. On a new work the first four start open. Each label says in one line what the section holds. 3. In **Writers**, choose **Add writer** for each writer. Enter the name and role. Leave the [IPI](https://trackforge.studio/docs/cwr/glossary#ipi) blank if you do not know it yet. Shares are covered in [Writers, publishers and shares](https://trackforge.studio/docs/workspace/catalogue/shares). 4. In **Recordings**, choose **Add recording** for each recording, and type its ISRC. A song with two ISRCs is one work with two recordings: add both here, not as two works. See [Recordings](https://trackforge.studio/docs/workspace/catalogue/recordings#one-work-several-isrcs). 5. In **Publishers**, choose **Add original publisher** if you know the [publisher](https://trackforge.studio/docs/cwr/glossary#publisher). If you have saved your publisher details in **Workspace settings**, the first publisher starts as that one. Type over it if the work has another. 6. In **Work details every society needs**, fill in the ISWC, language, category, duration and more. Alternative titles and performers are under **Alternative titles, performers and lyrics**, which starts folded. See [Additional details](https://trackforge.studio/docs/workspace/catalogue/additional-details). 7. Choose **Save work**, or press Ctrl+S (⌘S on a Mac). The bar at the top then reads **Saved** with a version number. The buttons **Save and go to writers**, **Save and go to recordings**, **Save and go to publishers**, **Save and go to work details** and **Save and finish** save, then open that section and put the cursor in it. ![The Add a work form with the Save work bar at the top, the boxes for the title and reference, the open Writers section and the To do panel beside them.](https://trackforge.studio/docs/img/workspace/add-work-form.png) ## Fix format messages before you save A box whose content does not fit its format shows a message beneath it. Correct it, or clear the box if you do not know the value. - **Your work reference**: 1 to 14 letters, digits or other printable characters, without accents and with no space at the start or end. - **Work identifier (ISWC)**: it looks like T-123.456.789-4 and its last digit checks the rest. See [the ISWC problem](https://trackforge.studio/docs/cwr/problems-and-fixes#iswc-format). - An ISRC on a recording: 12 characters, such as GBAAA2600001. It is a two-letter country code, three letters or digits, then seven digits. See [the ISRC problem](https://trackforge.studio/docs/cwr/problems-and-fixes#recording-isrc-invalid). - **Work duration (HHMMSS)**: six digits, so 000330 is 3 minutes 30 seconds. Minutes and seconds go up to 59, and it cannot be all zeros. - **Copyright date (YYYYMMDD)**: eight digits that make a real date, such as 20200131. - A writer's or publisher's IPI: 9 to 11 digits, with no spaces or punctuation. If the digits fit the format but the number looks mistyped, the box shows a warning, not an error, and the work still saves. A recording's release date and duration are under **Release date and duration**, which opens by itself when one needs fixing. ## What you will see The work joins the catalogue's saved works. A badge on the bar counts what is still to do. [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work) explains saving, the recovery copy and the To do list, and [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems) shows what each problem needs. ## Related - [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work) - [Ways to add works](https://trackforge.studio/docs/workspace/add-works/) - [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) --- *Source: [https://trackforge.studio/docs/workspace/add-works/by-hand](https://trackforge.studio/docs/workspace/add-works/by-hand)* --- ## docs/workspace/add-works/from-the-workbench.md # Bring in a draft from the Workbench > Bring a draft you saved from the CWR Workbench into your Workspace, after checking where it will go. The [CWR Workbench](https://trackforge.studio/cwr-tool) is TrackForge's free public tool for building a CWR file. When you choose **Save to workspace** there, your draft waits in the Workspace for you to confirm. Nothing is added until you do. ## Before you start - Stay in the same browser tab. The Workbench passes the draft to the Workspace through that tab. If you close it, or open the Workspace in another tab or browser, the draft is not there: go back to the Workbench and choose **Save to workspace** again. - You need to be able to edit the workspace. With view-only access the screen tells you to choose a workspace where you can edit, or to discard the draft. - Act within 24 hours. After that the draft expires, but the draft in the Workbench is unchanged. ## Steps 1. In the Workbench, choose **Save to workspace**. The Workspace opens with **Add this Workbench draft?**. 2. Read the destination. It gives the number of works and says they go into the selected catalogue. If you belong to more than one workspace, choose the right one first. The draft stays waiting while you do. To change the catalogue, see [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues). 3. Check the list. Each work shows its title, or "Untitled work" with a number if it has none, and how many writers it has. A work with lyrics also shows how many lines they have: they come across with the work and are kept beside it, never in its CWR details. See [Lyrics and LyricFind](https://trackforge.studio/docs/workspace/catalogue/lyrics). 4. Choose the button that begins **Add**. It reads Add work for one work and counts them for more. The button reads **Adding draft…** while it works. 5. A message at the top of the catalogue says how many works were added and to which catalogue. They now appear in your saved works. ![The Add this Workbench draft? card, listing two works with the number of writers each has, above the button Add 2 works.](https://trackforge.studio/docs/img/workspace/workbench-draft.png) To leave the draft out, choose **Cancel**. That removes only this hand-over. The draft in the Workbench stays where it is. ## If something goes wrong - **No longer available in this browser.** Go back to the Workbench and choose **Save to workspace** again. - **Expired after 24 hours.** Start **Save to workspace** again. - **Opened by another account.** A draft belongs to the first account that opens it in that browser. Sign back into that account, or choose **Remove this handoff**. - **The browser could not protect the draft.** Return to the Workbench and try again. - **Adding stopped part-way.** Works already added are safe. Try again to finish the rest. Trying again never makes duplicates. ## Related - [Ways to add works](https://trackforge.studio/docs/workspace/add-works/) - [Import a spreadsheet](https://trackforge.studio/docs/workspace/add-works/spreadsheet) - [Add a work by hand](https://trackforge.studio/docs/workspace/add-works/by-hand) --- *Source: [https://trackforge.studio/docs/workspace/add-works/from-the-workbench](https://trackforge.studio/docs/workspace/add-works/from-the-workbench)* --- ## docs/workspace/catalogue/find.md # Find, filter and sort works > Search your saved works, narrow the list by writer, publisher, society, status, ISWC or date, sort it, and tick the works you want to act on. The list in **Catalogue** holds every saved work. Search it to find one work, or filter it to find every work that needs something from you. ## Find the works that need your information 1. Open **Catalogue**. On a narrow screen the filters are folded under **Filters**. 2. Press **Needs information (any society)**. The list shrinks to those works, and the line above it says how many match and offers **Clear filters**. 3. Open a work. Press **Details missing** on its row to land on its **To do** list, or press its title to open the editor. 4. Follow the explanations to fix it. See [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). **Fix what is missing** on **Today** opens this same filtered list. See [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you). Three names mean one thing here: the row says **Details missing**, the filter button says **Needs information (any society)**, and the status choice says **Needs your information**. ![The Catalogue list filtered to Needs information, with the count line, the two cards of figures, the panel What is holding your works up and a Details missing chip on a work.](https://trackforge.studio/docs/img/workspace/find.png) ## Search, filter and sort - **Search saved works** looks through each work's own details: its title and any alternate title, work reference, ISWC, artists, every writer and publisher by name, IPI or IP number, and its recordings' ISRC, album title, label, catalogue number and EAN. Each word you type is looked for on its own, and a work shows when every word is found somewhere in its details, so *smith harbour* finds a work by Smith with Harbour in its title. An ISRC is found with or without its hyphens and spaces. The list narrows as you type. A date typed here is looked for as text, so use **Date** to find works by when something happened. - **Writer name or identifier** and **Publisher name or identifier** narrow it by a person or company. - **Society** and **Status** go together, and appear once you have chosen your societies in **Workspace settings**. With a society chosen, **Status** picks where works stand with that society. With **Society** left on **Any**, it picks by each work's one overall state: the most pressing status any of its societies is in, which is what the chart on **Today** counts. Its choices are **Needs your information**, **Not checked yet**, **Ready to prepare**, **With the society**, **Accepted**, **Needs correction or review** and **No TrackForge history**. [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) explains them. - **ISWC** keeps works that have one (**Has ISWC**) or lack one (**No ISWC**). - **Recordings** keeps works that list a recording (**Recording listed**) or list none (**No recording listed**). On the list of works with none, each row has an **Add a recording** button. - **Date** narrows the list by one date. Choose **Recording released**, **Work added**, **Last updated**, **Sent to a society** or **Society response received**, then a **From** day, a **To** day or both. Both days count, and either can be left empty. For **Recording released** you can type a **Year** instead. See [Find works by date](#find-works-by-date). - The buttons **Changed since submission**, **Registration differs** and **Details to confirm** each switch one more filter on. - **Sort by** offers **Last updated** (newest first), **Title**, **Reference** and **Status (needs you first)**. The footer moves between pages and sets how many works show: 25, 50 or 100. Your search, filters and sort stay in the page address, so reloading or going back keeps them. Reloading returns you to the first page. ## Find works by date **Date** keeps the works where that date falls between the two days you pick. Days run midnight to midnight in UK time (GMT, or BST in summer). - **Recording released** is any recording's first release date. A date saved as a year alone, such as 1995, counts only when your days cover that whole year, and a year and month only when they cover that whole month. A recording with no release date, or one that is not a date, never matches. Typing a **Year** sets the days to 1 January and 31 December of it. - **Work added** is the day the work was first saved. - **Last updated** is the day it was last saved. - **Sent to a society** is the day a file holding the work was sent, as you recorded it. - **Society response received** is the day a society's response that names the work reached the Workspace: when you uploaded it, or when it was collected for you. If the **From** day is later than the **To** day, the day you picked last moves the other to match. **Any** takes the date filter off. ## The figures above the list The card **What you have entered** above the list splits the catalogue's works two ways. **Recordings** shows **Recording listed** against **No recording listed**, and **ISWC** shows **Has ISWC** against **No ISWC**. Every figure opens the list with that one filter on and the others cleared. With fewer than ten works each is a list of figures with no drawing. Where each society is up to with your works is on the tab **Registration health**. See [Registration health](https://trackforge.studio/docs/workspace/registration-health). ![The card What you have entered, above the list of works in Catalogue.](https://trackforge.studio/docs/img/workspace/catalogue-figures.png) ## What a row shows Under the title you see the work reference, the writers' surnames and the ISWC. **Your details** reads **Complete**, **Details missing**, **Checking for** a society, or **Couldn't check**. Each society then has its own column. **Unsaved browser edits available** means the work has a recovery copy. See [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work). ## Tick works to act on them Owners and editors get tick boxes. **Select all works on this page** is in the heading row. **Prepare selected works** starts a file from your ticks. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). Ticks stay while you search, filter or change page, and they use saved versions. A work saved since you ticked it shows **Changed since selection**, so tick it again. ## If something goes wrong - ****No matching works.**** Press **Clear filters**. - ****Your works have not been checked yet**.** No society is chosen, so works are not checked for any. **Choose your societies** opens the choice. - **Checks seem stuck.** The list refreshes itself while works are being checked. If it stops, press **Refresh**. ## Keyboard In a row, Tab reaches the tick box, the title and the first society. The left and right arrow keys, Home and End then move between the societies. ## Related - [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you) - [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many) - [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/find](https://trackforge.studio/docs/workspace/catalogue/find)* --- ## docs/workspace/catalogue/edit-a-work.md # Edit a work > Open a saved work, change its title, reference, ISWC, language and other details, save it, and recover edits you have not saved. Use the editor to change a saved work or fill in what is missing. Save what you know and complete the rest later. ## Before you start You need to be an owner or editor. With view-only access the form is switched off and the editor says **You have view access to this workspace.** ## Steps 1. In **Catalogue**, press the work's title. See [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find). 2. Change what you need. The bar at the top reads **Unsaved changes. Press Save work to keep them.** 3. Press **Save work**. The bar reads **Saved** with a version number. Each save is a new version. See [History, undo and deleted works](https://trackforge.studio/docs/workspace/catalogue/history). 4. Press **Back to catalogue**. ## What the editor holds The form runs down the left: **Work title** and **Your work reference**, then five sections that fold. Each section's label names it and says in one line what it holds, for example "2 writers: Ada Lovelace, Grace Hopper" or **None added yet**, so a work reads as a short list until you open the part you need. - **Writers** and **Publishers**: [Writers, publishers and shares](https://trackforge.studio/docs/workspace/catalogue/shares). - **Recordings**: [Recordings](https://trackforge.studio/docs/workspace/catalogue/recordings). - **Work details every society needs**: the boxes below. Its line gives the ISWC and the language, or **No ISWC yet** and **Language not set**. - **Alternative titles, performers and lyrics**: [Additional details](https://trackforge.studio/docs/workspace/catalogue/additional-details) and [Lyrics and LyricFind](https://trackforge.studio/docs/workspace/catalogue/lyrics). Its line reads **Optional** until it holds something. A section starts open when it has nothing in it yet, and a section the **To do** list points into opens by itself, so no problem sits behind a closed fold. Press a section's label to open or close it. On the right, or above the form on a narrow screen, **To do** lists what is missing and each society's status. A badge on the bar, a number followed by **to do**, jumps to it. The buttons that begin **Save and go to**, and **Save and finish**, save and then open the next section and put the cursor in it. ![The work editor with the save bar at the top, the boxes for title and reference, the folded sections with their one-line summaries and the To do panel.](https://trackforge.studio/docs/img/workspace/editor.png) ### The boxes on this page - **Your work reference**: 1 to 14 letters, digits or other printable characters, without accents or spaces at the start or end. - **Work identifier (ISWC)**: it looks like T-123.456.789-4. TrackForge sets the dots and hyphens when you leave the box. A last digit that does not fit is flagged, but the work still saves. See [the ISWC problem](https://trackforge.studio/docs/cwr/problems-and-fixes#iswc-format). - **Language**: choose by name. **Most used** comes first. - **Work duration (HHMMSS)**: six digits, so 000330 is 3 minutes 30 seconds. Minutes and seconds go up to 59 and it cannot be all zeros. - **Copyright date (YYYYMMDD)**: eight digits, such as 20200131, and a real date. - **Music and lyrics**: **Music and lyrics written together** for most songs, **Music only (instrumental)**, **Lyrics only** or **Music and lyrics written separately**. A CWR file you bring in keeps its value. A work saved before this box existed reads as written together, which is what its files said. - **Work version type**: **Original work**, or **Arrangement or adaptation of another work**, which bulk edit calls **Modified version**. - **Music in this version** and **Lyrics in this version** appear for a modified version. Societies reject a modified version without both. It also needs a writer credited for the change: give the arranger, adaptor or translator that role under Writers. See [the problem](https://trackforge.studio/docs/cwr/problems-and-fixes#modified-version-writer). Choosing **Original work** clears both boxes. ## If you leave without saving Each change is copied into a recovery copy kept in this browser for 24 hours after your last change. - Reopen the work and the editor says **Recovered unsaved changes from this browser. Review and save them to your catalogue.** In the list, that work's row shows **Unsaved browser edits available**. - Press **Save work** to keep the changes. Press **Discard recovered changes** to return to the saved version. That button goes once you change something more. - Closing the tab asks you to confirm first. Another browser or device has no copy. - If the page says **This browser could not keep a recovery copy. Keep this page open until your save succeeds.**, you cannot leave until the save works. ## Keyboard shortcuts - Ctrl+S, or ⌘S on a Mac, saves from anywhere in the editor. - Escape closes the directory window that **Choose writer from directory** opens. ## If something goes wrong - ****Not saved — retry**.** Your edits are still on the page. Press **Save work** again. - **Someone saved a newer version.** A window headed **A newer version was saved** opens over the editor, with a table of the fields that differ. Your edits are kept, and nothing is saved until you choose. **Review my edits over this version** applies them to the newer version, unsaved, for you to check. Where you both changed a field, choose which value to keep first. **Use saved version** drops your edits. **Decide later** closes the window, and **Compare and choose** on the notice in the editor opens it again. ## Related - [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems) - [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/edit-a-work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work)* --- ## docs/workspace/catalogue/shares.md # Writers, publishers and shares > Add writers and publishers to a work, set each right's shares so they total 100%, and correct a name across your saved works. Use the **Writers** and **Publishers** parts of the work editor to say who wrote a work, who publishes it and how each right is split. ## Add a writer 1. Press **Add writer**. A row opens. 2. Type the first and last name. 3. Type the [IPI](https://trackforge.studio/docs/cwr/glossary#ipi): 9 to 11 digits, no spaces or punctuation, leading zeros kept. Leave it blank if unknown. If the last two digits do not fit, the box warns, but the work still saves. See [the IPI problem](https://trackforge.studio/docs/cwr/problems-and-fixes#ipi-invalid). 4. Choose a role: **Composer (music)** ([composer](https://trackforge.studio/docs/cwr/glossary#writer_designation_c)), **Lyricist (words)** ([author](https://trackforge.studio/docs/cwr/glossary#writer_designation_a)) or **Music and lyrics** ([both](https://trackforge.studio/docs/cwr/glossary#writer_designation_ca)). 5. Enter the shares (below). Choose **Controlled by your company** if you represent this writer. "Your company" is the publisher sending the file. See [controlled](https://trackforge.studio/docs/cwr/glossary#controlled). 6. Under **Society details**, choose the society for each right the writer holds. ![The Writers part of the work editor with one writer open, showing the boxes for name, role, IPI, shares and control.](https://trackforge.studio/docs/img/workspace/writers-publishers.png) ## Add a publisher 1. Press **Add original publisher**. If you saved publisher details in **Workspace settings**, the row starts as that publisher. Type over it for another. 2. Fill in the name, IPI, control and shares. The role starts as **Original Publisher**. 3. On that row, press **Add administrator** or **Add sub-publisher**. Each starts with zero ownership shares and joins the original publisher in one **Publishing arrangement**. The roles: - **Original Publisher** ([original publisher](https://trackforge.studio/docs/cwr/glossary#publisher_type_e)): signed the writer and owns the rights. - **Acquirer**: bought the rights from the original publisher. - **Publishing Administrator** ([administrator](https://trackforge.studio/docs/cwr/glossary#publisher_type_am)): runs the rights for the owner. - **Sub-Publisher** ([sub-publisher](https://trackforge.studio/docs/cwr/glossary#publisher_type_se)): represents the original publisher in other countries. - **Substituted Publisher**: stands in for a sub-publisher in a territory. - **Income Participant**: receives income without owning or running it. The last four hold no ownership share. ### A publisher you control with no IPI Societies match a publisher by its IPI, so a publisher you control needs one on every work. Under the IPI box of a publisher marked **Controlled by your company**, the editor says what your other saved works and your Workspace settings give that publisher: - ****IPI found on your other works****, when the box is blank and the same name has one IPI elsewhere. The note says where it is known from, for example "on 22 works and in Workspace settings". **Use this IPI** fills the box on this work. When other saved works also lack it, the button that begins **Fill it in on all** and counts those works writes the IPI onto every one of them, leaving each work's spelling of the name as it is; save this work first, because that button reviews saved works. - ****Different IPIs for one publisher****, when your saved works give one name two or more IPIs. The note lists them and where each is used. One of them is probably wrong: check which is right before you fill in or correct any of them. The same problems are counted in **To do** and in a file's checks. See [a controlled publisher without an IPI](https://trackforge.studio/docs/cwr/problems-and-fixes#controlled-publisher-without-ipi) and [one publisher with different IPIs](https://trackforge.studio/docs/cwr/problems-and-fixes#controlled-publisher-ipis-differ). ## Shares Each row has three share boxes, for performing, mechanical and synchronisation rights. Type 0 to 100, as 50 or 50%. Leave a box blank if you do not know it yet; type 0 if the party has none. See [shares](https://trackforge.studio/docs/cwr/glossary#shares). - Each right is totalled on its own, across every writer and publisher on the work, and must come to exactly 100%. - For performing rights, the writers together hold 0% or at least 49.94%, and the publishers together no more than 50.06%. - Use no more than two decimal places. A file carries two, so shares that look like 100% can miss it. Use figures such as 33.33, 33.33 and 33.34. ## What you will see when they do not total The rows concerned are marked **To do**. In the **To do** panel, **Ownership shares need attention** names each problem: a right totalling 90% when it needs 100%, a share that is not a number, or a blank share. Its **Go to** links take you to the boxes. You can still save. See [the shares problem](https://trackforge.studio/docs/cwr/problems-and-fixes#shares-total). When two decimals are the cause, **Round to two decimals** lists the new figures first, and **Apply these shares** changes the form, not the saved work. ## Territories, people and corrections - **Writer territory details** and, for a publisher, **Agreement and territory details** take territories. **Coverage** is **Include** or **Exclude**, and excluded territories are sent with zero collection shares. - **Choose writer from directory** (or **Choose publisher from directory**) copies a saved person's name, IPI and societies onto this work. Shares, roles, control and territories stay as they are. - **Correct this writer in saved works** (or **Correct this publisher in saved works**) appears once the person has an IPI or party ID, and is off while the work has unsaved changes. Choose **This work only**, or every matching saved work. ## Related - [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems) - [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/shares](https://trackforge.studio/docs/workspace/catalogue/shares)* --- ## docs/workspace/catalogue/recordings.md # Recordings > Add the recordings of a work with their ISRC, label, release date and duration, and fix the formats the editor asks for. A work can have many recordings. Add one row for each, with whatever you know about it. Societies use recordings to match plays to the work, so they are worth adding, but a file does not need them. ## One work, several ISRCs A song is one work, however many recordings it has. An ISRC identifies one recording, so a song with two ISRCs is one work with two recordings. For example, a song recorded with ISRC AOA4Y2600105 and again with ISRC USL4R2557287 is one work. Open it, add a recording for each ISRC, and save. Do not add a second work for the second ISRC: that registers the same song twice. Each recording is sent with its work in the CWR file, so societies can match plays of any of them to that one work. There is no limit on how many recordings a work can have. Importing a spreadsheet? A cell can list several ISRCs, or each recording can have its own row with the same work reference. See [A work with several recordings](https://trackforge.studio/docs/workspace/add-works/spreadsheet#a-work-with-several-recordings). ## Steps 1. In the work editor, find the card **Recordings (ISRCs)** and press **Add recording**. A card headed **Recording** and a number appears. The button **Save and go to recordings** saves the work and takes you there. 2. Type the [ISRC](https://trackforge.studio/docs/cwr/glossary#isrc_recording): 12 characters, such as GBAAA2600001. It is a two-letter country code, three letters or digits, then seven digits. 3. Fill in the label, album title and catalogue number if you have them. 4. Open **Release date and duration** and fill in what you know, in the formats below. The release EAN/UPC is in the same place: type the 13-digit EAN or the 12-digit UPC, which is kept with a leading 0. 5. Press **Save work**. For each further recording, press **Add recording** again. A second card, **Recording** 2, appears below the first. To take a recording off the work, press its **Remove recording** button, then save. ## Add a recording from the list Owners and editors can add one recording to a work without opening it. 1. In **Catalogue**, set the **Recordings** filter to **No recording listed**. Choosing **No recording listed** on the **Recordings** chart above the list does the same. See [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find). 2. Press **Add a recording** on the work's row. A window headed **Add a recording** opens, with the same boxes as the editor. 3. Fill in what you know and press **Save recording**. It stays off while every box is empty or a value is mistyped. The window closes and a note reads **Recording added to** and the work's title. The window adds one recording to a work that has none. To add a second ISRC or more, or change this one, open the work. ## The two formats | Box | Type | Example | |---|---|---| | Release date | Eight digits, year first: YYYYMMDD. It must be a real date. | 20260910 is 10 September 2026 | | Duration | Six digits for hours, minutes and seconds: HHMMSS. Minutes and seconds go up to 59. | 000330 is 3 minutes 30 seconds | The boxes are labelled **release date (YYYYMMDD)** and **duration (HHMMSS)**. Leave a box blank if you do not know it. A recording's duration is separate from the work's own duration, which is in [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work). ![A recording in the work editor with Release date and duration open, showing the boxes for the release date and the duration.](https://trackforge.studio/docs/img/workspace/recordings.png) ## What you will see - A row with nothing in it reads **Nothing is filled in for recording** and a number, and is left out when you save. - **Release date and duration** opens by itself when either value needs fixing, with the message under the box. - A work with no ISWC, or no recording with an ISRC, gets a reminder in its **To do** panel that societies use these to match plays. It is a reminder only and is not counted as a problem. ## If something goes wrong - **The ISRC looks mistyped.** Check it against your label or distributor, or clear the box. See [the ISRC problem](https://trackforge.studio/docs/cwr/problems-and-fixes#recording-isrc-invalid). An ISRC box holds one ISRC: put a second ISRC in a recording of its own. - **The same song is in the catalogue twice, once for each ISRC.** Add the second work's recordings to the first work and save, then delete the second work. See [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many#link-delete-or-prepare). Deleting it in the Workspace does not change what a society already holds. - **The release date is not a date.** Use eight digits, with a real month and day. 30 February is not a date. - **The duration is not a duration.** Use six digits, so 3 minutes 30 seconds is 000330. Minutes and seconds go up to 59. - **The window says the work was changed after the list was loaded.** Nothing was saved. Close the window, reload the list and add the recording again. - **The label or album title has letters a CWR file cannot carry.** Enter it in Latin letters. See [the label problem](https://trackforge.studio/docs/cwr/problems-and-fixes#recording-label-letters-unrepresentable) and [the album title problem](https://trackforge.studio/docs/cwr/problems-and-fixes#album-title-letters-unrepresentable). ## Related - [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work) - [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems) - [Additional details](https://trackforge.studio/docs/workspace/catalogue/additional-details) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/recordings](https://trackforge.studio/docs/workspace/catalogue/recordings)* --- ## docs/workspace/catalogue/additional-details.md # Additional details > Add alternative titles and performers to a work, read the US Copyright Office panel, and see society work IDs you have confirmed. Alternative titles and performers help a society recognise the work. In the work editor they are in the last section, **Alternative titles, performers and lyrics**, which starts folded and whose label reads **Optional** until it holds something: press the label to open it. Next to them sit a panel that reads US Copyright Office records and a list of society work IDs you have confirmed. ## Add alternative titles 1. In the work editor, open **Alternative titles, performers and lyrics**, find **Alternative titles** and press **Add title**. 2. Type the title. 3. In **What kind of title**, choose **Alternative title**, **Original title (before a translation)** or **Extra search title (for example a common misspelling)**. 4. In **Title language**, choose the language by name. 5. Press **Save work**. To drop one, press **Remove title** and a number. ## Add performers 1. Find **Performers** and press **Add performer**. 2. Type the first name, and the **last name or group name**. A band goes in the second box. 3. If you know them, open **Performer identifiers (optional)** for the IPI number and the IPI base number. The base number starts with I-, for example I-000000229-7. See [the IPI base number problem](https://trackforge.studio/docs/cwr/problems-and-fixes#ipi-base-number). 4. Press **Save work**. Titles and names go into a CWR file in Latin letters. If one holds other scripts, enter its romanised form. See [the alternative title problem](https://trackforge.studio/docs/cwr/problems-and-fixes#alternate-title-letters-unrepresentable) and [the performer problem](https://trackforge.studio/docs/cwr/problems-and-fixes#performer-name-letters-unrepresentable). ## The US Copyright Office panel The panel, **US Copyright Office**, sits with the status panels beside the form. It appears once the work has a title and at least one writer or publisher with a name, and it follows your edits before you save them. **What it does.** It looks for US records that name the same title and one of the work's writers or publishers. Its fold, **US Copyright Office records** and a date, lists each registration or document found, with a link to the official record and a **Copy number** button for the number to search for. A record that deserves a second look is marked **Worth a look**, and the fold opens by itself. Cases include a claimant who is not on your work, a different list of writers, a recorded document about the song and a termination notice. If nothing is found, a line says so. **What it does not do.** It does not change the work, fill in any box, add to your **To do** count or stop you saving. It matches by title and names, because these records carry no ISWC or ISRC, so a match is a lead and not a proof. It is not the official record, and the panel says so. No record does not mean the work is unregistered, since registration in the US is voluntary. If a list is longer than it can check, a line says how many it used. If the check cannot run, the panel says so in one line with **Try again**. Your work is not affected. The same check is offered when you prepare a file. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). ![The Alternative titles and Performers parts of the work editor, each holding one entry.](https://trackforge.studio/docs/img/workspace/editor-extras.png) ## Confirmed society work IDs **Confirmed society work IDs** appears only when a registration file you supplied gave this work a society's ID. It lists the society, the ID, and the file it came from. **View identifier source** opens that file's record. If the list cannot load, press **Retry identifiers**. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). ## Related - [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work) - [Recordings](https://trackforge.studio/docs/workspace/catalogue/recordings) - [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/additional-details](https://trackforge.studio/docs/workspace/catalogue/additional-details)* --- ## docs/workspace/catalogue/lyrics.md # Lyrics and LyricFind > Keep each work's lyrics in the Workspace and make LyricFind's lyrics file from them. Lyrics are never put in a CWR file. The Workspace can keep each work's lyrics and make [LyricFind](https://www.lyricfind.com)'s lyrics file from them. CWR has no place for lyric text, so lyrics are never put in a CWR file. Your CWR file already gives LyricFind who wrote and publishes each work. The lyrics file adds the words. Lyrics are kept beside the work, not in it. Saving or removing them does not change the work's version. It also leaves the work's status with each society, and any file you have prepared, as they are. ## Add lyrics to one work 1. Open the work. Lyrics are added to a work after it is saved, so save a new work first. 2. Open the editor's last section, **Alternative titles, performers and lyrics**, and find the card **Lyrics, for LyricFind (optional)**, below the performers. It is folded shut, and its header says whether lyrics are saved. Press **Show or edit lyrics** to open it. 3. Type or paste the lyrics, one line of the song per line. 4. Choose a **Lyrics language (optional)** only if the lyrics are in a different language from the work. Left as **Same as the work**, the work's own language is used. 5. Press **Save lyrics**. **Remove lyrics** deletes them. If you leave the work with lyrics typed but not saved, the Workspace asks before it lets you go. LyricFind accepts up to 32,767 characters of lyrics for a song. If someone else saved the work's lyrics after you opened it, saving is refused: reload the page and try again. ## Add lyrics from a spreadsheet A spreadsheet can carry lyrics in a column of its own. The CWR Workbench's template has one when you tick **Include a Lyrics column** as you download it. - The Workspace suggests **Lyrics (for LyricFind, never in the CWR file)** for a column named Lyrics. Check the suggestion as usual. See [Import a spreadsheet](https://trackforge.studio/docs/workspace/add-works/spreadsheet). - A work's lyrics come from the first of its rows that has any. Another row of the same work with different lyrics is an error to fix in the sheet. Repeating the same lyrics is fine. - The preview says whether the import adds, changes or removes a work's lyrics, with the number of lines. It does not show the words. A change to the lyrics alone saves no new version of the work. - An empty Lyrics cell leaves saved lyrics as they are, unless you choose that empty cells remove saved values. - To add lyrics to works you already have, import a sheet with your work reference and a Lyrics column. The rows match your saved works by reference. - The import keeps a record of the sheet you uploaded, lyrics included, as it does for every other column. Removing a work's lyrics later does not change that record. - If someone changes a work's lyrics between the preview and saving, saving stops and asks you to preview the import again. ## Make the LyricFind lyrics file 1. In the list of works, tick the works. See [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many). 2. Press **Make LyricFind lyrics file**. 3. If LyricFind already has these songs, tick **These songs are updates to songs LyricFind already has**. 4. Press the button that begins **Make the file for**. 5. Type the client name and password of the LyricFind account you send lyrics to in **LyricFind client name** and **LyricFind password**. They go into the file's clientName and password as it downloads. TrackForge does not keep them. Leave them blank to add them to the file yourself. 6. Download the lyric-1.2 file, then upload it to LyricFind. For one work, open the work and press **Make LyricFind file for this work** on its lyrics card. The button shows once lyrics are saved, with the card folded or open. The same dialog opens for that work alone: carry on from step 3. If you have typed changes to the lyrics, save them first, because the file is made from the saved lyrics. Each work's reference becomes its SongID, the same reference your CWR file gives LyricFind. LyricFind also needs the work's title, at least one performer and a language. Writers, ISWC, ISRCs, duration and the first recording's album go in when the work has them. The review list has three parts, which you can also download as a spreadsheet with **Download review list (CSV)**: - **Not in the file yet.** One numbered line for each work left out, saying what to add, for example "Add lyrics and a performer." **Open work** takes you to the work. Add what it is missing, then make the file again. - **Please check: included in the file.** A value was left out or read in a particular way. For example, when a work has several performers the first one is taken as the main artist. - **About the whole file.** How the works were read. The file is made when you ask for it and is not kept. Making it does not send anything to LyricFind. ## What LyricFind's other file needs LyricFind's ownership-1.4 file carries ownership and lyrics together. It needs LyricFind's own number for each publisher, so the Workspace does not make it yet. The CWR Workbench's [LyricFind converter](https://trackforge.studio/cwr-tool/lyricfind) makes it from LyricFind's spreadsheet. ## Related - [Import a spreadsheet](https://trackforge.studio/docs/workspace/add-works/spreadsheet) - [Bring in a draft from the Workbench](https://trackforge.studio/docs/workspace/add-works/from-the-workbench) - [Your data](https://trackforge.studio/docs/workspace/help/your-data) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/lyrics](https://trackforge.studio/docs/workspace/catalogue/lyrics)* --- ## docs/workspace/catalogue/edit-many.md # Edit many works at once > Tick works, then change the same detail on all of them, link them to another catalogue, delete them or start one file from them. Tick works in the list and act on them together. Owners and editors can change the same detail on all of them, link them to another catalogue, delete them or start a file from them. With view-only access the tick boxes and buttons are not there. ## Tick the works Above the list, the heading reads **Tick works to edit, link or delete them together** until you tick one, then it counts them. The buttons stay switched off until a work is ticked. - Tick works one at a time, or press **Select all works on this page**. The button that begins **Select all** or **Select the first** picks works matching your filters. **Clear selection** empties it. - Ticks stay while you search, filter or change page. They use saved versions, so save any browser edits first. A work saved since shows **Changed since selection**; tick it again. - You can edit, link or delete 200 works at a time. Past that the screen says **Select 200 works or fewer for editing or linking.** ## Change the same detail on many works 1. Press **Edit selected works**. 2. Under **What to change**, choose **Work details**, **Writer control by identifier** or **Publisher control by identifier**. 3. For work details, choose **Which detail**: **Language**, **Musical category** or **Work version type**. Then choose the new value. The version types are **Original work** and **Modified version**, which the editor words as **Arrangement or adaptation of another work**. They are the same choice. **Modified version** also asks for **Music in this version** and **Lyrics in this version**, and the preview waits for both. A modified version needs a writer credited for the change too, so the screen counts the works that have none: add that writer in each of them. Any other version type clears both details. 4. For control, choose **Match party by**: **IPI** or **Your own party reference**. Type the existing value, then choose the **New control state**. Only that party's [control](https://trackforge.studio/docs/cwr/glossary#controlled) changes. Names, shares, roles, societies, territories and agreements stay as they are. 5. Press **Preview changes to** and the number of works. Nothing is saved yet. A table shows each work before and after, with lists of **Skipped works** and **Conflicted works**. 6. For control changes, tick **I confirm the reviewed control changes for these exact writers or publishers.** 7. Press **Apply to** and the number. Each changed work gets a new saved version. **Change review** takes you back without saving. ![The preview of an edit to many works, with a table showing one work's language before and after, and the button Apply to 1 work.](https://trackforge.studio/docs/img/workspace/edit-many.png) The result says how many works changed. A work edited elsewhere since you opened this is not changed, and **Review current versions** reloads it so you can try again. **Done** closes the editor. **Prepare these** starts a file from the same works. You can also arrive here from a problem. In the catalogue panel **What is holding your works up**, a button such as **Set the language for** opens this editor with the works ticked and the detail chosen. See [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). ## Link, delete or prepare - **Link.** Under **Link to catalogue** choose a catalogue, then press **Link selected works**. No copies are made. See [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues). - **Delete.** **Delete selected works** opens **Confirm deletion**, which names the works. They leave every catalogue and stop counting towards your limit. Files you prepared or sent keep their record. See [History, undo and deleted works](https://trackforge.studio/docs/workspace/catalogue/history). - **Prepare.** **Prepare selected works** starts a file from your ticks. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). - **LyricFind.** **Make LyricFind lyrics file** makes LyricFind's lyrics file from the lyrics of the ticked works. See [Lyrics and LyricFind](https://trackforge.studio/docs/workspace/catalogue/lyrics). ## If something goes wrong - **Nothing opens, and the works are unticked.** They changed since you ticked them. Tick them again. - **Some works could not be linked.** The screen lists them and says retrying is safe. ## Related - [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/edit-many](https://trackforge.studio/docs/workspace/catalogue/edit-many)* --- ## docs/workspace/catalogue/fix-problems.md # Fix problems on a work > Read what is holding a work back, go straight to the field to fix, and fix one cause across many works or a problem a society sent back. A work waits when it lacks something a society needs in a file. TrackForge lists what is missing, takes you to the box and explains why. ## Where problems are listed - **On the work.** The **To do** panel sits beside the form, or above it on a narrow screen. Its count is only what stops a file. - **Across the catalogue.** Press **Needs information (any society)**, or **Fix what is missing** on **Today**. The panel **What is holding your works up** appears above the list, with one entry for each cause. The status is **Needs information**. A work's row says **Details missing**, **Today** says **Fix what is missing**, and the panel says **What is holding your works up**. They are the same thing. See [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses). ## Fix one work 1. Open the work. Pressing **Details missing** on its row lands you on **To do**. 2. Read each card headed **Needed before you can prepare a file**. It says what is wrong and what to do. 3. Press the link below the card that begins **Go to** and names the field. The section it is in opens if it was folded, and the cursor lands in the box. A cause in Workspace settings, such as your sender details, has **Open Workspace settings** too. 4. Press **What this means** for a fuller explanation, in a new tab. Not every problem has one. 5. Change the value and press **Save work**. TrackForge checks it again and the count falls. To check changes before saving, or a new work you have not saved yet, use **Check current edits**. If a check could not run, press **Check again**. When nothing is left the panel reads **Nothing to do for the saved version.** ![The To do panel of a work, with a card headed Needed before you can prepare a file, its What this means link and the Go to links for the boxes to change.](https://trackforge.studio/docs/img/workspace/fix-problems.png) ## Needed, worth checking and details to confirm - **Needed** cards stop a file, and are counted. - **Worth checking** cards are folded and never stop a file. - **Details to confirm** are values that may have been filled in for you. They do not stop a file. Check them, then press **This value is right** (or **These values are right**). Changing a value and saving also confirms it. ## Fix one cause across many works Each entry in **What is holding your works up** says how many works it holds up and which societies need it. The fold **Why it matters, and how to fix it** and the link **What this means** explain it. Owners and editors get buttons that settle it: - **Add your publisher details** or **Review your societies** open Workspace settings. - A button that begins **Set the language for**, with twins for the musical category and version type, opens bulk edit with those works ticked. See [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many). Anyone can press **Open the first:** to open the first work, or **Show the** works to list them. ## When a society sent a work back Open a rejected work from its response and a panel at the top is headed **Correcting revision for** and the society's name. It gives the society's reason and a button such as **Go to the writers**. The panel has no **What this means** link; the same problem's card in **To do** does. **To do** leads with a card for that society, headed **Needs correction**. Fix the work and press **Save work**. The bar then reads **Your correction is saved. Next: prepare the replacement file.** and offers **Prepare the replacement**. There is no button to send the file again: you prepare a new file and send it, from the Workspace through a society connection or yourself, recording the send. See [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response) and [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again). ## Related - [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work) - [Problems and fixes](https://trackforge.studio/docs/cwr/problems-and-fixes) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/fix-problems](https://trackforge.studio/docs/workspace/catalogue/fix-problems)* --- ## docs/workspace/catalogue/statuses.md # What the statuses mean > Tell prepared, sent and accepted apart, read the status on each work for each society, and see what moves a work to the next status. Each work has a status for every society you register with. It says where the work has got to with that society and what, if anything, you do next. One work can be **Accepted** by one society and **Ready** for another. ## Prepared, sent and accepted These three words mark three different moments. - **Prepared** means TrackForge has built a file. It is ready to download and nothing has gone to the society. The status reads **Prepared — not sent**. - **Sent** means you sent the file to the society yourself, outside TrackForge, and recorded the send. The status then reads **Awaiting response**. No status is called Sent; the work's **Timeline** has a line **Sent**. - **Accepted** means the society's response says it accepted the version you sent, and you have uploaded that response. The status reads **Accepted**. It is not proof of collection. TrackForge sends nothing to a society unless you ask it to. You move a work along: you prepare the file, send it (from the Workspace through a society connection, or by downloading it), record that you sent it if you sent it yourself, and upload the society's response. There is no button to send a file again. When a society rejects a work, you fix it, save it, prepare a new file, send it and record the send again. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send), [Upload a response](https://trackforge.studio/docs/workspace/files/upload-a-response) and [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again). TrackForge moves a work on its own only through the first four statuses in the table: it checks the saved version again after each save. The main statuses of one work with one society, and what moves the work from each to the next. TrackForge does the checking; every other move is yours. Accepted with changes sits with Accepted. The main statuses of one work with one society and the moves between them, as the text above describes. ```d2 direction: down checking: Checking… needs-info: Needs information ready: Ready prepared: Prepared — not sent awaiting: Awaiting response said: "What the\nsociety said" accepted: Accepted correction: Needs correction review: "Conflict or\nResponse needs review" checking -> needs-info checking -> ready needs-info -> checking: You fix and save ready -> prepared: You prepare a file prepared -> awaiting: "You send it and\nrecord the send" awaiting -> said: "You upload\nthe response" said -> accepted said -> correction said -> review correction -> awaiting: "You fix, save,\nprepare a new file,\nsend and record" ``` ## Every status | Status | What it means | What you do | |---|---|---| | **Checking…** | TrackForge is checking the latest saved version against this society's rules. | Wait. If it seems stuck, press **Refresh**. | | **Needs information** | Checks found details to add before a file can be prepared for this society. | Open the work's **To do**. See [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). | | **Couldn't check** | The check could not run. | Press **Check again** in the work's **To do**, or try the checks again from Workspace settings. | | **Ready** | The work passes the checks available for this society. | Prepare a file. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). | | **No TrackForge history** | Nothing was prepared or sent from TrackForge for this society. The work may already be registered elsewhere. | Nothing. It says only that TrackForge holds no record; it is not **Accepted**. | | **Prepared — not sent** | Your file is built and ready to download. Nothing has been sent. | Send it from the Workspace through a society connection, or download it, send it yourself and record the send. | | **Awaiting response** | A send is recorded and no response has been matched yet. Hover over it to see when you sent the file and how many days ago. | When the society replies, upload its response. | | **Accepted** | The society accepted the version you submitted. | Nothing. If you change the work later, **Changed since submission** appears. | | **Accepted with changes** | Accepted, with changes made by the society for you to review. | Open the response and review them. | | **Needs correction** | The society rejected the work or asked for a correction. | Fix the work. See [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again). | | **Conflict** | The society reported a conflicting claim or registration. | Open the response. See [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response). | | **Response needs review** | The society sent a response TrackForge cannot classify, such as a duplicate, a society not taking part, or one work number given to two works. | Open the response to see why. | | **File you supplied** | A registration file you uploaded. It is not a society response. | Press **Review supplied history**. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). | | **Status unavailable** | This page does not recognise the status. | Refresh the page. | **Needs information** has other names on other screens: a row in the list says **Details missing**, **Today** says **Fix what is missing**, and the panel above a filtered list says **What is holding your works up**. They are the same thing. Two notes can sit under a status. **Changed since submission** means the saved work changed after the version the society has. **Registration differs from catalogue** means the registration is not the same as your catalogue; **Review the difference** opens the comparison on the work. Until you choose your societies, a work shows one summary instead of a status, such as **Not checked yet — choose your societies**. See [Societies](https://trackforge.studio/docs/workspace/settings/societies). ## Where you see a status - **In the list.** On a wide screen each society has a column, with short words: **No history**, **Awaiting** and **Review response**. A work with nothing prepared or sent for a society shows **No history** in that column even while it still needs information; the **Your details** column says **Details missing** instead. On a phone the list is a set of cards: each society shows as its name and its status in full, and a society with no TrackForge history is left out. Hover over a status, or focus or press it, to read the society, the status and the evidence behind it. - **On a work.** The **Status** panel has one row per society, with a link beside it to the next step, such as **Review prepared file**, **Open delivery record**, **Review response** or **See To do**. Societies with nothing prepared or sent and the same status share one row. The **Timeline** fold lists, newest first, **File prepared**, **Sent**, **Response received**, **History supplied** and **Correction saved**. - **After a rejection is fixed.** The panel reads **Correction saved, not sent yet**, with **Prepare the replacement**. Once the replacement is prepared it reads **Replacement prepared, not recorded as sent**, with **Open the replacement file**. The society still holds the rejected version. ![The Status panel of a work, with one row for the societies where the work is ready and one for PRS, where a file is prepared and not sent.](https://trackforge.studio/docs/img/workspace/status-panel.png) ## Find works by status Choose a **Society**, then **Status**. Each choice holds more than one status: - **Needs your information**: **Needs information**. - **Not checked yet**: **Checking…** and **Couldn't check**. - **Ready to prepare**: **Ready**. - **With the society**: **Prepared — not sent** and **Awaiting response**. A work here may not have been sent. - **Accepted**: **Accepted** and **Accepted with changes**. - **Needs correction or review**: **Needs correction**, **Conflict** and **Response needs review**. - **No TrackForge history**: **No TrackForge history**. See [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find). ## Related - [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems) - [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare) - [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/statuses](https://trackforge.studio/docs/workspace/catalogue/statuses)* --- ## docs/workspace/catalogue/history.md # History, undo and deleted works > See the saved versions of a work, restore an earlier one, undo an import, and find or restore works you have deleted. Every save of a work is kept as a version, and nothing is overwritten. Use the versions to see what changed and to go back. You can also undo an import and bring back works you deleted. ## See the saved versions 1. Open a saved work in the editor. 2. Below the form, press **View saved versions**. 3. **Saved versions** lists them, newest first, as **Version** and a number with the title and the time. Each says what changed since the one before, such as a title, or a count of writers going from one to two. A save with no changes says so. A fold, **Exact saved data for version**, holds everything in that version. ![The Saved versions list of a work, with version 2 above version 1 and a Restore version 1 button.](https://trackforge.studio/docs/img/workspace/saved-versions.png) There is no button that undoes a single edit once it is saved. To go back, restore an earlier version. Edits you have not saved are kept in a recovery copy. See [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work). Prepared files and responses keep their own history. See [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses). ## Restore an earlier version 1. In **Saved versions**, press **Restore version** and a number on an older version. Owners and editors only. It stays switched off while you have unsaved changes, a save is running or a newer version conflicts. 2. The window **Restore version** and the number asks you to confirm. It explains that the saved information is copied into a new version, and that the current version and every earlier one stay in history. 3. Press **Restore version** and the number **as a new version**, or **Keep current version** to stop. The bar then says **Restored version** and the new version number. ## Undo an import Open the import from **Saved imports**. If it added works, the panel **Undo this import** says how many. Press it and confirm in **Confirm undo**. It deletes the works the import added. Changes it made to works you already had stay, and each work's history shows them. See [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review). ## Find and restore deleted works Deleting a work, from the list or by undoing an import, takes it out of every catalogue and stops it counting towards your limit. Files you prepared or sent before keep their record. See [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many). Deleted works are reached only from All catalogues. They are not listed inside a single catalogue. 1. In the catalogue chooser at the top of **Catalogue**, pick **All catalogues**. 2. Scroll below the list to **Deleted works**, which shows a count, and open it. It appears only once you have deleted something. 3. Press **Restore** beside a work. For several, tick them, or tick **Select all**, then press the **Restore** button above the list, which counts the works you ticked. A restored work returns to your catalogues and counts towards your limit again. Each entry shows the day it was deleted. The first page holds the most recent; **Show more** loads the rest. Works restore 200 at a time. If a restore fails, the screen gives the reason, and for more than 200 works it also says how many were restored. If you can only look, the list has no restore buttons. ## Related - [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues) - [Add your works](https://trackforge.studio/docs/workspace/add-works/) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/history](https://trackforge.studio/docs/workspace/catalogue/history)* --- ## docs/workspace/catalogue/several-catalogues.md # Several catalogues > Keep more than one catalogue, switch between them, see every work once in All catalogues and link works into another catalogue. A catalogue is a named group of works in your workspace. Keep more than one when you want to work on a group of works on its own: each catalogue has its own list, search, filters and list of what is holding its works up. A work can belong to several catalogues without being copied. ## Create another catalogue You need to be an owner or editor. 1. Beside the catalogue chooser, press **Create another catalogue**. 2. Type a name in **New catalogue name**. 3. Press **Create catalogue**. The new catalogue opens. A workspace with none shows **Create your first catalogue, then import a spreadsheet or add a work.** A name is set when you create the catalogue. The Workspace has no screen for renaming it, so choose it with care. ## Switch catalogue Open the chooser, which starts with **Choose a catalogue**, and pick a catalogue by name. It opens on **Today**. The Workspace remembers the last catalogue you used, for each workspace, in this browser. Each catalogue keeps its own search and filters. They do not follow you to another catalogue. The chooser is switched off while an action such as a save, a bulk edit or a delete is running. If the catalogue list did not load, press **Reload catalogues**. ## See every work once Choose **All catalogues** in the chooser. It appears once you have a catalogue. The page says each saved work appears once, with every catalogue it belongs to, and that links share the same saved work. The column **Catalogues** names them. The list searches, filters and sorts as a catalogue's does. See [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find). Opening a work opens it in the first catalogue it belongs to. ![All catalogues, with the Catalogues column naming the two catalogues a work belongs to and the Deleted works fold below the list.](https://trackforge.studio/docs/img/workspace/several-catalogues.png) ## Link works into another catalogue 1. Tick the works, in a catalogue or in All catalogues. 2. Under **Link to catalogue**, choose the catalogue. 3. Press **Link selected works**. The screen says how many were linked and that no copies were created. Existing links are kept. Because the link shares the same saved work, a change to the work shows in every catalogue it is in. See [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many). ## What you cannot do from All catalogues Edit, link and delete work as they do in a catalogue. These do not: - **Prepare a file.** There is no **Prepare selected works** button. Open a catalogue to prepare one. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). - **See the causes.** The panel **What is holding your works up** belongs to one catalogue. - **Import or add works.** Do that inside a catalogue. - **Open its own Today or files.** **All catalogues** has no pages of its own and no breadcrumb. The tab bar stays, with **Catalogue** selected; **Today**, **Files and responses** or **Registration health** opens that page of the catalogue you last used. To work in another catalogue, choose it in the chooser. **Workspace settings** is in the account menu. All catalogues is also the only place to find deleted works. See [History, undo and deleted works](https://trackforge.studio/docs/workspace/catalogue/history). ## Related - [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find) - [Add your works](https://trackforge.studio/docs/workspace/add-works/) --- *Source: [https://trackforge.studio/docs/workspace/catalogue/several-catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues)* --- ## docs/workspace/agreements.md # Agreements > Search, add and edit your agreements, and link works or one publishing arrangement to them. An agreement is a record of the facts of a publishing deal, kept once and reused across your workspace. Record it, then link the works it covers. Saving an agreement or a link does not change any work's rights, its agreement numbers or a prepared file. ## Open your agreements 1. Open **Catalogue** and press **Agreements**. 2. Search with **Find agreement**. The list shows each agreement's name and type, with a count. 3. Choose one to read it. If you can only look, you can read it and its links but not change them. ## Add or edit an agreement You need to be an owner or editor. 1. Press **Add agreement**, or choose an agreement to edit. The card reads **New agreement** or **Agreement · version** and a number. 2. Fill in **Agreement name**, which is needed to save. Choose an **Agreement type**: **Publishing**, **Administration**, **Sub-publishing** or **Other**. Add a **Start date** and **End date** if you know them. 3. Under **Parties**, press **Add agreement party** for each. Give a name, a role in your own words and, if you know it, the [IPI](https://trackforge.studio/docs/cwr/glossary#ipi): 9 to 11 digits, leading zeros kept. If the last two digits do not fit, the box warns but you can still save. 4. Under **Territories**, press **Add agreement territory** and type the name or expression your agreement uses. Tick **Exclude territory** for one the agreement leaves out. 5. Under **Society agreement numbers**, press **Add society number**, choose the society and enter its number. 6. Add anything else under **Agreement notes**. 7. Press **Save agreement**. The screen reads **Agreement saved. Existing work rights are unchanged.** If the save is refused, check that every party and territory has a name, that every society number has both a society and a number, and that the **End date** is not before the **Start date**. Fill in or remove the row, then save again. Each party, territory and number has a remove button. **Download…** on a saved agreement offers **Excel (.xlsx)**, **CSV (.zip)** and **JSON**. ![A saved agreement open for editing, with its name, type and dates, a party, a territory and a society agreement number.](https://trackforge.studio/docs/img/workspace/agreement.png) ## Link works to an agreement On a saved agreement, **Linked works and publishing arrangements** lists what it covers: the work's title and reference, **Whole work** or a publishing arrangement, and the version it was linked at. 1. In **Find a work to link**, search and press **Search workspace works**. 2. Choose a work from the matches. 3. In **Link applies to**, choose **Whole work** or one publishing arrangement. 4. Press **Link saved work**. To take a link off, press **Remove link to** beside it. The works are left alone. If an arrangement has since gone from the work, its link stays with a warning for you to review. Links are switched off while the agreement has unsaved changes. Save first. ## If you leave without saving An unsaved agreement is kept in this browser for 24 hours. When you come back, the screen says it recovered your draft. While changes are unsaved you cannot move to another part of the Workspace, and closing the tab asks you to confirm. Save, or press **Discard draft changes**. **Reload saved agreement (discard edits)** brings back the saved version. If the browser cannot keep a copy, the screen tells you to keep the page open and save before leaving. ## Related - [Writers, publishers and shares](https://trackforge.studio/docs/workspace/catalogue/shares) - [Societies](https://trackforge.studio/docs/workspace/settings/societies) --- *Source: [https://trackforge.studio/docs/workspace/agreements](https://trackforge.studio/docs/workspace/agreements)* --- ## docs/workspace/files/prepare.md # Prepare a file > Choose works and a society, check your publisher details and prepare a registration file that you then send yourself. Preparing builds a [CWR](https://trackforge.studio/docs/cwr/glossary#cwr) registration file from works you have saved, for the society you choose, and checks the works as it does. Preparing sends nothing to the society: you then send the file, from the Workspace through a [society connection](https://trackforge.studio/docs/workspace/settings/society-connections) or by downloading it and sending it yourself. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send). What a prepared file holds: for each work its title and identifiers, its writers, its publishers, the shares for each right and any recordings, together with your publisher details and the society the file is for. What a prepared file is built from, each leading into the file: - The work: title and identifiers - Its writers - Its publishers - Shares for each right, totalling 100% - Recordings, if any - Your publisher details - The society it is for ## Before you start - You must be an owner or editor. Save the works first: a file uses the saved version of each. - Add your publisher details and choose your societies in **Workspace settings**. The form copies them. See [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) and [Societies](https://trackforge.studio/docs/workspace/settings/societies). ## Steps 1. Open **Catalogue** and tick the works for the file. To put several in one file, search for each and tick it. 2. Press **Prepare selected works**. The page **Prepare a file** opens with the card **Prepare a CWR file**, in five numbered steps. The first, **Works included**, lists your works with the saved version of each. If you chose too many works, it says so. 3. **Who it goes to**. In **Who are you sending this file to?**, choose a society under **Your workspace societies**. If you do not know yet, choose **Not sure yet — general checks only**. A note says whether TrackForge checks that society's own rules or only the general CWR rules. If only the general rules, read the society's current guidance before you send. A society marked "unavailable" cannot be prepared yet: open the fold under the list, which begins "Why", to read the reason. AllTrack is listed once for each account, worldwide and US only, with the one saved in Workspace settings first: choose the account this file is for. The publisher details in step 5 follow the account, taking the publisher saved for it in Workspace settings. If you choose an account that has no publisher of its own, a warning above the publisher details says the file differs from your saved settings, because your works were checked against the saved account. In a file to AllTrack, TrackForge writes the account's territory for each publisher that covers all of it and leaves out a publisher that collects nothing there. The territories saved on your works do not change, so files for other societies stay as they are. 4. **What you are sending**. In **What are you preparing?**, choose **New registration with this recipient** for a work that society does not hold yet (a [new registration](https://trackforge.studio/docs/cwr/glossary#transaction_type_nwr)), or **Update an existing registration** for one you are changing (an [update](https://trackforge.studio/docs/cwr/glossary#transaction_type_rev)). A work may already be registered elsewhere even when TrackForge has no history for it. Choose an update for those. 5. **Your publisher details**. Check **Publisher name (as registered)**, **Publisher IPI number** and **Short code for your filenames**. They are filled in from Workspace settings, with the publisher you send as to the society you chose. If you choose another society, they change to its publisher unless you have edited them. Change them only if this file needs something different. For AllTrack, typing the IPI of the publisher saved for its other account switches the file to that account, and a line says so, because AllTrack reads the account from the publisher in the file's header. The code is the 2 or 3 letters your society gave you for naming files, not your [IPI](https://trackforge.studio/docs/cwr/glossary#ipi). 6. **Check and prepare**. A line above the button gives the name the file will get, starting "The file will be named". Its number follows on from the last file this workspace made this year for the same filename code and society code. To carry on from files you made before the Workspace, change **Start file numbers from** in [Workspace settings](https://trackforge.studio/docs/workspace/settings/publisher-details#file-settings) before you prepare. Press **Check and prepare file**. It stays off until you have chosen a society and a purpose and filled in all three publisher details. A line under it tells you if the society or the purpose is missing. If the button is still off, check the three publisher details in step 5. ![The Prepare a CWR file card, with the works included, the society the file goes to, what is being sent, the publisher details and the Check and prepare file button.](https://trackforge.studio/docs/img/workspace/prepare-file.png) ## What you will see If the checks pass, the file's page opens with **Your file is ready** and the file name, and a strip, **Where this file is**, with the stages **Prepared**, **Sent** and **Response**. Prepared is not sent. In the list of files and on Today, the badge reads **Prepared — not sent** until you have sent the file and recorded it. Next, [download, send and record it](https://trackforge.studio/docs/workspace/files/send). If a check fails, no file is made. The page says **Can't prepare yet** and lists each problem under **TrackForge’s checks on this file**, with what is wrong and how to fix it. - **Blocks file preparation** must be fixed. **Does not block preparation — review before proceeding** can be left. - **Fix this work** opens the work at the right place. **What this means** opens the explanation of that problem. - A note on accented letters says **Nothing to fix**. After you fix and save a work, press **Back to the file**, then **Prepare latest saved versions**. The form opens again with your earlier settings. ## If something goes wrong - **A work was saved again after you chose it.** Press **Use the latest saved versions** and the list shows the version that will go in the file. - **A problem on this list.** Three common ones are explained at [Publisher IPI number](https://trackforge.studio/docs/cwr/problems-and-fixes#sender-id), [publisher name](https://trackforge.studio/docs/cwr/problems-and-fixes#sender-name) and [shares that do not total 100%](https://trackforge.studio/docs/cwr/problems-and-fixes#shares-total). Those pages are shared with the Workbench, TrackForge's free public tool, so "Where to fix it" there names the Workbench. ## Related - [Download, send and record](https://trackforge.studio/docs/workspace/files/send) - [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems) - [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) --- *Source: [https://trackforge.studio/docs/workspace/files/prepare](https://trackforge.studio/docs/workspace/files/prepare)* --- ## docs/workspace/files/send.md # Download, send and record > Send your prepared file to the society from the Workspace, or download it, send it yourself and record who you sent it to, how and when. TrackForge never sends a file on its own: nothing reaches a society until you send it. Once a file is prepared, there are two ways to send it. - **From the Workspace, through a society connection.** If you have saved a [society connection](https://trackforge.studio/docs/workspace/settings/society-connections) that reaches the society, the page shows **Send this file** with **Next: send it to** the society **through your saved connection**. Press it, choose the connection under **Send through**, tick that you are authorised to send these registrations from that account, and press **Send file**. TrackForge uploads the file to the society's file server and records the send, so you do not record it yourself. A connection can be ICE (for PRS for Music and MCPS), The MLC, or the SFTP login a society such as MusicMark, SAMRO or CMRRA gave you. See [Societies and how files reach them](https://trackforge.studio/docs/workspace/settings/society-connections#societies-and-how-files-reach-them). - **Yourself, outside TrackForge.** Without a connection, or if you prefer, you download the file, send it to the society by the society's own route, then come back and record that you sent it, as in the steps below. The record lets TrackForge wait for the society's reply and keep the file on [Today](https://trackforge.studio/docs/workspace/today/) until it arrives. ## Before you start You need a prepared file. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). Only owners and editors can record a send. ## Steps to send it yourself 1. Open the file. It opens when you prepare it. Later, choose **Files and responses** and open the file from **Preparation history**, or press **Record that you sent it** beside the file on Today. 2. Press **Download file**. When a connection could send the file, this button sits under **Sending it another way?**. The page shows **Downloaded ✓**, and the button becomes **Download again**. 3. Send the file yourself, outside TrackForge, by the society's own route, such as its online portal or email. The page reminds you that TrackForge sends nothing. Under **Recorded deliveries and society responses**, a note gives the route the society publishes. If it says the route is unknown, confirm the method with the society. 4. Come back and press **I’ve sent it**. A window headed **Record that you sent this file** opens over the page. 5. Fill it in. Enter what you actually did: - **Society you sent it to**. It starts as the society you prepared the file for. It decides whose reply TrackForge says it is waiting for, and names the box where you upload that reply. - **How you sent it**: **The society’s online portal**, **Email** or **Another way**. For another way, describe it in **Describe how you sent it**. - **Date and time sent · your local time**. It starts as now. Change it to when you really sent the file. - The tick box that begins **I sent this exact file to**. It says you sent the file yourself. The window shows the file name and its SHA-256, a code that identifies that exact file, so the record is about one file. 6. Press **Save delivery record**. It stays off until you have chosen how you sent the file, with a description if you chose **Another way**, and ticked the box. The time must be after the file was prepared and not in the future. **Cancel** closes the window without saving. ![The Record that you sent this file window, with the society, the way it was sent, the date and time and the tick box filled in.](https://trackforge.studio/docs/img/workspace/record-sent.png) ## What you will see - **Delivery recorded.** and a line saying TrackForge is waiting for the society's response. - A strip of three stages, **Prepared**, **Sent** and **Response**. The file is now at **Sent**. - A record headed **Recorded by you**, with the society, the route and the time. - On Today, the file under **Files in progress** as **Awaiting response**. Until you record the send, the file stays **Prepared — not sent**, and TrackForge does not know to wait for a response. If you also sent the same file to another society, press **Record another send of this file** and choose that society. A file can be recorded once for each society, and a record cannot be changed afterwards, so check what you entered before you save it. When the society replies, [upload its response](https://trackforge.studio/docs/workspace/files/upload-a-response). ## Different routes for different societies You do not have to send every file the same way. Each society has its own route, and you use whichever it takes: you might send files to one society from the Workspace through a connection, upload them to another society's online portal and email them to a third. Choose **Another way** for a route the window does not list, and describe it. Each file is prepared for one society, sent by that society's route and recorded with the route you used. Each society replies by its own route too, and you upload each response to its file. A file you send to more than one society is recorded once for each, and each record keeps its own route. ## Other things on this page - **Download work manifest…** lists the works in the file as Excel, CSV (in a zip) or JSON. - **Technical file details and preserved evidence** holds the exact works and settings used, with **Download exact snapshot JSON**. Later edits leave the file and this evidence as they were. ## If something goes wrong - **The file's page says the saved work has changed.** The note reads **Saved work has changed since this revision was prepared.** The file is still the one you downloaded. To send the newer versions, press **Prepare latest saved versions**, then download, send and record the new file. - **There is no record button.** The button **I’ve sent it** is missing when you can only look, or when the page says **Can't prepare yet** and no file was made. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). ## Related - [Upload a response](https://trackforge.studio/docs/workspace/files/upload-a-response) - [What Today shows](https://trackforge.studio/docs/workspace/today/) - [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) --- *Source: [https://trackforge.studio/docs/workspace/files/send](https://trackforge.studio/docs/workspace/files/send)* --- ## docs/workspace/files/upload-a-response.md # Upload a response > Upload the file a society sends back after you send it a registration file, and see how TrackForge read it. After a society deals with a file you sent, it sends back a response file, called an [acknowledgement](https://trackforge.studio/docs/cwr/glossary#society_acknowledgement). It is how the society says what it did with each work. You get it from the society, not from TrackForge. Upload it here and TrackForge reads it and shows the result for each work. ## Before you start - Record that you sent the file. The upload box is part of that record. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send). - Only owners and editors can upload. - Have the society's reply to this file. It usually ends in `.V21` or `.ACK`. The box accepts `.v21`, `.v22`, `.ack` and `.txt` files. ## Steps 1. Open the file. On Today, find it under **Files in progress** and press **Upload the response**. Or choose **Files and responses** and open the file from **Preparation history**. 2. Find the record of your send under **Recorded deliveries and society responses**. Its upload box is named after the society, such as "Upload PRS’s response file". 3. Drop the file on the box, or choose it. The hint under the box, **Drop the file here or choose it.**, gives the file types, how many files you can add at once and the size limit for each. 4. Wait while the box shows **Reading the response…**. When TrackForge has matched the file to your recorded send, you see **Response read.** and a line about the result. If it could not be matched, there is no such line: find the file under **Response files you uploaded for this send** and read its state. ![The upload box for the society's response on a recorded delivery, with one response file listed below it as matched to the delivery.](https://trackforge.studio/docs/img/workspace/upload-response.png) ## What you will see The line after **Response read.** says one of three things: - The society replied, with a count such as "1 Needs correction · 4 Accepted". The result for each work is shown above the box. See [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response). - The response answers a different file you sent. It is filed against that file, and the line says where to look. - It is not the latest response from the society for this file, so the results have not changed. Under **Response files you uploaded for this send**, each file shows what happened to it: - **Matched to a recorded delivery**. The results are in. - **Read, not yet matched** or **Saved, not yet read**. TrackForge has the file and has not finished with it. - **Could not be read as a CWR acknowledgement**. - **Conflicting response — kept for review**. - **Already uploaded** comes before the state when you add the same file again. **Download response** gives you the file back. **Download report…**, in Excel, CSV (in a zip) or JSON, appears only for a matched response. On Today, the card **Society responses** lists the responses you uploaded most recently, newest first. **Open the file** goes to the file it answers. ## If something goes wrong - **There is no upload box.** The send is not recorded yet, and the page says **No delivery is recorded for this revision.** Record it first. You may also be view-only. - **The file could not be read.** Check you chose the society's reply, not the file you sent. - **The screen says no recorded delivery matches.** Check it is the acknowledgement for this file. TrackForge keeps it for review. - **The file is too large or you chose too many.** The box tells you the limit. - **You added the reply in registration history.** TrackForge matches it to the file you recorded as sent. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). If a file has had no response for a long time, Today says **No response after 30 days**. Upload the reply if you have it. Otherwise, check with the society. ## Related - [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response) - [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again) - [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you) --- *Source: [https://trackforge.studio/docs/workspace/files/upload-a-response](https://trackforge.studio/docs/workspace/files/upload-a-response)* --- ## docs/workspace/files/understand-a-response.md # Understand a response > Read what a society said about each work in a response, in plain words, and what to do next. ## What you are looking at A response is the society's reply to a file you sent it. TrackForge turns it into one card for each work in that file. A card shows the work's title, a badge with the society's result, and, unless the work was accepted, what the society said and what to do next. The link **How to read a response** on those cards opens this page. Cards sit under the record of your send on the file's page, below **Recorded deliveries and society responses**. A line above them counts the results, problems first, for example "PRS replied: 1 Needs correction · 4 Accepted." ![A response card for a work that needs correction, with the box What PRS said, What to do next and the button to fix the work.](https://trackforge.studio/docs/img/workspace/response-card.png) ## What the badge means | Badge | What it means | What to do next | |---|---|---| | **Accepted** | The society accepted the version you sent. It is not proof that money has been collected. | Nothing. | | **Accepted with changes** | The society accepted the work but changed some details. | Check them against your catalogue. Update your work if theirs are right. | | **Needs correction** | The society rejected the work or asked for a correction. | Fix the part named, save, and prepare a correction file. See [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again). | | **Conflict** | Another party claims shares in the work. | Check your ownership and shares. Contact the society if your claim is right. At SAMRO, a conflict can mean only that another work has the same title, so check that the writers match before you change anything. | | **Possible duplicate** | The society may already hold this work. | Check whether it was registered before. Prepare a correction only if the details differ. | | **Not participating** | The society does not administer these rights for this work. | Nothing for that society. | | **Response needs review** | TrackForge could not classify the response. | Read the society's message and decide whether the work needs a correction. | The card's next-step line is headed **What to do next:**. These are the screen's own words, in short. ## What the society said The box headed, for example, "What PRS said" (with the society's name) gives a plain sentence for each message. It starts with what the society did: rejected the whole file, rejected every work in a group, rejected this work's registration, or ignored one line or one value. It ends with the part of the work at fault, such as the work details, a writer, a publisher or a recording. For example: "PRS rejected this work’s registration because of a problem with a writer." Under it, the society's original message appears in its own words. Where a message names the same work number or [ISWC](https://trackforge.studio/docs/cwr/glossary#iswc) as another of your works, the card explains why that matters and a **Where:** line says where to put it right. SAMRO's "Composer/Author role is invalid for a LEGAL ENTITY" means a writer on the work is, in SAMRO's records, a company rather than a person. It usually happens when a company's name or IPI number was entered as a writer. Check each writer's name and IPI number. A writer is the person who wrote the work; a company that owns or administers it belongs among the publishers. Then fix the writer and prepare a correction file. The line under the title shows the society, the version you submitted and, when the society gave the work its own number, that reference. **Earlier response** means a later response has replaced it. A line such as "PRS answered for ABRAMUS." means one body answered on behalf of another. ## Technical details Open **Technical details and submitted work** to see exactly what you submitted. It says which saved version is current now and whether the work has changed since. It shows the submitted writers and publishers with their shares, and a table with **Message type**, **Level**, **Record** and **Validation number**. Most readers never need it. ## Prepared, sent and accepted These are three different things. Prepared means the file is built. Sent means you sent it and recorded it. Accepted means the society accepted the version you sent. See [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses). ## Related - [Fix and send again](https://trackforge.studio/docs/workspace/files/fix-and-send-again) - [Upload a response](https://trackforge.studio/docs/workspace/files/upload-a-response) - [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) --- *Source: [https://trackforge.studio/docs/workspace/files/understand-a-response](https://trackforge.studio/docs/workspace/files/understand-a-response)* --- ## docs/workspace/files/fix-and-send-again.md # Fix and send again > Fix a work a society rejected, save it, prepare a replacement file and send it, from the Workspace or yourself. When a society rejects a work, its card says **Needs correction**. There is no button that sends a file again, and TrackForge sends nothing itself. You fix the work, save it, prepare a new file for it and send that file: from the Workspace through a [society connection](https://trackforge.studio/docs/workspace/settings/society-connections), or yourself, recording the send. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send). How to act on a response: each work in it is accepted, needs a correction, or has no answer yet. There is no button to send a file again, so a correction goes back through a new file. How to act on a response, work by work, as the text above describes: a correction goes back through a new file. ```d2 direction: down upload: Upload the response each: For each work nothing: Nothing to do wait: "Wait for the\nnext response" fix: "Open the work\nand fix it" save: Save prepare: Prepare a new file send: "Download it, send it,\nrecord the send" upload -> each each -> nothing: Accepted each -> wait: No answer yet each -> fix: Needs correction fix -> save save -> prepare prepare -> send send -> upload ``` ## Before you start Read what the society said. See [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response). You must be an owner or editor. ## Steps 1. Open the response. On Today, press **Review society response**, the main button when a society has said a work needs correction, or press **View response and history** on that work's card. If you have already saved a correction, the card offers **Continue correction**. Or choose **Files and responses** and open the file from **Preparation history**. The cards are under **Recorded deliveries and society responses**. 2. On the card of the rejected work, read the reason and **What to do next:**. Press the button **Fix and prepare a correction for** followed by the work's title. 3. The work opens with a box at the top headed **Correcting revision for** and the society's name. It gives the society's reason and, depending on the problem, a button such as **Go to the writers**. The fold **Review submitted version** shows exactly what you sent, to compare with the version you are editing. The same reason is on the work's **To do** panel. 4. Fix the work. See [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). 5. Press **Save work**. The bar at the top reads **Your correction is saved. Next: prepare the replacement file.** 6. Press **Prepare the replacement**. You return to the file, where the panel **Prepare a replacement for this response** has a button **Prepare replacement**. Press it. 7. The form is titled **Prepare response replacement**. It holds only the works the response names, with the original settings loaded for you to review. **What are you preparing?** starts with the purpose of the first file. If that was **New registration with this recipient**, a note says it is kept: a rejected work is not registered with that society yet, so you send its replacement as a new registration again. If the first file was an update, check the choice before you prepare. Choose an update only for a work the society has already accepted. 8. Press **Check and prepare file**. Then [download, send and record](https://trackforge.studio/docs/workspace/files/send) the new file, as for any other. When the society replies, [upload its response](https://trackforge.studio/docs/workspace/files/upload-a-response). ![A work opened from a response, with the Correcting revision box at the top and the Review submitted version fold open.](https://trackforge.studio/docs/img/workspace/fix-and-send-again.png) ## What you will see The first file and its response stay in history exactly as they were. On the first file, **Response replacements** lists the new one with **View replacement revision**. On the new file, **Replacement from a customer response** names the works it replaces, and **View original preparation** goes back. The new file starts as **Prepared — not sent**. If you saved a fix before opening the response, its card says you have saved a newer version since the response. Check the fix, then prepare the replacement. ## If something goes wrong - **A replacement is already prepared.** The form offers **Open existing replacement**. - **A work was saved again after you chose it.** Press **Use the latest saved versions**. - **The new file says **Can't prepare yet**.** Fix the problems it lists. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). - **There is no fix button on a card.** It appears only on the latest response for a work marked **Needs correction**, **Conflict**, **Not participating** or **Response needs review**, and only for owners and editors. A card marked **Accepted**, **Accepted with changes**, **Possible duplicate** or **Earlier response** has none. To change such a work, open it from the catalogue, then [prepare a file](https://trackforge.studio/docs/workspace/files/prepare) as usual. ## Related - [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response) - [Download, send and record](https://trackforge.studio/docs/workspace/files/send) - [What needs you next](https://trackforge.studio/docs/workspace/today/needs-you) --- *Source: [https://trackforge.studio/docs/workspace/files/fix-and-send-again](https://trackforge.studio/docs/workspace/files/fix-and-send-again)* --- ## docs/workspace/files/registration-history.md # Upload your registration history > Add old CWR files, society responses and work lists as a record, and match their works to the works you have saved. Use registration history for registrations made before TrackForge or outside it. You upload the files you already have. TrackForge keeps them as a record, matches their works to works you have saved, and shows you where a society holds something different from your catalogue. These files are a record. TrackForge did not send them, they do not become a TrackForge delivery, and uploading them does not add works to your catalogue. ## Before you start - Only owners and editors can upload. - Have your [CWR](https://trackforge.studio/docs/cwr/glossary#cwr) 2.1 files, society responses (ACK), ISW identifier notifications, or PRS agreement work-list JSON captures. You can upload them one by one or in a zip. Other societies' work-list formats are not supported yet. - To find works a society holds differently from your catalogue, upload two files together: the CWR file you registered the works with, and the society's response (ACK) that accepted it. A CWR file on its own is matched to your works but gives nothing from the society to compare with, and a work list does not carry shares. ## Steps 1. Choose **Files and responses**, then the tab **Registration history**. On **Registration health**, **Bring in old files and replies** under **Add what you know** opens the same place. 2. In the card **Add supplied files**, choose your files in **History files**. The types are `.zip`, `.v21`, `.ack` and `.json`. The card says: "Up to 20 files, 5 MiB per file and 25 MiB per batch." 3. Leave **Work reference source** alone, under **Matching settings**, unless you imported your catalogue under a different source name. 4. Press **Upload supplied history**. ![The Add supplied files card with two files chosen, above the button Upload supplied history.](https://trackforge.studio/docs/img/workspace/registration-history-upload.png) ## What you will see A box headed **What the upload found** says how many files were read and kept, with counts for **Files read**, **Works matched**, **Not matched yet** and, if there are any, **Registered differently**. Under **What needs you**: - "N works registered differently from your saved details", with a button that starts **Review** and ends "that work" or "those works". See [Works registered differently](https://trackforge.studio/docs/workspace/files/registered-differently). - "N works in these files not matched to a saved work yet", with a button that starts **Match** and ends "it" or "them". You can leave these if the works are not in this catalogue. - **Nothing here needs you.** when there is nothing to do. For a society's work list (your PRS agreement work list), the box also counts **Positions recorded** and **Not held by the society**. The list says what the society holds for every saved work in the catalogue: **Held as your catalogue says** when an entry of the list is matched to the work (by a confirmed society work number or by ISWC), **Not held by the society** when the list could have matched the work and did not, and **Not checked** when the work has no ISWC or confirmed work number to find it by. Each work shows this under the society's status on its page, with the list it came from and the date the list was taken, and the catalogue's **Society position** filter lists the works in any one position. A newer list replaces an older one's reading for each work. A file in a format TrackForge does not read is kept, and the box says so. If a file was already held, nothing is added for it. If a file is a society's reply to a file you recorded as sent, the box says so and **Review society response** opens that file. The **Files** card lists everything held, with the kind (society response, CWR source, ISWC notification or society work list) and whether it was read. Choose a file to see its works in a table. **In your catalogue** says whether each is linked to a saved work, and **Differences** counts where the file and your saved work disagree. Press **Review** on a row to open that work in a window over the table. For a work that is not linked, type its title in **Find a saved work** there and press **Search**. Then press the button that reads **Link** and the title of the right work. **Download original file** gives the file back. For a CWR file with works that are not in your catalogue, **Add missing works from this file** opens an import review where you choose what to save. See [Review an import before saving](https://trackforge.studio/docs/workspace/add-works/review). Then press **Link again after adding**. For a work list, **Match confirmed society IDs** does the matching again. ## If something goes wrong - **The upload button is off.** Choose at least one file first. - **A file says it was kept but not read.** TrackForge reads CWR 2.1 registrations, ACK responses, ISW notifications and PRS work-list captures. Ask whoever sent it for a CWR 2.1 file. A CWR file with more than 250,000 lines or 30,000 works is also kept but not read, as it is more than a genuine CWR file holds. - **A zip is refused.** The limits apply to what the zip holds, counted as it is unpacked: up to 20 files and 25 MiB in one batch. Upload the files in smaller batches. To download a report on the whole catalogue across all societies, open the menu **Download report…** on the tab **Registration health**. It offers **Excel summary and full detail** and **PDF summary with charts**. Both say what each society holds beside where your registration has got to. In the Excel report, the sheet "Work statuses" has a column "Society holds" and a column "Society records read on" next to "Status", and the "Summary" sheet has a table and a chart "What each society holds", counting each society's works as "Held", "Not held" or "Not checked". The PDF has the same table with one bar per society. "Not checked" covers works with no reading yet and works the society does not deal in. ## Related - [Works registered differently](https://trackforge.studio/docs/workspace/files/registered-differently) - [Upload a response](https://trackforge.studio/docs/workspace/files/upload-a-response) - [Import a CWR file](https://trackforge.studio/docs/workspace/add-works/cwr-file) --- *Source: [https://trackforge.studio/docs/workspace/files/registration-history](https://trackforge.studio/docs/workspace/files/registration-history)* --- ## docs/workspace/files/registered-differently.md # Works registered differently > See which works a society holds differently from your catalogue and settle each difference. A work is registered differently when a society's accepted registration of it does not match the work you have saved, for example in its shares. Nothing changes until you choose. You can update the catalogue, prepare a revision for the society, or record why your catalogue is right. ## Before you start - The work needs an accepted registration to compare with. The card names the submission it comes from. You can bring in old registrations by [uploading your registration history](https://trackforge.studio/docs/workspace/files/registration-history): the CWR file and the society's response that accepted it, together. - Only owners and editors can settle a difference. Save any edits to the work first: until you do, the page says **Save your edits before deciding on registration differences.** ## Steps 1. Find the work. After an upload, press the button that starts **Review** and ends "that work" or "those works". Or press **Review the differences** or the **Registered differently** tile on Today. The catalogue opens filtered to **Registration differs**. 2. Open the work. It opens at the card **Registration and catalogue**, with one section for each society. 3. Read the comparison. The pill shows **Registration differs from catalogue**, **Difference reviewed** or **Matches the catalogue**. A table with the columns **Detail**, **In your catalogue** and **In the registration file** lists the differences. **Ownership and shares differ** comes first, and other differences are folded beneath. Differences in letter case alone, internal IDs, or empty on both sides are counted, not listed. On anything wider than a phone, **Show this comparison larger** opens the same table in a wide window. 4. Under **Choose one way to settle this difference**, choose one of the three ways below. ![The Registration and catalogue card of a work, with a table of the shares that differ and the ways to settle the difference.](https://trackforge.studio/docs/img/workspace/registered-differently.png) ## The three ways to settle it **Update my catalogue to match the registration.** Your saved work takes the registered values shown. Tick **I confirm the displayed changes to shares, parties and control.** If an ISWC differs, you can also tick **Also apply the displayed ISWC change.** Then press **Update my catalogue to match**, which stays off until the first box is ticked. The page says **Done.**, lists the values taken with what each one was, and gives the new saved version. **Keep my catalogue as it is.** Write why in **Why your catalogue is right (kept with the work)**, then press **Keep my catalogue as it is**. Your catalogue does not change. The society's registration is still different, and the work is no longer listed for review. Your reason stays with the work as **Intentional difference:**. That button stays off until you write a reason. **Keep it and prepare a revision for the society.** Press the button that begins **Keep it and prepare a revision for**. A revision tells the society what your catalogue says, so its registration can be brought into line. Your catalogue stays as it is, and the form to [prepare a file](https://trackforge.studio/docs/workspace/files/prepare) opens as an update for that society. The difference stays visible until that file is prepared. Then [download, send and record](https://trackforge.studio/docs/workspace/files/send) it as usual. ## From the history file The same three choices appear when you open a file in registration history and press **Review** on a linked work: **Update catalogue from supplied values**, **Mark reviewed**, which needs a **Review note**, and **Prepare revision**. ## If something goes wrong - **The choices are greyed out.** You have unsaved edits on the work, or a save is still running. Save the work first. - **There are no choices.** You can only look, or the difference is already settled. - **The work is not in the list.** The comparison is made against an accepted registration, so a work without one is not listed. It may still be registered elsewhere. - **A work list shows no shares.** It does not carry full shares or control terms, so they cannot be compared from it. ## Related - [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history) - [Writers, publishers and shares](https://trackforge.studio/docs/workspace/catalogue/shares) - [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses) --- *Source: [https://trackforge.studio/docs/workspace/files/registered-differently](https://trackforge.studio/docs/workspace/files/registered-differently)* --- ## docs/workspace/settings/publisher-details.md # Publisher details > Set your publisher name, IPI number and filename code, any other publishers you send to some societies as, and the defaults that the files you prepare start from. Your publisher details say who is sending your files: your publisher name, your [IPI](https://trackforge.studio/docs/cwr/glossary#ipi) number and a short code for naming files. A file cannot be prepared without them, and TrackForge uses them to check your works. This is step three of the **Get set up** card, and the prepare page fills them in from here. The same page holds your societies and the way to Society connections: [Your societies and Society connections](https://trackforge.studio/docs/workspace/settings/societies#your-societies-and-society-connections) says how the two differ. ## Before you start Only owners and editors can change these. If you can only look, a note at the top of **Workspace settings** says **Only an owner or editor can change these settings.**, the boxes are switched off and there is no **Save settings** button. Have to hand the name your [society](https://trackforge.studio/docs/cwr/glossary#society) holds for you, your publisher's IPI name number and the 2 or 3 letters your society gave you for naming files. ## Steps 1. Open the account menu (your initials, top right) and choose **Workspace settings**. The card **Your publisher details** is near the top, under **Workspace name** if you are the workspace's owner. 2. In **Publisher name (as registered)**, type your company or publisher name exactly as your society has it. Spaces at either end go when you leave the box. 3. In **Publisher IPI number**, type your publisher's IPI name number. Its help tip says it is a 9 to 11 digit number. 4. In **Short code for your filenames**, type the 2 or 3 letters your society gave you, for example ABC. It is not your IPI number. 5. Press **Save settings**. Societies are saved as soon as you choose them, but these details are saved only with this button. All three are needed together: if one is missing or does not fit, the save is refused and a message says what to check. ![The Your publisher details card, with a line saying what the details are for, the publisher name, IPI number and filename code filled in, and the Save settings button below them.](https://trackforge.studio/docs/img/workspace/publisher-details.png) ## Publishers for different societies If you send to some societies as a different publisher, for example another company in your group, add it as another publisher and choose the societies it is for. Every other society uses your first publisher, the default one. 1. In **Your publisher details**, press **Add another publisher**. 2. Fill in its name, IPI number and short code as in steps 2 to 4. Keep any zeros at the start of the IPI number. 3. Under **Used for**, tick the societies you send to as this publisher. Only the societies you have chosen under [Societies](https://trackforge.studio/docs/workspace/settings/societies) are listed. A society has one publisher, so ticking it here takes it from any other. 4. Press **Save settings**. AllTrack is listed once for each of its accounts, worldwide and US only, because a publisher sends to one account. A publisher can be ticked for one account and another publisher for the other, and the note under the ticks says so: **A society has one publisher, and AllTrack one for each account. Choosing it here takes it from any other.** Each saved work is then checked with the account whose publisher it names, so a work naming your US publisher is checked as the US-only account and is not held for covering only part of the world. **Make default** swaps a publisher with the default one. The old default then has no societies until you tick some. **Remove** takes a publisher off the list, and its societies go back to the default one. Each society's works are checked with the publisher chosen for it. A new file for a society starts from its publisher, and a file for an AllTrack account from that account's publisher. A new society connection starts from the publisher of the societies it reaches, or from the default one when they have different publishers. ## File settings The fold **File settings (advanced)** holds two settings. Most publishers never change them. - **Type of file**: **New registrations** or **Updates to existing registrations**. It is the choice the prepare page starts from for a [new registration](https://trackforge.studio/docs/cwr/glossary#transaction_type_nwr) or an [update](https://trackforge.studio/docs/cwr/glossary#transaction_type_rev). - **Start file numbers from**: a whole number from 1 to 9999. Each file takes the next number for its society and year, never below this one, and never reuses a number. If you made CWR files this year before using the Workspace, enter the number after your last one: 27 if your last file was number 26. The number applies to the year you save it in. On 1 January it goes back to 1, because a CWR file name includes the year and each year's files are numbered from 0001. The prepare page shows the name the next file will get before you prepare it. ## What you will see - **You have unsaved changes.** until you save, then **Settings saved** beside the button. - On the prepare page, the details of the publisher for the file's society appear already filled in, with a note that they come from Workspace settings. If you choose another society, they change to its publisher unless you have edited them. If you change them there, a warning says they differ from the saved settings used for checks, so works that passed may show new issues. See [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare). ## If something goes wrong - **A warning says the name is longer than a [CWR](https://trackforge.studio/docs/cwr/glossary#cwr) file holds.** The warning calls it the sender name. It shows the shortened form the file will carry. Your own text is not changed. To choose the short form yourself, enter 45 characters or fewer. - **A notice says the name ends with a comma, semicolon or colon.** If that is not part of the name, use the button beside the notice to remove it. Otherwise it would appear in your files. - ****Start file numbers from** shows **Use a whole number from 1 to 9999.**** Correct it: **Save settings** stays off until you do. - **A message above the cards says why a save failed.** Problems with the IPI number or the name are explained at [the sender ID problem](https://trackforge.studio/docs/cwr/problems-and-fixes#sender-id) and [the sender name problem](https://trackforge.studio/docs/cwr/problems-and-fixes#sender-name). Those pages are shared with the Workbench, TrackForge's free public tool, so "Where to fix it" there names the Workbench. - **The settings changed while you were editing.** The message comes with a button **Reload current settings**. Your entries stay on screen: compare them with the current settings before you save again. ## Related - [Societies](https://trackforge.studio/docs/workspace/settings/societies) - [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare) - [Getting help](https://trackforge.studio/docs/workspace/help/) --- *Source: [https://trackforge.studio/docs/workspace/settings/publisher-details](https://trackforge.studio/docs/workspace/settings/publisher-details)* --- ## docs/workspace/settings/societies.md # Societies > Choose the societies you register with, pick a profile where one is offered, and see what TrackForge checks for each society. The societies you choose decide which statuses each work has: TrackForge checks every work for every [society](https://trackforge.studio/docs/cwr/glossary#society) you add, and shows where the work stands with each (see [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses)). This is step two of the **Get set up** card. Until you choose some, a work shows one summary, **Not checked yet — choose your societies**, instead of a status. Choosing a society sends nothing to it. ## Your societies and Society connections **Workspace settings** has two cards that are often mixed up. Each has a help tip beside its title. - **Your societies** are the societies you register your works with. Every work you add or import is checked against the rules of each one, as far as TrackForge knows them, and you prepare files for them. Where TrackForge does not check a society's own rules yet, the society says **General checks only** and your works get the general [CWR](https://trackforge.studio/docs/cwr/glossary#cwr) checks. Where it says **File preparation not available**, no file can be made for that society yet. Choosing a society sends nothing and needs no login. - **Society connections** are your logins to the societies' file servers, so TrackForge can send your files and collect the responses. A connection is optional: without one, you upload files to the society yourself. See [Society connections](https://trackforge.studio/docs/workspace/settings/society-connections). You can register with a society without a connection. Under each of your societies, a line says how its files get there: through your connection, for example to ICE, or **You upload files yourself.** ## Before you start Only owners and editors can add or remove a society. If you can only look, a note at the top of **Workspace settings** says **Only an owner or editor can change these settings.**, and the list is shown with its controls switched off. You can choose up to 20 societies. ## Add a society 1. Open the account menu (your initials, top right) and choose **Workspace settings**. The card **Your societies** is below **Your publisher details** and **Society connections**. 2. Press the box **Add a society**, which reads "Search for a society to add". Type a name, abbreviation or country. Only music rights societies are listed, with the common ones under **Most used** and the rest under **All music societies**. 3. Choose the society. It is saved at once: **Saving…**, then **Societies saved**. The count beside the card's title goes up by one. ![The Your societies card, with lines saying what choosing a society does and what its labels mean, the Add a society box, the block of societies named on your works and three chosen societies.](https://trackforge.studio/docs/img/workspace/settings-societies.png) If your works already name societies, a block **Societies named on your works** lists them, with how many works each is on. Tick the ones you send registrations to, or tick **Select all**, then press **Add selected**. They are all added in one save. Add only the ones you really register with, because each one is checked for every work. ## Choose a profile Some societies offer more than one [profile](https://trackforge.studio/docs/cwr/glossary#recipient_profile), the account set-up you have with them. For those, a box **Profile** appears, starting on the society's default. Choose the one that matches your account. If none is chosen, the fold **What we check for** says **Choose an account profile**. ## See what TrackForge checks Beside a society's name, a label may say how far the checks go: - **General checks only**: TrackForge applies its general checks for a [CWR](https://trackforge.studio/docs/cwr/glossary#cwr) file, not rules of that society's own. - **File preparation not available**: no file can be prepared for that society yet. Your other societies are not affected. If you do not register with it, remove it. - The profile's name followed by the word "checks": TrackForge checks against that profile. Under the society's name, a line **Society position** says how TrackForge finds out what the society's own records hold for your works: - **Upload the society's work list**: TrackForge reads the list of registered works you download from the society's portal. Upload it with your registration history. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). - **TrackForge checks this society**: TrackForge reads the society's records itself. - **No position available yet**: no reading of this society's records can be taken yet. Its works show **Not checked**. This line reports what TrackForge can do. There is nothing to switch on. Open the fold **What we check for** and the society's name to see more: - **Checks** gives the level of checking and what it means. - **Society registration route** is the route the society itself publishes for registering works, or **Unknown**. - **What we know about this society** is a second fold inside the first. Open it to see **CWR versions**, **Acknowledgement stages**, **ISWC notifications** and **Work-list access**. Each is **Unknown** unless it has been checked, in which case the source and the date checked sit beside it, with a link where the source is published. Where a society's own document reached TrackForge from a member rather than from the society's website, the source is named without a link. Where a fact was told to TrackForge rather than read in a document, the line says who reported it and when, and that the society has not confirmed it to us; under **Society registration route** the note then reads **This is the society's process as reported to TrackForge.** ## Remove a society Press **Remove** beside it. It is saved at once, with no further question. ## What you will see - If you are an owner or editor and have a society but no publisher name, a notice **Now** says **Next: add your publisher details, above.** Its button **Add publisher details** takes you to the box. See [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details). ## If something goes wrong - **The society is not in the list.** The box says **No music society matches. Try the society's full name or country.** Try the full name or the country. - **You cannot add another.** At the limit the card says **The 20-society limit is reached. Remove one before adding another.** - **Works still say they are not checked.** No society is chosen yet, or **Checking…** has not finished. ## Related - [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here) - [Prepare a file](https://trackforge.studio/docs/workspace/files/prepare) - [Getting help](https://trackforge.studio/docs/workspace/help/) --- *Source: [https://trackforge.studio/docs/workspace/settings/societies](https://trackforge.studio/docs/workspace/settings/societies)* --- ## docs/workspace/settings/workspace-name.md # Change the workspace's name > Rename your workspace as its owner, and see where the name is shown and what it is used for. The workspace's name is shown at the top of the page and in emails about the workspace. It starts as the business name you gave when the workspace was created, and its owner can change it. Your CWR files use your publisher details, not this name. ## Before you start - You must be the owner. For an editor or anyone who can only look, the card is not shown at all. Ask the owner. - If you have more than one workspace, the card belongs to the one chosen in **Workspace**. ## Steps 1. Open the account menu (your initials, top right) and choose **Workspace settings**. The card **Workspace name** is the first one. 2. Type the new name in the box. 3. Press **Save name**. It stays off while the box is empty or holds the name already saved. ![The Workspace name card, with the name in its box and the Save name button below it.](https://trackforge.studio/docs/img/workspace/workspace-name.png) ## What you will see The button reads **Saving…** while it works. The card then says **Workspace name saved**, and the name at the top of the page changes straight away. The name is also what you type to confirm closing your account. After a change, that window asks for the new name. See [Close your account](https://trackforge.studio/docs/workspace/settings/close-your-account). ## If something goes wrong - **There is no **Workspace name** card.** You are not the owner of the workspace that is open. If you have several workspaces, check the **Workspace** chooser. Otherwise ask the owner. - ****Save name** stays switched off.** The box is empty, or the name is the same as the one saved. - **A message appears under the box.** It gives the reason, and the name is not changed. ## Related - [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) - [Your account](https://trackforge.studio/docs/workspace/account) - [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way) --- *Source: [https://trackforge.studio/docs/workspace/settings/workspace-name](https://trackforge.studio/docs/workspace/settings/workspace-name)* --- ## docs/workspace/settings/society-connections.md # Society connections > Save a connection to a society's file server, test it, send files and check for the society's responses from the Workspace, by hand or automatically. A society connection holds the details of a society's file server, where CWR files are delivered and the society's responses come back. With one, you can test your login to that server, collect the society's responses, and send files to that society from the Workspace. A connection is optional: without one, you download each file and upload it to the society yourself. See [Sending files](#sending-files). A connection is not the same as choosing your societies, which decides what your works are checked against: see [Your societies and Society connections](https://trackforge.studio/docs/workspace/settings/societies#your-societies-and-society-connections). ## What you can connect to - **PRS for Music / MCPS via ICE** is ICE's file server. One connection serves both PRS for Music and MCPS. From 2 November 2026, GEMA takes files through ICE too, on the same login. - **The MLC** is The MLC's file server. - MusicMark (for ASCAP, BMI and SOCAN), SAMRO, CMRRA and HFA are each society's own SFTP server, on the login it issued you. - **Another society** is for any other society that gave you an SFTP login for CWR files. The form for a society shows what it asks of a publisher before it issues a login, with links to its own pages. Meeting those is between you and the society. Once you have the login, the Workspace uses it. See [Logins societies issue](https://trackforge.studio/docs/workspace/settings/society-logins). **Add a connection** lists all of these, and every choice opens a form. It also lists the societies ICE will take or may take, such as GEMA from 2 November 2026 and the ICE clients not confirmed yet; choosing one opens the ICE form, on the same login. The societies you register with that no connection reaches, for example APRA or AllTrack, are listed by name with the line "No connection reaches APRA, so download the file, send it to APRA yourself and record I've sent it." Choosing one still opens the **Another society** form with the society and its receiver code filled in, for a publisher that society has given an SFTP login; the form repeats the line, so add a connection only if you have one. ## Societies and how files reach them Under the tiles, the card **Societies and how files reach them** says in one line how many of the societies you register with a connection reaches. Press **Show all** to see the list: the societies you register with first, then every other society a connection reaches or will reach. Each society has the same line **Workspace settings** shows under it. - **Through ICE now:** PRS for Music and MCPS. - **Through The MLC now:** The MLC. - **Through ICE from 2 November 2026:** GEMA. GEMA processes the files sent to ICE from January 2027. - **Through your own login now:** ASCAP, BMI and SOCAN, through MusicMark, CMRRA and SAMRO. Add a connection with the login the society gave you, and files go through it; until then, you upload files to them yourself. - **Not confirmed yet:** STIM, KODA, TONO, Teosto and Sabam, which are ICE clients. ICE has not confirmed that it takes their CWR files. You can send them through your ICE connection if ICE takes them, or upload files to them yourself. - **Every other society**, for example SACEM or AllTrack: add the SFTP login it gave you under **Another society**, or by its name in **Add a connection**, and files go through it; otherwise you upload files yourself. ## Before you start - You need the login the society gave your organisation for its file server. Adding a connection does not apply to the society for one. - Add your publisher details in **Workspace settings** first, because a new connection is filled in from them. See [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details). - Only an owner or editor can add, change or test a connection. Anyone else sees the page with a note saying so. ## Open the page 1. Open the account menu (your initials, top right) and choose **Workspace settings**. 2. The card **Society connections**, under **Your publisher details**, lists the connections saved. Press **Open society connections**. Its breadcrumb reads **Workspace settings**, then **Society connections**. **Back to Workspace settings** takes you back. ## Add a connection 1. Press **Add a connection** and choose the server or society. 2. Check the publisher fields: **Publisher name (as registered)**, **Publisher IPI number** and **Short code for your filenames**. They are filled in from your publisher details, and the form says so. If you have [more than one publisher](https://trackforge.studio/docs/workspace/settings/publisher-details#publishers-for-different-societies), they come from the one used for the societies this connection reaches. Change them only if this login sends files for a different publisher. 3. For The MLC, choose the **Receiver file code** and the **Issued connection protocol** exactly as The MLC gave them to you. 4. For a society's own server, enter the **Server address**, **Port**, **Folder for files you send** and **Folder for the society's answers** as the society gave them. Where the society publishes them, they are filled in. For **Another society**, also enter its name in **Society** and its three-digit **Receiver file code**. 5. If you already have a login to the same server, give this one a **Name for this login**, for example the publisher it is for. With one login to a server, the form does not ask. 6. Under **Your login for** the society, type the username and password, or private key, the society gave you. The login is on the same form as the details, so there is no second step to look for. 7. Tick the box confirming it is your organisation's own login and that TrackForge may keep it and use it. 8. Press **Save and test login**. The details are saved, then the Workspace signs in with the login and saves it only if that works. The page then says **Login tested and saved** and the tile says **Connected**. If the society's server refuses the login, the details stay saved, the page says so, and the tile says **Login needed**: type the login again there and press **Test and save login**. Where a login cannot be saved in your workspace, the form asks only for the details and says "Your login is asked for next": press **Save connection details**, and the new tile asks for the login each time you test the connection or check for responses. For a society's own server, the first time you save the login the Workspace stops before your login is sent and shows **Confirm this server** on the tile. Check the fingerprint, press **Trust this server**, and save the login again with **Test and save login**. See [Confirm the server the first time](https://trackforge.studio/docs/workspace/settings/society-logins#confirm-the-server-the-first-time). ## Save, replace or remove the login Once saved, the tile shows **Login saved** with the date, and **Test connection** and **Check for responses** use it without asking again. - **Replace** opens the login form again, for example after the society changes your password. The new login is tested before it replaces the old one. - **Remove** asks you to confirm with **Remove login**, then deletes the login from where it is kept. The connection's details stay. To use the connection again, save a login again. - If you change the connection's details with **Edit details**, the tile asks for the login again. ## Check for responses automatically Where the society's server uses SFTP, the login form offers **Also check for responses automatically, about twice a day**, and the tile has the switch **Check for responses automatically, about twice a day** once the login is saved. With it on, TrackForge checks for the society's responses about every 12 hours, as **Check for responses** does, including while you are signed out. The tile shows when the next check is due and when the last one ran. - Turn the switch off to stop automatic checks at any time. The saved login stays. - If the login stops working, automatic checks stop and the Workspace shows **Automatic response checks paused**. Save the login again with **Replace**, or turn the switch back on. - **Remove** deletes the login and stops automatic checks with it. ## What a connection's tile shows Each connection is a tile named after its society. When you have two logins to the same server, each tile also shows the name you gave it. Beside the name, a plug icon shows whether it is connected: the two plugs are joined when the connection works, and apart when it does not. The badge at the top right gives its one status in words: - **Connected**: the last test signed in and read your folders. - **Can’t connect**: the last test failed. The line on the tile gives the society server's reason. - **Not tested**: the connection has not been tested yet. Under the name, a line says which publisher the connection sends as, with its short code, for example "Sends as Example Music Publishing Ltd (EXM)". **Edit details** opens the connection's details again and shows the server it uses. ## Test connection and Check for responses - **Test connection** signs in with the saved login and counts the files in your folders on the society's server. The answer is one line on the tile. The whole test has about 36 seconds; a folder the server is still listing when that runs out is reported as one that could not be read, so a very large or slow folder can show as unreadable although the login works. - **Check for responses** keeps a copy of the society's acknowledgements for files sent under your sender code. It is offered where the society's server uses SFTP. To have it run without pressing it, see [Check for responses automatically](#check-for-responses-automatically). Neither changes, moves or deletes anything on the society's server, and neither sends a registration. To read what a society said, see [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response). ## Sending files A prepared file shows **Send this file** when a connection with the same publisher details and receiver code can take it, whichever society that is. Choose the connection under **Send through**, check **What will be sent**, tick that you are authorised to send these registrations from that account, and press **Send file**. TrackForge uploads that file to the society's server with the connection's login and records the send. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send). Where no connection can take a file, you download it and upload it to the society yourself. For a society no connection reaches, for example APRA, the file's send step says so in one line: download the file, send it to the society yourself and record **I've sent it**. On **Workspace settings**, each society you register with has a line saying how its files travel: you upload them yourself, you upload them and check for responses through your connection, or they go through your connection. Where you upload them yourself, the line adds what a connection could do: that you can add one, when it starts, that it is coming, or that it is not confirmed yet. Joined plugs mark a line that goes through a connection, and plugs apart mark one that does not. ## How your login is protected The panel **How we protect your login** on the page says the same: - **Storage.** Your login is kept in Google Cloud Secret Manager, in Google's London region, not in TrackForge's database. - **Encryption.** Google encrypts it where it is stored. It travels only over encrypted connections: to Google, and to the society's server. - **Use.** TrackForge's server reads it only to test the connection, send the files you choose and check for responses, including the automatic checks you turn on. Google logs every read. It is never shown again, and never shared. - **Control.** Replace or remove it at any time. Signing out or closing the page keeps it. Removing it deletes it from Google. If you delete your workspace with **Close workspace**, it is not used unless the workspace is reopened, and is deleted with everything else 30 days later. The [Privacy Policy](https://trackforge.studio/privacy) (section 13) says what a connection keeps. ## If something goes wrong - ****Save connection details** stays switched off.** A field is missing or not valid. The IPI number is 9 to 11 digits, and the short code is 2 or 3 letters or digits. A second login to the same server also needs a name. - ****Save and test login** or **Test and save login** stays switched off.** Fill in every login field and tick the box. - **The page says the society did not accept the login.** The test failed, so the login was not saved. Check the login the society gave you and try again. - **The page says the login belongs to a different account.** A connection stays with the account it was first tested with. For another account, add another connection. - **The tile says **Can’t connect**.** Read the reason on the tile. Check the details with **Edit details**, then press **Replace** if the society changed your login. - **There are no buttons.** Only an owner or editor can add, change or test a connection. ## Related - [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) - [Logins societies issue](https://trackforge.studio/docs/workspace/settings/society-logins) - [Societies](https://trackforge.studio/docs/workspace/settings/societies) - [Download, send and record](https://trackforge.studio/docs/workspace/files/send) - [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response) --- *Source: [https://trackforge.studio/docs/workspace/settings/society-connections](https://trackforge.studio/docs/workspace/settings/society-connections)* --- ## docs/workspace/account.md # Your account > Open your account from the account menu to change your name, see your plan and works allowance, and read which emails the Workspace sends. The Account page holds what belongs to you and not to one catalogue: your name, your plan, the emails the Workspace sends and closing your account. What belongs to the workspace, such as its societies and publisher details, is in **Workspace settings**, in the same menu. ## Open your account The account button is at the right-hand end of the top bar. It shows your initials and, on a wider screen, your first name. Until you have given a name it reads **Account**. Press it to open a menu with your name and email address at the top, then four choices, with a line between each group: - **Workspace settings**, with the open workspace's name beneath it, opens the settings that apply to every catalogue in the workspace: its name, your publisher details, your societies and Society connections. See [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way#workspace-settings). - **Profile** opens the Account page. - **Plan and billing** opens the same page at the card of that name. - **Sign out** signs you out. ![The account menu open at the right-hand end of the top bar: a name and email address above Workspace settings and the workspace's name, then Profile and Plan and billing, then Sign out.](https://trackforge.studio/docs/img/workspace/account-menu.png) The Account page takes the catalogue's place on the screen, so the tabs are not shown while it is open. **Back to catalogue** returns you to where you were. **Search** stays in the top bar: what you choose in it closes the page. See [Search](https://trackforge.studio/docs/workspace/help/#search). ![The Account page, headed Your account, with the Profile card and the Plan and billing card below it.](https://trackforge.studio/docs/img/workspace/account-page.png) ## Change your name 1. Open the account menu and choose **Profile**. 2. On the **Profile** card, type your **First name** and **Last name**. Both are needed. 3. Press **Save profile**. It stays off until you have changed one of them. The card says **Profile saved**, and the account button shows your new initials and first name straight away. The card also shows the email address you sign in with. The Workspace finds your workspace by that address, so you cannot change it here. The card gives the address to email if it needs changing. ## Your plan The **Plan and billing** card shows the workspace's name and its plan. During the beta the plan reads **Free beta**. Below that are the number of works you have saved out of the most the account may hold, with the link **ask for more**, the day the workspace was opened and the day you accepted the beta offer. The beta offer is printed in full under them. If you have more than one workspace, this card is about the one chosen in **Workspace**. ## Emails the Workspace sends The **Emails** card lists each email the Workspace sends to your address and why, and says that none of it is marketing. One is the **Unused-workspace warning**, sent to a workspace's owner once it has gone unused for 11 months. The card says the workspace is deleted 30 days later unless someone signs in, and that this email cannot be turned off. ## Download everything The **Download everything** card is shown to everyone who can see the workspace. It makes one zip of the workspace's catalogues, reports, prepared files, society responses, the files you brought in, agreements and lyrics. See [Downloads and your data](https://trackforge.studio/docs/workspace/help/your-data). ## Close your account The last card, framed in red, **Close your account**, is shown only to the workspace's owner. See [Close your account](https://trackforge.studio/docs/workspace/settings/close-your-account). ## If something goes wrong - **The choices in the account menu are greyed out.** You have unsaved changes, or a save is under way. Save or close what you are working on first. - **The menu offers only **Sign out**.** Your account has no workspace yet, so there is no Account page to open. - ****Save profile** stays switched off.** Both names are needed, and one of them must differ from what is saved. ## Related - [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way) - [Close your account](https://trackforge.studio/docs/workspace/settings/close-your-account) - [Change the workspace's name](https://trackforge.studio/docs/workspace/settings/workspace-name) - [Getting help](https://trackforge.studio/docs/workspace/help/) --- *Source: [https://trackforge.studio/docs/workspace/account](https://trackforge.studio/docs/workspace/account)* --- ## docs/workspace/settings/close-your-account.md # Close your account > Close your workspace as its owner: what the screen says will happen, what you type to confirm, and what you see afterwards. Closing your account closes the workspace you have open. Only the workspace's owner can do it. The card that does it is the last one on the Account page, framed in red, which you open from the account button at the right-hand end of the top bar. ## Before you start - You must be the owner. For an editor or anyone who can only look, the card is not shown at all. Ask the owner. - If you have more than one workspace, the card belongs to the one chosen in **Workspace**. Closing affects only that one. - The card advises you to download everything you want to keep first. The window that confirms closing offers it as its first step, and the **Download everything** card above lets you choose what to include. See [Downloads and your data](https://trackforge.studio/docs/workspace/help/your-data). ## Steps 1. Press the account button, choose **Profile** and scroll to the card **Close your account**. 2. Read what it says. Closing stops access to this workspace straight away. After 30 days TrackForge permanently deletes everything in it: catalogues, works, imports, prepared files, delivery records and society responses. 3. Press **Close workspace…**, the red button. A window opens, headed **Close** and the workspace's name. It repeats that access stops straight away and that everything is permanently deleted after 30 days. 4. Step 1, **Keep a copy**: press **Download everything** to save one zip of everything in the workspace, with its tables in Excel. It reads **Preparing your download…**, then **Your download has started.** You can skip this step. 5. Step 2, **Confirm**: type the workspace's name, shown in the line above the box (press the name to copy it). Capital letters and spaces at either end do not matter. 6. Press **Close workspace**, the red button without the dots. It stays off until what you typed matches. **Keep workspace** shuts the window and closes nothing. ![The window that confirms closing the workspace: step 1 Download everything, step 2 the workspace name typed in, and the red Close workspace button ready.](https://trackforge.studio/docs/img/workspace/close-account.png) ## What you will see The button reads **Closing…** while it works. The page then reloads and the workspace's screens are replaced by a card headed with the workspace's name and **is closed**. It says when everything in the workspace will be permanently deleted, and that to reopen it before then you email support@trackforge.studio. A closed workspace is quiet: no emails about society responses are sent for it, and no response updates are recorded, until it is reopened. If it is reopened within the 30 days, the updates that were due are then published. That address is also the one the first card gives for changing your mind within the 30 days. The card says nothing more about what happens next. For any other question, see [Getting help](https://trackforge.studio/docs/workspace/help/). ## If something goes wrong - ****Close workspace** stays switched off.** What you typed does not yet match the workspace's name. Check it against the name above the box. It is also off while the download in step 1 is being prepared. - **A message appears in the window.** It gives the reason, and the page does not reload. A message under step 1 means the download failed; nothing was closed. - **There is no **Close your account** card.** You are not the owner of the workspace that is open. If you have several workspaces, check the **Workspace** chooser. Otherwise ask the owner. - **You have changed your mind.** Email support@trackforge.studio within the 30 days the card names. ## Related - [Your account](https://trackforge.studio/docs/workspace/account) - [Downloads and your data](https://trackforge.studio/docs/workspace/help/your-data) - [Getting help](https://trackforge.studio/docs/workspace/help/) - [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way) --- *Source: [https://trackforge.studio/docs/workspace/settings/close-your-account](https://trackforge.studio/docs/workspace/settings/close-your-account)* --- ## docs/workspace/help.md # Getting help > Find help from inside the Workspace: help links, search, field tips, explanations of problems and responses, and email to TrackForge. The Workspace has help in several places. Guides and explanations open in a new tab, so you keep your place. ## Help for the page you are on The link **Help for this page** in the header opens the manual page for the part of the Workspace that is open. An open saved work opens [Edit a work](https://trackforge.studio/docs/workspace/catalogue/edit-a-work), a prepared file opens [Download, send and record](https://trackforge.studio/docs/workspace/files/send), **Workspace settings** opens [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details), and the Account page opens [Your account](https://trackforge.studio/docs/workspace/account). The header links are not shown on a phone-width screen. Use the footer link **Help and guides** there. It opens the front page of the documentation, with the Workspace manual and the [CWR reference](https://trackforge.studio/docs/cwr/). ## Help with setting up Each of the six steps on the **Get set up** card has a link, **How this works**, even when the step is done or you can only look. It opens the page for that step. [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here) covers the whole card. ## Search Press **Search** in the header, or Ctrl+K (⌘K on a Mac), to open the search box. On a phone-width screen the button shows a magnifying glass alone. Type to go to a section, find a work, writer or publisher, or search the help. Results come in four groups, and up to two more where questions and Ask TrackForge are switched on for your workspace: - **Go to** lists the sections of the open catalogue, **Workspace settings**, and the Account page as **Your account** and **Plan and billing**. An owner or editor also sees **Add a work** and **Import works**. - **Works in this catalogue** lists up to eight works. It searches from two characters, and only in the catalogue that is open, through the same details as the works list's search: titles, references, ISWCs, ISRCs, artists, writers, publishers and album details. See [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find). Type more to narrow it. - **Writers and publishers** lists up to four writers and four publishers whose name, IPI or IP number matches. Choosing one opens the works list filtered to their works. - **Ask about your works** appears once you type three words or more. Its one line repeats your words. Choose it, and the works list opens with the filters the question asks for, such as a status, a society, a writer, a publisher or a date. For example, *works sent to PRS last month with no ISWC* opens the list for PRS, filtered to works sent last month that have no ISWC. The list shows those filters as if you had set them, so change or clear them as usual. If the question cannot be used, the line says why: for example, it names a society your workspace has not chosen, or its dates are not clear. - **Help** lists the best six matches among the pages and headings of these docs. Where questions are switched on, the docs' own AI search finds these pages, and until it answers, or if it cannot, the box matches the pages and headings itself. A help result opens in a new tab. If the list of help pages cannot be loaded, the group holds one item, **Open the docs**, which opens the front page of the documentation. - **Ask TrackForge** comes last, where Ask TrackForge is switched on. Its one row, **Ask:** and your words, asks Ask TrackForge and opens its panel. With nothing typed the row reads **Open Ask TrackForge**. See [Ask TrackForge](https://trackforge.studio/docs/workspace/help/ask-trackforge). A question is turned into filters by a language model that Cloudflare runs for us. It is sent your question and the codes of your workspace's societies, never your catalogue, and our own server then finds the works. The [privacy policy](https://trackforge.studio/privacy) (section 13) says what Cloudflare keeps. ![The search box open over Today with the letters lan typed, listing Plan and billing under Go to, a work and some help pages below.](https://trackforge.studio/docs/img/workspace/search-box.png) Use the arrow keys and Enter to choose, and Escape to close the box. On **All catalogues** the box lists your catalogues under **Open a catalogue** in place of the first three groups. The box works on the Account page and in **Workspace settings** too. There it searches the works of every catalogue, under **Works**, and a work opens in a catalogue it is in. A writer or publisher opens **All catalogues** filtered to their works. **Ask about your works** is not offered there, because it filters one catalogue's list. Whatever you choose closes the page. While you have unsaved changes or a save is under way, the box says to finish what you are doing on the page first. Until then the sections and works are shown but cannot be chosen, a question cannot be asked, and only the help can be opened. The shortcut does nothing while a dialog is open. ## Help beside a field Some fields have a small help button, shown as an "i", beside the label. Its name starts "Help:", for example "Help: sender name" beside **Publisher name (as registered)** in **Workspace settings**. Point at it to read the tip. On a touch screen, press it. Press it again, press Escape or press elsewhere to close the tip. Tab skips the button, so it moves from field to field. To read a field's tip from the keyboard, press F1 or Alt+/ while the cursor is in the field. The tip opens and the cursor stays put. A field with no tip does nothing. ## Help with a problem or a response - **What this means** sits beside a problem that the CWR reference explains: on a work's **To do** panel, among the checks on a prepared file, and in the panel **What is holding your works up**. It opens that problem in [Problems and fixes](https://trackforge.studio/docs/cwr/problems-and-fixes). A problem with no explanation has no link. - **How to read a response** sits in the notice on a society's response that reports what the society said. It opens [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response). ## Ask TrackForge Where it is switched on, **Ask** in the header opens Ask TrackForge, which answers questions from TrackForge's guides and music-rights sources and shows its sources. Beside a problem or a society's response, **Explain** asks it what that means. It is being tried with a few workspaces first. See [Ask TrackForge](https://trackforge.studio/docs/workspace/help/ask-trackforge). ## Email TrackForge - **Contact support**, in the header and the footer, opens an email to support@trackforge.studio in your email program. - When you have used all the works your account allows, the badge **Full** appears under the **Works** meter with a link, **ask for more**. It opens an email to support@trackforge.studio with the subject "More works for my workspace". See [Finding your way around](https://trackforge.studio/docs/workspace/finding-your-way). ## If something goes wrong - **A work, a file or a response shows a problem you do not understand.** Choose **What this means** beside it, or look the message up in [Problems and fixes](https://trackforge.studio/docs/cwr/problems-and-fixes). For what a society said about a file, see [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response). - **A button is switched off, or the screen does not do what you expect.** Choose **Help for this page**. It opens the manual page for that screen, and most pages end with their own list of what can go wrong and what to do. - **You cannot find how to do something.** Open **Search** and type what you are trying to do. - **A screen will not load, or shows an error.** Reload the page. If it happens again, choose **Contact support** and say which catalogue and work you had open, what you pressed and what the screen said. ## Related - [What the Workspace is](https://trackforge.studio/docs/workspace/) - [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here) - [Glossary](https://trackforge.studio/docs/cwr/glossary) --- *Source: [https://trackforge.studio/docs/workspace/help/](https://trackforge.studio/docs/workspace/help/)* --- ## docs/workspace/help/ask-trackforge.md # Ask TrackForge > Ask the Workspace's assistant how to do something, what a problem or a society's response means, or about the works in your catalogue, read its sources, and use Premium answers. Ask TrackForge answers questions about registering works, using the Workspace and the works in your catalogue. Its answers come from TrackForge's guides, music-rights sources and the works saved in your workspace, and each answer says which sources it used. It is being tried with a few workspaces first, so you may not see it yet. ## Open Ask TrackForge Press **Ask** in the header, beside **Search**. The panel **Ask TrackForge** opens at the side of the page, so the screen you are working on stays in view. On a phone-width screen it covers the screen, with a shorter question box and the **Premium answer** tick beside **Ask**; **Back to the Workspace** closes it. Press **Ask** again, Escape, or the close button (×) at the top of the panel to close it. You can also ask from the search box: open **Search**, type your question, and choose the row under **Ask TrackForge**, which starts **Ask:**. That is not the same as **Ask about your works**, which turns a question into the works list's filters: see [Getting help](https://trackforge.studio/docs/workspace/help/). When Ask TrackForge is new to you, the updates bell in the header shows it under **New in the Workspace**, marked **New**. Choose **Ask TrackForge** there to open the panel. It is shown until you choose it or press **Mark all as read**, and is not shown again in that browser. It is not shown after 31 December 2026. ## Ask a question Type in **Your question** and press **Ask**. Before you ask anything, the panel suggests three **Questions to start with** for the screen that is open. Choose one to ask it. While the answer is found, the panel reads **Searching the guides…**, then how many sources it is reading, then **Writing…**. When it looks something up in your catalogue, the panel reads **Looking up** and what it is looking up. The answer appears as it is written, under your question at the top of the panel, so you read it from its start. **Stop** ends it part-way. Ask a follow-up in the same box: the panel remembers the last few questions and answers. **Start again** clears the conversation. Ask TrackForge does not change your catalogue or send anything. It tells you what to do and where. ## Ask about your catalogue With a catalogue open, Ask TrackForge answers from the works saved in it. With none open, as on **All catalogues** or **Workspace settings**, it answers from all your catalogues together. For example: - How many works have I got in this catalogue? - How many artists do we have? - What do I need to do next? - Are there any files waiting to be sent? - Which works by Jane Doe are held? - Which works have no ISWC? - Show me every work PRS rejected. - What is the status of T-123.456.789-0? - Why was Night Song rejected by PRS? It reads the name of each of your catalogues and how many works it holds. For the catalogue open, or all your catalogues together when none is open, it reads the counts, what needs doing as **Today** lists it (the works that need you, files not yet sent or waiting for a response, and imports not finished), and the writers, publishers and artists on the saved works, with how many works each is on, and how many recordings it has. A writer or publisher is counted once by IPI number, so the same person saved on several works is one writer. It finds the works a question names by title, writer, artist or publisher name, ISWC, ISRC or IPI number, as the works list's search does, in the catalogue open or, with none open, in all of them. With a work open, or from **Explain** on a work, it also reads that work. Each work an answer uses is listed under **Sources** with the catalogue's name, or with **All catalogues** when none is open. While that catalogue is open, **Take me there** can open a work the answer names, or the works list showing the works in one state. When the answer looked works up, it can open the works list with the filters the answer used: in the catalogue it looked in, while that catalogue is open, or on **All catalogues** for a lookup across all of them. To answer which works, writers or items match, Ask TrackForge looks them up as the works list does, while it writes, and gives the exact number. A question can name another of your catalogues, or ask across all of them. A standard answer lists up to 20 of them and a Premium answer up to 50; **Take me there** opens the list of all of them. A standard answer reads up to 5 works in full, and a Premium answer up to 15. When a question finds more, the answer says it covers only the works it read. Ask TrackForge reads only the workspace you are working in. When a question asks about something it does not read, such as what your works have earned, the answer says it cannot see it. ## Explain a problem or a response **Explain** sits under a problem that Ask TrackForge can explain, beside **What this means** where that is shown: on a work's **To do** panel, among the checks on a prepared file, and in the panel **What is holding your works up**. It asks what the problem means and how to fix it, and opens the panel with the answer. On a society's response, **Explain this response** asks what the society's response means and what to do next. A response that came with no message from the society has no **Explain**. On Today, in the card **Society responses**, a response with rejections, conflicts or duplicates also has **Explain**: it explains the first work in that response the society sent a message about. What the panel is explaining shows at its top, after **Looking at**. An **Explain** on a work also reads that work, so the answer can use its writers, shares and responses. When the work's latest check no longer has the problem it explained, the answer says **Fixed: this no longer shows on** and the work's title. ## Read an answer and its sources An answer marks what it took from each source with the source's number in square brackets, such as [1]. The sources are numbered in the order the answer first uses them, and listed in that order under **Sources** below the answer; choose a number to go to its source. - A source from these docs opens inside the panel. **Back to the answer**, which stays at the top of the panel as you read, returns to the answer, and **Open the page** opens it in a new tab. - A source from TrackForge's music-rights sources shows its title, who published it and the passage used. **Open the original** opens it where it is published online. A document with no web address has no link. Where an answer names a screen of the Workspace, a button such as **Take me there** takes you to it. An answer that draws on TrackForge's rules or music-rights sources ends with the line **Information from the sources shown, not legal advice.** When the guides and sources do not answer a question, Ask TrackForge says so, with an email link to TrackForge. The link opens an email in your own email program with your question already written in. ## Tell us about an answer Under each answer, **Helpful?** asks whether it helped: press **Yes** or **No**. The panel then says **Thanks for telling us.** TrackForge counts the yes and no answers for your workspace each month, and keeps nothing of the question or the answer with them. If the panel says **Your answer to “Helpful?” could not be saved. Try again in a moment.**, press **Try again**. **Send this to TrackForge** opens an email to support@trackforge.studio in your own email program, with your question, the answer and its sources written in. Add anything you want to say and send it, and a person at TrackForge will look at the answer. Nothing is sent until you send the email. A very long answer is shortened to fit in an email, and the cut is marked with an ellipsis (…). ## Premium answers A Premium answer reads more of the guides and music-law sources and thinks for longer, for a fuller answer. It takes longer to arrive: in TrackForge's tests in October 2026, a standard answer usually took about 5 seconds and a Premium answer about 8, and the slowest Premium answers took about half a minute. An answer that looks something up in your catalogue takes a few seconds longer. A Premium answer is marked with a crown and the word Premium. - To ask for one, tick **Premium answer** under the question box before you press **Ask**. The line beside the tick says what a Premium answer is. - Under a standard answer, **Ask again with Premium** asks the same question again as a Premium answer. - **Explain** always gives a standard answer first, even while the tick is ticked. Use **Ask again with Premium** under it for more. - When the guides do not answer a standard question, Ask TrackForge may look further by itself. The answer then reads **The guides do not answer this, so this answer looks further.** During the beta, Premium answers are included, with no monthly limit. The **Plan and billing** card on the Account page shows them under **Premium answers** as **Included in the beta**. ## What is sent and kept Your question, the conversation's last few turns and, for **Explain**, the society, rule, codes and words of the problem or response are sent to write the answer. So is what the answer needs from your catalogue, or looks up there as it writes: its counts, what needs doing, the writers, publishers and artists with their IPI numbers, the works that match the works list's filters, and for each work it read, the title, references, ISWC, writers, publishers, shares, artists, recordings, state, what is left to do and the societies' latest responses. The guides and sources are searched for your question without the titles and names it found in your catalogue. TrackForge keeps no question and no answer, and writes nothing from your catalogue to its logs. The conversation stays in your browser tab, and is gone when you close the tab or press **Start again**. TrackForge keeps a count of each workspace's answers each month. The [Privacy Policy](https://trackforge.studio/privacy), section 13, names the companies that handle the question. ## If something goes wrong - **There is no **Ask** button.** Ask TrackForge is not switched on for your workspace yet. - **The panel says **Ask TrackForge could not be opened. Reload the page to use it.**** The Workspace has been updated since the page was opened. Reload the page. - **The panel says to give it a minute and ask again.** Many questions have been asked in a short time. Wait a minute and ask again. - **The answer stopped part-way.** Press **Ask again**. - **The panel says **Ask TrackForge is unavailable just now. Try again in a moment.**** Wait a moment and ask again. If it keeps happening, choose **Contact support**. - **The panel says answers are paused until a date.** TrackForge's limit for the month has been reached. **Search** still finds help pages. - **The question is too long.** Keep it to 1,000 characters. - **A source does not open in the panel.** Choose **Open the page** to open it in a new tab. ## Related - [Getting help](https://trackforge.studio/docs/workspace/help/) - [Understand a response](https://trackforge.studio/docs/workspace/files/understand-a-response) - [Problems and fixes](https://trackforge.studio/docs/cwr/problems-and-fixes) --- *Source: [https://trackforge.studio/docs/workspace/help/ask-trackforge](https://trackforge.studio/docs/workspace/help/ask-trackforge)* --- ## docs/workspace/help/your-data.md # Downloads and your data > See what you can download from the Workspace and where, how to delete and restore works, and how to close your account. This page maps what you can take out of the Workspace and what you can remove from it. Each section points to the page that has the steps. To take everything at once, use **Download everything**; each download below is also on its own page. ## Download everything The Account page, opened from the account button in the top bar, has a card **Download everything** for anyone who can see the workspace. Press **Download everything…**. A window lists what the zip can hold, each with a tick and how many there are: - **Catalogues**, with how many works they hold - **Registration reports**, one for each catalogue - **Prepared CWR files, with their work manifests**. Each file's folder also holds its exact snapshot JSON. - **Society responses**, as you uploaded them, with a report for each matched one - **Files you brought in**: the original of each CWR import and each registration history file - **Agreements** - **Lyrics**: one table of every work's lyrics and language Everything with something in it starts ticked. A part with nothing in it reads **None yet** and cannot be ticked. Under **Tables as** choose **Excel**, **CSV** or **JSON**; CWR files and the files you brought in are always as they were kept. Press **Download zip**. It reads **Preparing your download…** while the zip is made, then the window closes and **Download started** appears. The zip has one folder for each part and a file `README.txt` that says what each folder holds and when the zip was made. If a stored file could not be read, the rest is still included and `README.txt` names what is missing. ![The Download everything window, with a tick for each part and how many there are, the Tables as choice and the Download zip button.](https://trackforge.studio/docs/img/workspace/download-everything.png) ## What you can download | What | Where | What you get | |---|---|---| | Your catalogue, or the works you ticked | **Catalogue**: **Download…**. With works ticked it counts them and reads **selected…** after the number. | **Excel (.xlsx)**, **CSV (.zip)** or **JSON** | | A registration report | **Registration health**: **Download report…** | **Excel summary and full detail** or **PDF summary with charts**, for the **Whole catalogue, all societies** | | A prepared file | The file's page: **Download file**, then **Download again** | The CWR file, which you send yourself | | The works in a prepared file | The file's page: **Download work manifest…** | Excel, CSV (zip) or JSON | | The evidence behind a file | The file's page, in **Technical file details and preserved evidence**: **Download exact snapshot JSON** | The exact works and settings used | | A society response you uploaded | The file's page: **Download response**, and **Download report…** for a matched response | The response as you uploaded it; the report in Excel, CSV (zip) or JSON | | A file you brought in | **Download original .V21** when you review a CWR import; **Download original file** in your registration history | The file as it was kept | | An agreement | **Agreements**, on a saved agreement: **Download…** | Excel, CSV (zip) or JSON | | The lyrics of the works you ticked | **Catalogue**: **Make LyricFind lyrics file** | LyricFind's lyric-1.2 file (JSON) with each work's lyrics. The catalogue download does not include lyrics. See [Lyrics and LyricFind](https://trackforge.studio/docs/workspace/catalogue/lyrics) | The catalogue download and the registration report are there for anyone who can see the catalogue. TrackForge never sends a file on its own: you send a prepared file, from the Workspace through a [society connection](https://trackforge.studio/docs/workspace/settings/society-connections) or by downloading it. See [Download, send and record](https://trackforge.studio/docs/workspace/files/send), [Upload a response](https://trackforge.studio/docs/workspace/files/upload-a-response) and [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). ![The Catalogue heading with the Download menu open, offering Excel, CSV and JSON.](https://trackforge.studio/docs/img/workspace/your-data-download.png) ![The Registration health heading with the menu Download report open, offering an Excel summary and a PDF summary with charts.](https://trackforge.studio/docs/img/workspace/your-data-health.png) ## Delete and restore works If you are an owner or editor, tick works in **Catalogue** and press **Delete selected works**, then confirm. The works leave every catalogue and no longer count towards your limit. Files you prepared or sent keep their record, and you can restore the works later. Deleted works are reached only from **All catalogues**, in the fold **Deleted works**. They are not listed inside a single catalogue. See [History, undo and deleted works](https://trackforge.studio/docs/workspace/catalogue/history) and [Edit many works at once](https://trackforge.studio/docs/workspace/catalogue/edit-many). ## Close your account An owner can close the workspace from the Account page, opened from the account button in the top bar. The card, framed in red, says closing stops access straight away and that after 30 days everything in the workspace is permanently deleted. The window that confirms it offers **Download everything** as its first step. See [Close your account](https://trackforge.studio/docs/workspace/settings/close-your-account). ## What the beta offer says The beta offer says your data stays yours and that you can download it at any time. It says TrackForge deletes it only if you close your account, or after an emailed warning if the workspace has gone unused for 11 months. ## If something goes wrong - **A download does not start.** The page shows a message with the reason. For **Download everything** the message is in its window, and your ticks stay as they were. - ****Download everything** says **Nothing to download yet.**** The workspace has no catalogues, files or agreements yet. - ****Download…** is missing on an agreement.** It appears only once the agreement is saved. - **You cannot find deleted works.** Switch to **All catalogues** in the catalogue chooser. ## Related - [Getting help](https://trackforge.studio/docs/workspace/help/) - [Several catalogues](https://trackforge.studio/docs/workspace/catalogue/several-catalogues) --- *Source: [https://trackforge.studio/docs/workspace/help/your-data](https://trackforge.studio/docs/workspace/help/your-data)* --- ## docs/workspace/registration-health.md # Registration health > See where each society is up to with your catalogue and what each society holds, open the works behind any figure, and add what you know. **Registration health** is the fourth tab, and **See the full picture** on **Today** opens it too. It shows, for the catalogue you have open, where each [society](https://trackforge.studio/docs/cwr/glossary#society) is up to with your works and what each society's own records hold. Every figure on it opens the works behind it in the Catalogue, so the tab is both the picture and the way into the list. ## What you will see From the top of the screen down: - **The figures.** Five tiles: **Saved works**, **Needing response review**, **Registered differently**, **No history at a society** and **Not held by a society**. Choose a tile to open those works. A tile at nought opens nothing. - ****Where each society is up to**.** One row per society, with a bar split by status and one column per status, in the words the Catalogue's status filter uses. Choose a figure, or a part of the bar, to open the Catalogue filtered to that society and that status. See [What the statuses mean](https://trackforge.studio/docs/workspace/catalogue/statuses). - ****What each society holds**.** One row per society, with a bar split three ways and the figures **Held**, **Not held** and **Not checked**, counted from the newest reading of the society's records, and **How its position is found**. **Not checked** covers works with no reading yet and works the society does not deal in. Choose a figure, or a part of the bar, to open the Catalogue filtered to that society and that **Society position**. The bars appear once the catalogue holds ten works; below that the figures stand alone. - ****Add what you know**.** One line per society saying what TrackForge holds for it in this catalogue, in works: sent from here, with a file or reply you brought in, and with a reading of its records. Where something would add to the picture, the line says what and gives the button: **Bring in old files and replies** opens your registration history, **Prepare a file** opens the Catalogue. Only owners and editors see the buttons. - ****Society responses to review**.** The first responses that need correction or review, with what the society said. Choose a title to open the work. If there are more, **Open Files and responses** lists the rest. - ****From saved to accepted**.** The chart of one society's works from saved to answered, as on Today, once the catalogue holds ten works. The line under the title says when the figures were read. Choose the tab again to read them afresh. ## Take it with you The menu **Download report…** at the top right offers **Excel summary and full detail** and **PDF summary with charts**. Both are built from the same figures as the tab. The Excel report lists every work and society; the PDF has the tables with a bar per society. See [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history). ## Getting here - The tab **Registration health**, second from the left on every screen of a catalogue. - On **Today**, **See the full picture** under **Your catalogue in numbers**. - Step 5 of the **Get set up** card, **See what the societies hold**, whose button reads **See what they hold**. See [Your first file in six steps](https://trackforge.studio/docs/workspace/start-here). ## If something goes wrong - **Registration health could not be loaded.** Press **Try again**. - **The tab says the catalogue is too large.** The report covers up to 10,000 works and 200,000 work and society pairs. Make a smaller catalogue to see it. - **Every society reads Not checked.** No reading of any society's records exists yet. **Add what you know** says what would give one. ## Related - [What Today shows](https://trackforge.studio/docs/workspace/today/) - [Find, filter and sort works](https://trackforge.studio/docs/workspace/catalogue/find) - [Upload your registration history](https://trackforge.studio/docs/workspace/files/registration-history) --- *Source: [https://trackforge.studio/docs/workspace/registration-health](https://trackforge.studio/docs/workspace/registration-health)* --- ## docs/workspace/settings/society-logins.md # Logins societies issue > What MusicMark, SAMRO, CMRRA, HFA and other societies ask of a publisher before they issue an SFTP login for CWR files, and how to use that login in the Workspace. Many societies take CWR files on an SFTP server of their own and give each publisher a login. If a society has given you one, add it as a connection and the Workspace uses it. See [Society connections](https://trackforge.studio/docs/workspace/settings/society-connections). The Workspace does not apply for a login for you. Whatever a society asks for first, such as membership or a test file, is between you and the society. Once it has given you the login, enter it as it gave it to you: the username and password or key go on the same form as the server details, under **Your login for** the society, and **Save and test login** tests them before keeping them. A society no connection reaches, for example APRA, is listed in **Add a connection** with the line that you download the file and send it to the society yourself; if that society has given you an SFTP login for CWR files, you can still add it there. ## What every society gives you - A **username** and either a **password** or a **private key**. - The **server address**, and sometimes a port other than 22. - The **folders** to put files in and to collect its answers from. Where it names none, leave both as `/`. - Your **short code for filenames**: the 2 or 3 letters or digits your files are named with. ## MusicMark MusicMark takes CWR files for ASCAP, BMI and SOCAN in one place. Files sent to MusicMark are addressed to receiver code 707, which the Workspace fills in. - Your publisher must be a member or affiliate of ASCAP, BMI or SOCAN. MusicMark does not take files from members of other societies. - After you apply, MusicMark sets up your submitter folder and login. - MusicMark asks for a test file of up to 100 works on its test server before it issues the live login. Use the live login in the Workspace. - Each file must cover the World, North America, the US or Canada. The server address starts as `ftp.musicmark.com`. Change it only if MusicMark gave you another. Read more: [MusicMark: getting started](https://www.musicmark.com/documents/MusicMark_getting_started.pdf) and [MusicMark: questions and answers](https://www.musicmark.com/documents/MusicMark-FAQs.pdf). ## SAMRO Files sent to SAMRO are addressed to receiver code 063. - Your publisher must be a SAMRO publisher member. - SAMRO gives each publisher its own server address and login. It does not publish them, and it has changed them before, so enter the latest details SAMRO sent you. Read more: [SAMRO: publisher membership](https://samro.org.za/application/publisher/) and [SAMRO: support](https://www.samro.org.za/support). ## CMRRA CMRRA handles Canadian mechanical rights. Files sent to CMRRA are addressed to receiver code 088. - Your publisher needs a CMRRA account. - CMRRA sends the server address with the login. Files go in `/incoming` and CMRRA's answers come back in `/outgoing`, which the Workspace fills in. - CMRRA's guide calls its server FTP. The Workspace connects only over SFTP, which is encrypted, so ask CMRRA for SFTP access if your login does not work. Read more: [CMRRA: CWR help guide](https://cmrra.ca/help-centre/common-works-registration-cwr-help-guide/) and [CMRRA: sending and receiving CWR files](https://www.cmrra.ca/wp_super_faq/how-do-i-send-cwr-files-to-cmrra-how-do-i-receive-files-from-cmrra/). ## HFA HFA, part of SESAC, handles US mechanical rights. Files sent to HFA are addressed to receiver code 034. - Your publisher needs an HFA account. - Email cwrdelivery@sesac.com to set up CWR delivery. HFA then gives you a secure server address and login. Read more: [HFA: getting started with CWR file delivery](https://help.harryfox.com/what-is-cwr-and-how-do-i-get-started-with-cwr-file-delivery). ## Another society Choose **Another society** for any other society that gave you an SFTP login for CWR files. - Enter the society's name in **Society**. - Enter its three-digit code in **Receiver file code**, as the society gave it to you. 000 is not accepted here: it means a file for several societies. - Enter the server, port and folders exactly as the society gave them. ## Confirm the server the first time The first time you save or test the login for a new connection, the Workspace reaches the server but does not send your login yet. The tile shows **Confirm this server** with the server's fingerprint, a line starting `SHA256:`. 1. Check that the fingerprint matches the one the society gave you, or ask the society for it. 2. Press **Trust this server**. 3. Press **Test and save login** on the tile, or **Test connection** if your login is already saved. This time your login is sent. From then on, a test, a check for responses or a send stops if the server shows any other fingerprint. That way your login only ever goes to the server you confirmed. If you change the server address or port, you confirm the new server again. ## If the society changes its server Societies sometimes move to a new server. If the server shows a different fingerprint from the one you trusted, the test stops before your login is sent, and the tile shows **This server has changed** with the new fingerprint. 1. Ask the society whether its server changed, and for the new fingerprint. 2. If they match, press **Trust this server** and press **Test connection** again. If the society gave you a new server address too, change it with **Edit details** first, then confirm the new server as above. ## If something goes wrong - ****Save connection details** stays switched off.** The server address must be a name such as `sftp.society.org`, and each folder starts with `/`. For another society, the name and a three-digit receiver code are needed. - **The test says the server address is not a public address.** The name points inside a private network. Use the address the society gave you for the internet. - **The test says the society did not accept the login.** Check the username and password or key with the society. MusicMark's test-server login does not work on its live server. ## Related - [Society connections](https://trackforge.studio/docs/workspace/settings/society-connections) - [Societies](https://trackforge.studio/docs/workspace/settings/societies) - [Publisher details](https://trackforge.studio/docs/workspace/settings/publisher-details) --- *Source: [https://trackforge.studio/docs/workspace/settings/society-logins](https://trackforge.studio/docs/workspace/settings/society-logins)* --- # CWR Documentation --- ## docs/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. A complete guide to CWR structure, workflow, and versions. > 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." --- ## Check Your CWR Files The TrackForge CWR Workbench checks .V21 files against Common Works Registration 2.1 Revision 8. 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. - [Check a CWR file](https://trackforge.studio/cwr-tool) - [CWR Record Types Reference](https://trackforge.studio/docs/cwr/record-types) --- ## Related Documentation - **[CWR Record Types](https://trackforge.studio/docs/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. - **[Problems and fixes](https://trackforge.studio/docs/cwr/problems-and-fixes)** -- Every problem the CWR Workbench can report, why it matters and how to fix it. - **[CWR Workbench](https://trackforge.studio/cwr-tool)** -- Create a CWR 2.1 file, check or read an existing .V21 file, and understand society ACK responses. 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 Workbench](https://trackforge.studio/cwr-tool/workbench). Upload your .V21 file and check it against Common Works Registration 2.1 Revision 8. No account required. --- *Source: [https://trackforge.studio/docs/cwr/](https://trackforge.studio/docs/cwr)* --- *Source: [https://trackforge.studio/docs/cwr/](https://trackforge.studio/docs/cwr/)* --- ## docs/cwr/record-types.md # CWR Record Types -- A Complete Reference > A complete reference to CWR record types for music industry professionals. Covers file structure (HDR, GRT, TRL), work registration (NWR, REV), party records (SPU, SPT, SWR, SWT, PWR), share arithmetic, and version type codes. > 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 says whether the work is original or based on another work. It must be one of two codes, and a society rejects the work without one. | Code | Version Type | Description | |---|---|---| | `ORI` | Original Work | A work written from scratch. | | `MOD` | Modified Version | A work based on another, such as an arrangement, adaptation or translation. | A **MOD** work must also say what happened to the music and to the lyrics, each as a code from its table: | Music arrangement | Meaning | |---|---| | `ARR` | Arranged from the original music | | `NEW` | New music added to the original music | | `ADM` | New music written for existing lyrics | | `ORI` | Original music, unchanged | | `UNS` | Changed, details not known | | Lyric adaptation | Meaning | |---|---| | `TRA` | Translated into another language | | `MOD` | Changed in the same language | | `REP` | Replaced with new lyrics | | `NEW` | New lyrics added to the original lyrics | | `ADL` | New lyrics written for existing music | | `ORI` | Original lyrics, unchanged | | `NON` | No lyrics | | `UNS` | Changed, details not known | The writers must match the version type. A **MOD** work needs at least one SWR or OWR writer designated `AR` (arranger), `AD` (adaptor), `SR` (sub-arranger), `SA` (sub-author) or `TR` (translator), and an **ORI** work may have none of them. The CWR Workbench and the Workspace check all of this before they make a file: see [the problems and fixes](https://trackforge.studio/docs/cwr/problems-and-fixes#modified-version-writer). --- ## 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 | --- ## Check Your CWR Files The TrackForge CWR Workbench checks .V21 files against Common Works Registration 2.1 Revision 8 -- share arithmetic, record structure, field formatting, and cross-record consistency. Upload a file and get a detailed report in seconds. - [Open the CWR Workbench](https://trackforge.studio/cwr-tool) --- ## Related Documentation - **[CWR Workbench](https://trackforge.studio/cwr-tool)** -- Create, check and read CWR 2.1 .V21 files and understand society ACK responses. - **[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/docs/certification/overview/the-problem)** -- Why music rights data is broken and what TrackForge does about it. - **[What is CWR?](https://trackforge.studio/docs/cwr)** -- A complete guide to CWR structure, workflow, and versions. - **[Problems and fixes](https://trackforge.studio/docs/cwr/problems-and-fixes)** -- Every problem the CWR Workbench can report, why it matters and how to fix it. --- *Source: [https://trackforge.studio/docs/cwr/record-types](https://trackforge.studio/docs/cwr/record-types)* --- *Source: [https://trackforge.studio/docs/cwr/record-types](https://trackforge.studio/docs/cwr/record-types)* --- ## docs/cwr/glossary.md # Glossary > Plain-English definitions of the Common Works Registration (CWR) terms used in the Workbench and in this documentation. Common Works Registration (CWR) is the standard file format used to exchange musical-work registrations with collecting societies. A registration identifies the work, its writers and publishers, and the rights shares being declared. The Workbench creates and checks CWR 2.1 Revision 8 files and reads society acknowledgement responses. ## Common Works Registration (CWR) {#cwr} The standard file format publishers and collecting societies use to exchange musical-work registrations. ## Musical work (the composition or song, not its recording) {#work} A musical composition or song. One musical work can have many different sound recordings. ## New registration (CWR code: NWR) {#transaction_type_nwr} A registration sent for a musical work that has not previously been registered. ## Update to an existing registration (CWR code: REV) {#transaction_type_rev} A correction or update to a musical work that has already been registered. ## Society acknowledgement response (ACK) {#society_acknowledgement} The response file a society returns to report what happened to submitted registration transactions. ## Writer or publisher identity number (IPI) {#ipi} The Interested Parties Information identifier used to distinguish writers, publishers and other rights parties. Example: 00123456789 ## International work identifier (ISWC) {#iswc} The International Standard Musical Work Code assigned to a composition, not to a sound recording. Example: T-000.000.000-0 ## Recording identifier (ISRC) {#isrc_recording} The International Standard Recording Code assigned to a particular sound recording, not to the underlying musical work. Example: GBABC2600001 ## Performance-right, mechanical-right and synchronisation-right shares (PR/MR/SR) {#shares} Separate shares for performance, reproduction and synchronisation rights. Each right type must total 100% across the parties in a registration. ## Music publisher {#publisher} A party that owns, controls or administers rights in a musical work under an agreement with writers or another publisher. ## Original publisher (CWR publisher type: E) {#publisher_type_e} The original publisher in the work’s publisher chain. ## Administrator (CWR publisher type: AM) {#publisher_type_am} A publisher that administers rights on behalf of another rights holder. ## Sub-publisher (CWR publisher type: SE) {#publisher_type_se} A publisher appointed to collect or administer rights in specified territories. ## Controlled writer or publisher {#controlled} A rights party the submitting publisher directly represents for the right and territory being registered. ## Composer (CWR designation: C) {#writer_designation_c} A writer credited with composing the music. ## Author (CWR designation: A) {#writer_designation_a} A writer credited with writing the lyrics. ## Composer and author (CWR designation: CA) {#writer_designation_ca} A writer credited with both the music and the lyrics. ## Collecting society {#society} A collective management organisation (CMO) or performing rights organisation (PRO) that licenses rights and distributes royalties for its members or represented parties. ## Destination rules (recipient profile) {#recipient_profile} Additional generation or validation checks required by the society intended to receive the file. ## Society work reference (cross-reference) {#cross_reference} A society-assigned work number returned in an acknowledgement so the submission can be matched to the society’s records. --- *Source: [https://trackforge.studio/docs/cwr/glossary](https://trackforge.studio/docs/cwr/glossary)* --- ## docs/cwr/problems-and-fixes.md # Problems and fixes > Every problem the CWR Workbench can report, in plain English: what is wrong, why it matters, how to fix it and where to fix it. Every public Workbench issue is explained in plain English: what is wrong, why it matters, how to fix it and where to fix it in the Workbench. For the meaning of a CWR term, see the [glossary](https://trackforge.studio/docs/cwr/glossary). In the Workspace the same problems are listed on the work itself. Open the work, and each problem takes you to the field to correct. See [Fix problems on a work](https://trackforge.studio/docs/workspace/catalogue/fix-problems). ## Share errors ### The shares for a right do not add up to exactly 100%. {#shares-total} **Why it matters:** Incorrect share totals can prevent a work from being processed as intended. **How to fix it:** Adjust the writer and publisher shares for that right until the total is exactly 100%. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_shares_total` ### The collection shares for a right add up to more than 100% in a territory. {#collection-share-total} **Why it matters:** Collection is separate from ownership: it says who actually receives the money in a territory. If a writer keeps a collection share for a right they assigned to their publisher, both parties appear to claim the same money and the society rejects the registration. **How to fix it:** Check the writer's collection shares against what the writer actually owns. Where the publisher owns the right outright, the writer's collection share for it should be zero. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_nwr_tr14_collection_total` ### A writer or publisher share is outside the allowed 0% to 100% range. {#shares-range} **Why it matters:** An out-of-range share is not valid CWR ownership data and can prevent processing. **How to fix it:** Replace the share with a number from 0 to 100. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_share_out_of_range` ### A writer or publisher share is not a number. {#shares-format} **Why it matters:** CWR can only carry numeric shares, so the work cannot be processed reliably with this value. **How to fix it:** Enter a number such as 50 for a 50% share. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_share_non_numeric` ### A global publisher territory is missing or changes the publisher's synchronization collection share. {#cmrra-collection-allocation} **Why it matters:** CMRRA expects the publisher's worldwide territory to retain the publisher's applicable synchronization share. **How to fix it:** Select the CMRRA recipient profile and regenerate the file so the publisher synchronization share remains on the publisher's worldwide territory. **Where to fix it in the Workbench:** Generate → Recipient society **Rule:** `cwr_21_cmrra_spt_sr_collection` ### A zero-ownership publisher role has a positive global synchronization collection share whose CMRRA allocation is not yet proven. **Why it matters:** Ownership and collection are separate in CWR, so replacing this explicit collection value with zero could discard a genuine collection mandate. **How to fix it:** Review the publisher chain and authoritative CMRRA collection evidence before generating this delivery. **Where to fix it in the Workbench:** Generate → Publishers and territories **Rule:** `cwr_21_cmrra_zero_ownership_spt_sr_collection_unresolved` ### A writer territory assigns mechanical collection to a field that CMRRA requires to be zero. **Why it matters:** CMRRA expects the applicable mechanical collection on the publisher territory, so this allocation can prevent correct processing. **How to fix it:** Select the CMRRA recipient profile and regenerate the file so the mechanical collection is carried on the publisher territory. **Where to fix it in the Workbench:** Generate → Recipient society **Rule:** `cwr_21_cmrra_swt_mr_collection` ### A writer territory assigns synchronization collection to a field that CMRRA requires to be zero. **Why it matters:** CMRRA's delivery allocation must be represented correctly for the work to be processed as intended. **How to fix it:** Select the CMRRA recipient profile and regenerate the file; TrackForge will correct this delivery allocation without changing ownership. **Where to fix it in the Workbench:** Generate → Recipient society **Rule:** `cwr_21_cmrra_swt_sr_collection` ### An acquiring publisher has no ownership share. {#acquirer-share} **Why it matters:** An acquirer is listed because it now owns rights in the work. With every ownership share at zero the society cannot tell what it acquired. **How to fix it:** Give the acquiring publisher the ownership shares it took over from the original publisher. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_5_5_5_spu_acquirer_share` ### A publisher chain owns nothing. {#publisher-chain-ownership} **Why it matters:** Each publisher chain must own part of at least one right, or the society cannot work out what that chain is registering. **How to fix it:** Give the original publisher or the acquirer in that chain its ownership share, or remove the chain. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_nwr_tr25_chain_ownership` ### The original publisher keeps an ownership share in a chain with an acquirer. {#acquirer-original-share} **Why it matters:** When an acquirer takes over a chain, the ownership moves to the acquirer. Leaving shares on the original publisher claims the same rights twice. **How to fix it:** Move the original publisher's ownership shares to the acquiring publisher and set the original publisher's shares to zero. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_nwr_tr26_acquirer_original_share` ### A publisher that cannot own a share has one. {#publisher-zero-ownership} **Why it matters:** Some publisher roles only administer or sub-publish and own nothing. A share on one of them claims ownership the society will not accept. **How to fix it:** Set this publisher's ownership shares to zero, or change its role if it really owns part of the work. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_spu_field_19_zero_ownership` ### Publishers hold more than half of the performing right. {#publisher-performing-total} **Why it matters:** Performing-right societies keep at least half of the performing right for writers, so a registration giving publishers more is rejected. **How to fix it:** Reduce the publishers' performing shares to 50% or less in total and give the rest to the writers. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_nwr_tr4_publisher_pr_total` ### Writers hold less than half of the performing right. {#writer-performing-total} **Why it matters:** Performing-right societies expect writers to hold at least half of the performing right, unless the writers hold none of it. **How to fix it:** Raise the writers' performing shares to at least 50% in total, taking the difference from the publishers. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_nwr_tr9_writer_pr_total` ### A publisher chain has no original publisher or acquirer with an ownership share. {#chain-no-ownership} **Why it matters:** Each publisher chain starts from a publisher that owns part of the work. The publishers below it collect on that owner's behalf. **How to fix it:** Enter ownership shares for the original publisher or the acquirer in the chain, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_chain_no_ownership` ### An original publisher keeps an ownership share in a chain that has an acquirer. {#chain-original-share-with-acquirer} **Why it matters:** An acquirer takes over the original publisher's ownership, so the original publisher is listed with no share. **How to fix it:** Set the original publisher's ownership shares to zero and enter them for the acquirer, or change the acquirer's role. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_chain_original_share_with_acquirer` ### An acquirer has no ownership share. {#chain-acquirer-no-ownership} **Why it matters:** An acquirer owns the rights it acquired, so it holds a share of at least one right. **How to fix it:** Enter the acquirer's ownership shares, or change its role if it owns no share. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_chain_acquirer_no_ownership` ### A publisher includes a territory where it collects nothing. {#publisher-territory-no-collection} **Why it matters:** An included territory tells societies where a publisher collects. With no collection share it says nothing, so it cannot go in the file. **How to fix it:** Enter the publisher's collection shares for the territory, remove the territory, or exclude it instead. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_publisher_territory_no_collection` ### A publisher's territory rows both collect the same right in one territory. {#publisher-territory-rows-collect-twice} **Why it matters:** Rows for one publisher that split the rights between them must give each right in a territory on one row. Two rows collecting the same right there would put the publisher in the file twice for it. **How to fix it:** Keep the right on one of the rows for that territory, and type 0 for it on the other row. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_publisher_territory_rows_collect_twice` ### A publisher's rows split the rights between them, and one row leaves a right blank that another row gives. {#publisher-territory-row-blank-right} **Why it matters:** A blank cell usually means the publisher's whole share. Where another of its rows gives that right, the blank could also mean the publisher does not collect it there, and the file cannot say which. **How to fix it:** Type the right on that row: 0 if the publisher does not collect it there, or the share it collects. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_publisher_territory_row_blank_right` ### A publisher has more than one row for one territory with different collection shares. {#publisher-territory-conflicting-shares} **Why it matters:** Each row becomes its own record in the file. Records for the same publisher and territory with different shares contradict each other, and a society cannot tell which share applies. **How to fix it:** Keep one row for the territory, or combine the rows into one row that carries every share the publisher collects there. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_publisher_territory_conflicting_shares` ### A writer includes a territory where the writer collects nothing. {#writer-territory-no-collection} **Why it matters:** An included territory tells societies where a writer collects. With no collection share it says nothing, so it cannot go in the file. **How to fix it:** Enter the writer's collection shares for the territory, remove the territory, or exclude it instead. **Where to fix it in the Workbench:** Generate → Work details → Writer territories **Rule:** `cwr_21_writer_territory_no_collection` ## Identity errors ### A work is missing its stable Submitter Work ID. {#submitter-work-id} **Why it matters:** The recipient returns this identity in its acknowledgement, and later revisions must use the same value to target the same work. **How to fix it:** Enter a stable catalogue identifier that will not change when the title changes. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields **Rule:** `cwr_21_submitter_work_id_missing` ### A Submitter Work ID uses a format the recipient cannot process. **Why it matters:** An invalid identity can be rejected or returned in an unusable ACK, breaking safe correlation and revision handling. **How to fix it:** Use 1–14 letters or numbers with no spaces; keep the same value for later revisions. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields **Rule:** `cwr_21_submitter_work_id_format` ### Two works in the file use the same Submitter Work ID. **Why it matters:** A duplicate makes the recipient ACK ambiguous and can attach a revision or rejection to the wrong catalogue work. **How to fix it:** Assign a different stable Submitter Work ID to each work in the file. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields **Rule:** `cwr_21_submitter_work_id_duplicate` ### An agreement number is longer than 14 characters or has characters a CWR file cannot carry. {#agreement-number} **Why it matters:** A CWR file holds an agreement number in 14 plain characters. A longer or accented number would reach the society changed, so it could not be matched to your agreement. **How to fix it:** Enter the agreement number exactly as it was issued: up to 14 letters, numbers and basic punctuation, with no accents. If the number you were given is longer, check it with whoever issued it. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_agreement_number_format` ### An IPI base number is not in the form I-001068130-6: the letter I, nine digits and one more digit, joined by hyphens. {#ipi-base-number} **Why it matters:** An IPI base number is always 13 characters, and a CWR file holds exactly those 13. A longer or differently written number would reach the society changed, so TrackForge will not cut or alter it. **How to fix it:** Enter the IPI base number exactly as the society shows it, for example I-001068130-6, or leave it empty: the number is optional. It is not the 11-digit IPI name number, which has its own box. **Where to fix it in the Workbench:** Work details → Performers **Rule:** `cwr_21_ipi_base_number_format` ### A value in this file has a character a CWR file cannot carry. {#plain-text-file} **Why it matters:** A CWR file is plain text. TrackForge stopped rather than write a file a society could not read. **How to fix it:** Look for accents or symbols in identifiers such as reference and agreement numbers, replace them, and generate the file again. **Where to fix it in the Workbench:** Generate → Work details **Rule:** `cwr_21_file_not_plain_text` ### A writer or publisher IPI name number is not in a valid numeric format. {#ipi-invalid} **Why it matters:** A valid IPI helps the recipient match the correct rights-holder and registration account. **How to fix it:** Check the IPI name number against society records and enter 9 to 11 digits without spaces or punctuation. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_ipi_invalid` ### A writer and publisher use the same IPI name number. {#ipi-party-type} **Why it matters:** Recipients use the IPI registry to distinguish writer persons from publisher organizations. Reusing one IPI across both roles can make the writer role invalid and cause the work to be rejected. **How to fix it:** Replace the duplicated value with the verified IPI assigned to each party. If the writer's IPI is unknown, leave it blank rather than using the publisher organization's IPI. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_cross_role_ipi` ### The sender ID is not a valid CWR sender code or publisher IPI name number. {#sender-id} **Why it matters:** The sender identity tells the recipient who supplied the file and which account owns the submission. **How to fix it:** Enter the full society-issued sender code or publisher IPI name number without spaces or punctuation. **Where to fix it in the Workbench:** Generate → Sender details **Rule:** `cwr_21_sender_id_invalid` ### The sender ID appears to be a shortened version of the publisher IPI name number. **Why it matters:** A shortened identity can point the submission at the wrong account or prevent the sender from being matched. **How to fix it:** Copy the publisher's complete IPI name number into Sender ID; TrackForge will place it into the fixed-width header correctly. **Where to fix it in the Workbench:** Generate → Sender details **Rule:** `cwr_21_hdr_sender_id_truncated` ### The sender ID is still the example placeholder rather than a real society-issued identity. **Why it matters:** A placeholder cannot identify the party responsible for the submission. **How to fix it:** Replace the example with your society-issued sender code or publisher IPI name number. **Where to fix it in the Workbench:** Generate → Sender details **Rule:** `cwr_21_sender_id_placeholder` ### For a file to AllTrack: no publisher you control on a work has an IPI. {#alltrack-publishers-without-ipi} **Why it matters:** AllTrack finds the submitting publisher on each work by the IPI in the file's header. With no IPI on any of your publishers it finds you holding nothing and rejects the work. **How to fix it:** Add the IPI to the publisher you send the file as, on each work. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_alltrack_publishers_without_ipi` ### For a file to AllTrack: the sender's IPI is on none of a work's publishers. {#alltrack-sender-not-on-work} **Why it matters:** AllTrack finds the submitting publisher on each work by the IPI in the file's header. The files AllTrack accepts carry that IPI on one of the work's publishers; without it AllTrack can reject the work as if you held nothing. **How to fix it:** Send the file as a publisher you control on the work, or check that publisher's IPI. **Where to fix it in the Workbench:** Generate → Submitter **Rule:** `cwr_21_alltrack_sender_not_on_work` ### A publisher you control on a work has no IPI. {#controlled-publisher-without-ipi} **Why it matters:** Societies match a publisher on a work by its IPI. Without it a society may not link the work to you. CWR 2.2 requires the IPI of the publisher sending the file, and AllTrack already rejects a work on which none of your publishers has one. **How to fix it:** Add the IPI to each publisher you control. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_controlled_publisher_without_ipi` ### One publisher you control has different IPIs on different works. {#controlled-publisher-ipis-differ} **Why it matters:** One publisher has one IPI. Two IPIs for one name usually mean one was typed or copied wrongly, and societies match a publisher by its IPI, not its name. **How to fix it:** Check which IPI is right and correct the others, or give two different companies names that tell them apart. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_controlled_publisher_ipis_differ` ### A writer or publisher appears more than once with no IPI, so it is sent as one party. {#name-only-party-repeated} **Why it matters:** Without an IPI, the file can only tell parties apart by name. Two different people or companies with the same name would be sent as one. **How to fix it:** If they are different people or companies, add each one's IPI. **Where to fix it in the Workbench:** Generate → Work details → Writers and publishers **Rule:** `cwr_21_name_only_party_repeated` ### No agreement number is given for any publisher you control. {#agreement-number-missing} **Why it matters:** Without an agreement number, PRS and MCPS register your claim as one you state rather than one backed by an agreement, and societies in other countries may not accept it. **How to fix it:** Add your agreement number to each publisher you control (Submitter Agreement # in the Workbench, Your agreement reference in the workspace), then check again. This is a warning: the file can be made without it. **Where to fix it in the Workbench:** Generate → Publishers → Submitter Agreement # **Rule:** `cwr_21_ice_assumed_claim_no_agreement` ### A CAPASSO file includes a sub-publisher or publishing administrator whose external CAPASSO relationship cannot be verified here. {#capasso-linked-party-affiliation} **Why it matters:** CAPASSO accepts a sub-publisher or publishing administrator only when that party is directly affiliated with, or linked to, CAPASSO. An unconfirmed relationship can cause the registration to be rejected. **How to fix it:** Confirm the CAPASSO affiliation or link for every sub-publisher and publishing administrator before submitting the file. **Where to fix it in the Workbench:** Your CAPASSO affiliation or agreement records, before submission **Rule:** `cwr_21_capasso_linked_party_affiliation_unverified` ### The sender name is missing. {#sender-name} **Why it matters:** The recipient needs the sender name to identify who supplied the registration file. **How to fix it:** Enter the company or publisher name exactly as it appears in society records. **Where to fix it in the Workbench:** Generate → Sender details **Rule:** `cwr_21_sender_name_blank` ### The selected sender type is not supported by the Workbench generator. {#sender-type} **Why it matters:** The Workbench must encode a supported sender identity before it can build a valid header. **How to fix it:** Choose Publisher (PB) as the sender type. **Where to fix it in the Workbench:** Generate → Sender details **Rule:** `cwr_21_sender_type_invalid` ### A writer is missing a name. {#writer-name} **Why it matters:** A work cannot be registered reliably without identifying each writer. **How to fix it:** Enter the writer's last name and, where available, first name. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_writer_name_blank` ### A publisher is missing a name. {#publisher-name} **Why it matters:** The recipient needs the publisher name to identify and route the claimed interest. **How to fix it:** Enter the publisher name exactly as it appears in society records. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_publisher_name_blank` ### The same writer appears more than once on one work. {#duplicate-writer} **Why it matters:** Duplicate writer rows can double-count shares or create conflicting identities. **How to fix it:** Keep one row for the writer and combine any duplicated shares into that row. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_duplicate_writer` ### A publisher record does not have a consistent, unique interested-party identifier. {#publisher-identity} **Why it matters:** Publisher territory and writer-link records use this identifier to attach rights to the correct publisher. **How to fix it:** Regenerate the file so each publisher has one unique identifier that is repeated on its related territory and writer-link records. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_5_5_5_spu_interested_party` ### A publisher's society is not a society code. **Why it matters:** A CWR file names each society by its code. A value that is not one tells the receiving organisation nothing about where to send the share, so the work cannot be registered. **How to fix it:** Choose the publisher's society by name for each right it holds a share of, then generate again. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `publisher.society.invalid` ### A writer's society is not a society code. **Why it matters:** A CWR file names each society by its code. A value that is not one tells the receiving organisation nothing about the writer's membership, so the work cannot be registered. **How to fix it:** Choose the writer's society by name, or leave it blank if it is unknown, then generate again. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `writer.society.invalid` ### A writer record does not have a consistent, unique interested-party identifier. {#writer-identity} **Why it matters:** Writer territory and publisher-link records use this identifier to attach rights to the correct writer. **How to fix it:** Regenerate the file so each writer has one unique identifier that is repeated on related territory and publisher-link records. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_5_9_4_swr_interested_party` ### A recording ISRC is not a valid ISRC. {#recording-isrc-invalid} **Why it matters:** An ISRC has 12 characters: a two-letter country code, a three-character registrant code, the last two digits of the year and a five-digit number. Societies use it to link recordings to the work, so an invalid one is rejected. **How to fix it:** Correct the recording's ISRC from the label's or distributor's records, or leave it blank. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → ISRC **Rule:** `cwr_21_recording_isrc_invalid` ## Structure errors ### For a file to AllTrack: a publisher's territories are not the territory of the AllTrack account chosen. {#alltrack-account-territory} **Why it matters:** AllTrack applies one territory to the whole account, so it cannot take excluded countries or a mix of worldwide and single countries. Overlapping territories can also count mechanical shares twice. **How to fix it:** Check that the AllTrack account chosen, US-only or worldwide, is the one in your agreement. A file made in TrackForge for that account writes the account's territory for each publisher for you: the United States for the US-only account, the whole world for the worldwide account. In a file made elsewhere, give each publisher named that territory alone. **Where to fix it in the Workbench:** Generate → Destination rules **Rule:** `cwr_21_alltrack_account_territory_scope` ### For a file to AllTrack: a publisher covers only part of the territory of the AllTrack account chosen. {#alltrack-account-territory-partial} **Why it matters:** AllTrack applies one territory to the whole account and cannot take excluded countries, so the file cannot give this publisher's territories truthfully for that account. **How to fix it:** Choose the AllTrack account, worldwide or US-only, that matches the publisher's agreement. TrackForge then writes that account's territory in the file for each publisher that covers it. Your saved territories do not change, so files for other societies stay as they are. **Where to fix it in the Workbench:** Generate → Destination rules **Rule:** `cwr_21_alltrack_account_territory_partial` ### For a file to AllTrack: no publisher you control collects in the territory of the AllTrack account chosen. {#alltrack-account-territory-uncollected} **Why it matters:** AllTrack applies one territory to the whole account, and the file leaves out each publisher that collects nothing there. **How to fix it:** Check that the AllTrack account chosen, US-only or worldwide, is the one in your agreement, or leave this work out of the file. **Where to fix it in the Workbench:** Generate → Destination rules **Rule:** `cwr_21_alltrack_account_territory_uncollected` ### For a file to AllTrack: more than one publisher collects the same right in the territory of the AllTrack account chosen. {#alltrack-one-publisher-per-right} **Why it matters:** AllTrack takes one publisher for each right: the one that collects in the account's territory. A file showing two publishers sharing a right there is not accepted. **How to fix it:** Check the territories and collection shares of each publisher named. If only one of them collects in the account's territory, correct the others. If they do share it, leave this work out of the AllTrack file and ask AllTrack how they want it registered. **Where to fix it in the Workbench:** Writers/Publishers → Territories **Rule:** `cwr_21_alltrack_one_publisher_per_right` ### For a file to CAPASSO: CAPASSO takes Africa only, and a territory on this work says something else. {#capasso-africa-territory} **Why it matters:** CAPASSO accepts Africa-only territories for writers and publishers, so a worldwide or other territory can register the wrong territory with CAPASSO or get the work rejected. This applies only to files sent to CAPASSO. It does not mean rights in Africa have to be collected through CAPASSO. **How to fix it:** If CAPASSO does not collect for you, do not send this file to CAPASSO: in the Workspace, remove CAPASSO from your societies in Workspace settings. For a file to CAPASSO, on the party named, remove the territory rows that do not match (for example World), or replace them: Africa for a publisher or a writer. A publisher can also list the 54 African countries, each once. With no rows, TrackForge fills in the right ones for CAPASSO. In the Workbench, also choose CAPASSO — Africa administration under Destination rules. **Where to fix it in the Workbench:** Generate → Destination rules and Writers/Publishers → Territories **Rule:** `cwr_21_capasso_africa_territory_scope` ### A modified version has no arranger, adaptor or translator among its writers. {#modified-version-writer} **Why it matters:** Societies reject a modified version unless a writer is credited for the change, as an arranger, adaptor, translator, sub-arranger or sub-author. **How to fix it:** Add the person who arranged, adapted or translated the work, with that role. If the work wasn't changed, mark it as an original work instead. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_modified_no_version_writer` ### An original work credits an arranger, adaptor or translator. {#original-version-writer} **Why it matters:** Societies reject an original work with an arranger, adaptor, translator, sub-arranger or sub-author; those roles belong to a modified version. **How to fix it:** Mark the work as a modified version if it's an arrangement, adaptation or translation. Otherwise change that writer's role. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Version **Rule:** `cwr_21_original_has_version_writer` ### A work has no writer credited as its composer or author. {#composer-or-author} **Why it matters:** Societies reject a work unless at least one writer is credited as composer, author or composer/author. An arranger, adaptor or translator alone isn't enough. **How to fix it:** Give the person who wrote the music or the words the role Composer, Author or Composer/Author. For a modified version, also add the writers of the original work. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_no_creator_writer` ### A work has no writers. {#no-writers} **Why it matters:** At least one writer is required to identify the authorship being registered. **How to fix it:** Add each person who composed the music or wrote the lyrics. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_no_writers` ### A performer has no name. {#performer-name} **Why it matters:** Each performer in the file must be named. **How to fix it:** Enter the performer’s name, or remove the empty performer. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Performer / Artist **Rule:** `artist.name_missing` ### A new work registration has no publisher. {#missing-publisher} **Why it matters:** The generator needs a publisher interest to represent who is administering the new registration. **How to fix it:** Add the administering publisher, or record the appropriate writer as self-published. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_missing_publisher` ### A writer is missing their role in creating the work. {#writer-designation} **Why it matters:** The writer designation is required to describe whether the party composed, authored or adapted the work. **How to fix it:** Choose the writer's role, commonly Composer (C), Author (A) or Composer/Author (CA). **Where to fix it in the Workbench:** Generate → Work details → Writers → Role **Rule:** `cwr_21_writer_designation_blank` ### A writer's role is not one a CWR file can carry. {#writer-role-code} **Why it matters:** Societies reject a work whose writer role is not a code from the CISAC writer role table, because the role decides how the writer is paid. **How to fix it:** Choose the writer's role from the list: Composer, Author, Composer/Author, Arranger, Adaptor, Translator, Sub-author or Sub-arranger. In a spreadsheet, write the role's name or its code. **Where to fix it in the Workbench:** Generate → Work details → Writers → Role **Rule:** `cwr_21_writer_designation_invalid` ### A publisher has an unsupported relationship type. {#publisher-type} **Why it matters:** The relationship type determines how the publisher is represented in the CWR ownership chain. **How to fix it:** Choose the relationship that matches the agreement: Original Publisher, Publisher Administrator, Acquirer, Sub-publisher or another supported type. **Where to fix it in the Workbench:** Generate → Work details → Publishers → Relationship **Rule:** `cwr_21_publisher_type_invalid` ### There are no works in the generation request. {#no-works} **Why it matters:** A CWR registration file needs at least one work transaction. **How to fix it:** Add a work manually or import one or more works from CSV. **Where to fix it in the Workbench:** Generate → Works **Rule:** `cwr_21_no_works` ### A publisher record has an invalid field or lacks a society code for a claimed right. {#publisher-society} **Why it matters:** Without valid publisher identity and routing data, the claimed interest may not be processed correctly. **How to fix it:** Add the publisher's three-digit society code for each claimed right, correct any other reported field, and regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_5_4_4_spu_field_validation` ### A publisher holds a share of a right but has no society for that right. **Why it matters:** The society tells the receiving organisation where to send that share. Without one the share has nowhere to go, so the work cannot be registered. **How to fix it:** Choose the publisher's society for each right it holds a share of, or set that share to zero, then generate again. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `publisher.society.missing` ### An uncontrolled writer claims a share without a society code or a link to a controlling publisher. {#writer-society} **Why it matters:** The recipient needs either the writer's society routing or a publisher link to understand who administers the claimed share. **How to fix it:** Add the writer's society code, or add the publisher-writer link that identifies the controlling publisher, then regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Writers and publisher links **Rule:** `cwr_21_5_10_3_swr_record_validation` ### A controlled writer holds a share of a right, but neither the writer nor the writer's publisher has a society for that right. **Why it matters:** The society tells the receiving organisation where to send that share. Without the writer's society, or one on the writer's publisher, the share has nowhere to go, so the work cannot be registered. **How to fix it:** Choose the writer's society for that right, or the society of the publisher that collects it, then generate again. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `writer.society.missing` ### A territory entry is not one societies recognise. {#territory-unknown} **Why it matters:** Societies route collection by territory, so each entry must be a country, a region or a list they recognise. TrackForge reports the entry instead of guessing a territory or treating it as worldwide. **How to fix it:** Replace the territory with a country or region name, a list of countries, or a worldwide entry with exclusions, then check again. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_territory_unknown` ### A territory entry is a territory that no longer exists. {#territory-inactive} **Why it matters:** Retired territories such as the Soviet Union or Yugoslavia no longer exist in the territory list societies use, so they cannot register or route collection for them. **How to fix it:** Replace the retired territory with the current countries you collect in, then check again. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_territory_inactive` ### A publisher territory record has an invalid territory, collection share or inclusion setting. {#publisher-territory} **Why it matters:** Publisher territory records define where and for which rights the publisher collects. **How to fix it:** Check the publisher's territory, inclusion or exclusion setting, and collection shares, then regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Publisher territories **Rule:** `cwr_21_5_7_3_spt_record_validation` ### A publisher territory field is invalid or does not match its publisher. **Why it matters:** A territory must link to the correct publisher and contain valid shares and territory data to be processed reliably. **How to fix it:** Correct the publisher link, collection shares or territory code reported for the territory, then regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Publisher territories **Rule:** `cwr_21_5_7_4_spt_field_validation` ### A writer territory record has an invalid territory, collection share or inclusion setting. {#writer-territory} **Why it matters:** Writer territory records define where and for which rights the writer collects. **How to fix it:** Check the writer's territory, inclusion or exclusion setting, and collection shares, then regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Writer territories **Rule:** `cwr_21_5_11_3_swt_record_validation` ### A writer territory field is invalid or does not match its writer. **Why it matters:** A territory must link to the correct writer and contain valid shares and territory data to be processed reliably. **How to fix it:** Correct the writer link, collection shares or territory code reported for the territory, then regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Writer territories **Rule:** `cwr_21_5_11_4_swt_field_validation` ### A publisher-writer relationship does not link to valid publisher and writer identities in the same work. {#publisher-writer} **Why it matters:** The relationship tells the recipient which publisher controls the writer's interest. **How to fix it:** Correct the publisher and writer links so both refer to parties in the same work, then regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Publisher-writer links **Rule:** `cwr_21_5_12_2_pwr_record_validation` ### A controlled-writer record appears after an uncontrolled writer. {#writer-record-order} **Why it matters:** CWR recipients process controlled-writer records before other writers and can reject the whole work when those blocks are reversed. **How to fix it:** Regenerate the file so all controlled writers and their territory and publisher links appear before uncontrolled writers. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_nwr_tr18_record_order` ### A publisher chain is out of order or starts with the wrong kind of publisher. {#publisher-chain-order} **Why it matters:** Each chain must start with an original publisher or income participant and be numbered 1, 2, 3 in order, or the society cannot tell which publishers belong together. **How to fix it:** Start each publisher chain with the original publisher and number the chains in order with no gaps. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_5_5_5_spu_chain_role` ### An acquiring publisher is not preceded by the original publisher in its chain. {#acquirer-follows-original} **Why it matters:** An acquirer takes rights over from an original publisher, so the society rejects a chain where the acquirer has nobody to take the rights from. **How to fix it:** Add the original publisher at the start of the chain, ahead of the acquiring publisher. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_5_5_6_spu_acquirer_follows_original` ### A publisher chain does not start with an original publisher or income participant. {#chain-first-publisher-role} **Why it matters:** Societies read each chain from the publisher that holds the rights. A sub-publisher, administrator or acquirer can only appear below that publisher. **How to fix it:** Start the chain with the original publisher and link the other publishers below it. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_chain_first_publisher_role` ### A publisher chain has more than one original publisher. {#chain-second-original-publisher} **Why it matters:** Societies read each chain from its one original publisher. A second original publisher starts a chain of its own. **How to fix it:** Give the second original publisher its own chain, or change its role if it acts for the first publisher. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_chain_second_original_publisher` ### An acquirer does not follow an original publisher in its chain. {#chain-acquirer-without-original} **Why it matters:** An acquirer is listed after the original publisher whose rights it acquired. **How to fix it:** Put the original publisher first in the chain with the acquirer below it, or change the acquirer's role. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_chain_acquirer_without_original` ### A publisher's territory rows overlap without one lying inside the other. {#publisher-territory-rows-not-nested} **Why it matters:** Rows that split the rights are written as one set of territories, each inside the one before it. Areas that only partly overlap cannot be written that way. **How to fix it:** Name the areas so each lies inside another or does not touch it. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_publisher_territory_rows_not_nested` ### A publisher excludes territories but includes none where it collects. {#exclusions-without-collection} **Why it matters:** An exclusion takes a territory out of an area where the publisher collects. With no such area there is nothing to take it from. **How to fix it:** Add the territory where the publisher collects, with its collection shares, or remove the excluded territories. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_publisher_exclusions_without_collection` ### Two publishers you control collect the same right in the same territory. {#publisher-collection-overlap} **Why it matters:** Only one of your publishers can collect each right in a territory. Overlapping territories leave it unclear who should be paid, so societies reject the registration. **How to fix it:** Change one publisher's territories so no right is collected twice in the same territory. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_publisher_collection_overlap` ### A territory is attached to a publisher you do not control. {#opu-territory-scope} **Why it matters:** A registration lists territories only for the publishers you control. Where an outside publisher collects is for that publisher to register. **How to fix it:** Attach the territory to a publisher you control, or remove it, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Territories **Rule:** `cwr_21_opu_territory_scope` ## Format errors ### The International Standard Musical Work Code (ISWC) is not in the expected format. {#iswc-format} **Why it matters:** A malformed ISWC cannot reliably match the work to its existing international registration. **How to fix it:** Check the ISWC against society records and enter it as a T followed by 10 digits, with no dots or dashes. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → ISWC **Rule:** `cwr_21_iswc_format` ### The International Standard Musical Work Code (ISWC) has the wrong final check digit. {#iswc-check-digit} **Why it matters:** An incorrect check digit means the identifier does not validate and may not match the intended work. **How to fix it:** Copy the complete ISWC again from an authoritative society record. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → ISWC **Rule:** `cwr_21_iswc_check_digit` ### A work is missing its title. {#title-blank} **Why it matters:** The title is a mandatory work identity field used to process and match the registration. **How to fix it:** Enter the work's registered title. **Where to fix it in the Workbench:** Generate → Work details → Title **Rule:** `cwr_21_title_blank` ### A work duration is not in hours, minutes and seconds format. {#duration-format} **Why it matters:** A malformed duration cannot be encoded correctly in the fixed-width CWR record. **How to fix it:** Enter the duration as HH:MM:SS, for example 00:03:45. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Duration **Rule:** `cwr_21_duration_invalid` ### A work duration is set to zero. {#duration-zero} **Why it matters:** A zero duration can be mistaken for known zero-length data rather than an unknown value. **How to fix it:** Enter the actual duration, or clear the field when the duration is unknown. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Duration **Rule:** `cwr_21_duration_zero` ### A work language is not a recognised two-letter code. {#language-code} **Why it matters:** An unrecognised language code cannot be interpreted consistently by the recipient. **How to fix it:** Choose a recognised two-letter language code such as EN, ES, FR or DE. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Language **Rule:** `cwr_21_language_invalid` ### A work has an unsupported version type. {#version-type} **Why it matters:** The version type tells the recipient whether this is the original work or a modified version. **How to fix it:** Choose Original for the first version or Modified for an arrangement, translation or adaptation. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Version **Rule:** `cwr_21_version_invalid` ### A modified version doesn't say what happened to its music. {#music-arrangement-missing} **Why it matters:** Societies reject a modified version that doesn't say whether its music was arranged, added to or kept as it was. **How to fix it:** Choose what happened to the music: arranged, new music added, music written for existing lyrics, or kept as it was. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Version **Rule:** `cwr_21_music_arrangement_missing` ### A modified version doesn't say what happened to its lyrics. {#lyric-adaptation-missing} **Why it matters:** Societies reject a modified version that doesn't say whether its lyrics were translated, changed, replaced or kept as they were, or that it has none. **How to fix it:** Choose what happened to the lyrics: translated, changed, replaced, added to, kept as they were, or no lyrics. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Version **Rule:** `cwr_21_lyric_adaptation_missing` ### A work has an unrecognised entry for what happened to its music. {#music-arrangement-invalid} **Why it matters:** Societies accept only their listed choices for what happened to a modified version's music. **How to fix it:** Choose one of the listed options for what happened to the music. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Version **Rule:** `cwr_21_music_arrangement_invalid` ### A work has an unrecognised entry for what happened to its lyrics. {#lyric-adaptation-invalid} **Why it matters:** Societies accept only their listed choices for what happened to a modified version's lyrics. **How to fix it:** Choose one of the listed options for what happened to the lyrics. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Version **Rule:** `cwr_21_lyric_adaptation_invalid` ### A writer record contains an invalid field or society code. **Why it matters:** Invalid writer identity or routing data can prevent the writer's interest from being processed correctly. **How to fix it:** Correct the reported writer field and use the writer's three-digit society code, then regenerate the file. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_5_10_4_swr_field_validation` ### The first recording refusal answer is missing. {#first-recording-refusal} **Why it matters:** MCPS and PRS need to know whether the right to refuse a first recording is held back before they accept the registration. **How to fix it:** Answer yes or no for first recording refusal on every controlled writer and publisher, then validate the file again. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_mcps_prs_first_recording_refusal` ### A work title uses only characters a CWR file cannot carry. {#title-unrepresentable} **Why it matters:** CWR files carry titles in Latin letters, digits and basic punctuation. Characters from other scripts, such as Cyrillic or Japanese, are left out, and a work cannot be registered without a title. **How to fix it:** Enter the work title in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Title **Rule:** `cwr_21_title_unrepresentable` ### A work title has letters a CWR file cannot carry. {#title-letters-unrepresentable} **Why it matters:** CWR files carry titles in Latin letters, digits and basic punctuation. Accented letters are written as plain letters, but letters from other scripts, such as Cyrillic, Greek or Japanese, would be left out, so the society would register the work under the wrong title. **How to fix it:** Enter the work title in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Title **Rule:** `cwr_21_title_letters_unrepresentable` ### A writer's last name uses only characters a CWR file cannot carry. {#writer-name-unrepresentable} **Why it matters:** CWR files carry names in Latin letters, digits and basic punctuation. Characters from other scripts, such as Cyrillic or Japanese, are left out, and a writer cannot be identified without a name. **How to fix it:** Enter the writer's last name in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_writer_name_unrepresentable` ### A publisher name uses only characters a CWR file cannot carry. {#publisher-name-unrepresentable} **Why it matters:** CWR files carry names in Latin letters, digits and basic punctuation. Characters from other scripts, such as Cyrillic or Japanese, are left out, and the society needs the publisher's name to identify the claim. **How to fix it:** Enter the publisher name in Latin letters, for example its romanised form or the name registered with the society, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_publisher_name_unrepresentable` ### An alternative title has letters a CWR file cannot carry. {#alternate-title-letters-unrepresentable} **Why it matters:** CWR files carry titles in Latin letters, digits and basic punctuation. Accented letters are written as plain letters, but letters from other scripts, such as Cyrillic, Greek or Japanese, would be left out, so the society would record the wrong alternative title. **How to fix it:** Enter the alternative title in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Alternative Titles **Rule:** `cwr_21_alternate_title_letters_unrepresentable` ### A writer's name has letters a CWR file cannot carry. {#writer-name-letters-unrepresentable} **Why it matters:** CWR files carry names in Latin letters, digits and basic punctuation. Accented letters are written as plain letters, but letters from other scripts, such as Cyrillic, Greek or Japanese, would be left out, so the society could match the wrong writer. **How to fix it:** Enter the writer's name in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Writers **Rule:** `cwr_21_writer_name_letters_unrepresentable` ### A publisher name has letters a CWR file cannot carry. {#publisher-name-letters-unrepresentable} **Why it matters:** CWR files carry names in Latin letters, digits and basic punctuation. Accented letters are written as plain letters, but letters from other scripts, such as Cyrillic, Greek or Japanese, would be left out, so the society could match the wrong publisher. **How to fix it:** Enter the publisher name in Latin letters, for example its romanised form or the name registered with the society, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Publishers **Rule:** `cwr_21_publisher_name_letters_unrepresentable` ### A performer name has letters a CWR file cannot carry. {#performer-name-letters-unrepresentable} **Why it matters:** CWR files carry names in Latin letters, digits and basic punctuation. Accented letters are written as plain letters, but letters from other scripts, such as Cyrillic, Greek or Japanese, would be left out, so the society would record the wrong performer. **How to fix it:** Enter the performer name in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Performer / Artist **Rule:** `cwr_21_performer_name_letters_unrepresentable` ### A record label has letters a CWR file cannot carry. {#recording-label-letters-unrepresentable} **Why it matters:** CWR files carry names in Latin letters, digits and basic punctuation. Accented letters are written as plain letters, but letters from other scripts, such as Cyrillic, Greek or Japanese, would be left out, so the society would record the wrong record label. **How to fix it:** Enter the record label in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details **Rule:** `cwr_21_recording_label_letters_unrepresentable` ### An album title has letters a CWR file cannot carry. {#album-title-letters-unrepresentable} **Why it matters:** CWR files carry titles in Latin letters, digits and basic punctuation. Accented letters are written as plain letters, but letters from other scripts, such as Cyrillic, Greek or Japanese, would be left out, so the society would record the wrong album title. **How to fix it:** Enter the album title in Latin letters, for example its romanised form, then check the work again. **Where to fix it in the Workbench:** Generate → Work details **Rule:** `cwr_21_album_title_letters_unrepresentable` ### A title is too long for the CWR file. {#text-too-long} **Why it matters:** The CWR file holds at most 60 characters for a title, and a few letters, such as ß, take two; TrackForge will not cut it short, because the society would register a different title from yours. **How to fix it:** Shorten the title to fit, for example by using the form registered with the society. **Where to fix it in the Workbench:** Generate → Work details **Rule:** `cwr_21_text_too_long` ### A work date is not a real date. {#work-date-invalid} **Why it matters:** Societies record work dates exactly. A date that does not exist, such as 30 February, cannot be sent. **How to fix it:** Enter a real date for the work, or leave it blank. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Copyright date **Rule:** `cwr_21_date_invalid` ### A recording release date is not a real date. {#recording-release-date-invalid} **Why it matters:** Societies record the first release date exactly. A date that does not exist, such as 30 February, cannot be sent. **How to fix it:** Enter the recording's real first release date, or leave it blank. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Release Date **Rule:** `cwr_21_recording_release_date_invalid` ### A recording duration is not in hours, minutes and seconds. {#recording-duration-invalid} **Why it matters:** A CWR file stores a duration as hours, minutes and seconds, with minutes and seconds below 60. Other values cannot be sent. **How to fix it:** Enter the recording length as minutes and seconds, such as 3:45, or leave it blank. **Where to fix it in the Workbench:** Generate → Work details → Advanced fields → Recording Duration **Rule:** `cwr_21_recording_duration_invalid` ## File errors ### A fixed-width CWR field contains data that does not meet its format or length rule. {#record-length} **Why it matters:** Invalid field data can prevent the record, work or file from being processed correctly. **How to fix it:** Correct the source data in the system that created the file, regenerate it, and validate the new file. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_2_1_6_field_validation` ### The CWR file header contains invalid or missing sender information. {#header-fields} **Why it matters:** The header identifies the sender and file version; an invalid header can cause the whole file to be rejected. **How to fix it:** Correct the sender or header settings in the system that created the file, then regenerate it. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_3_5_3_hdr_field_validation` ### The CWR group header is missing required information or is in the wrong format. {#group-header} **Why it matters:** The group header opens and identifies a transaction group; an invalid one can prevent the group from being read. **How to fix it:** Regenerate the file from the source system so it creates a complete group header. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_3_6_3_grh_field_validation` ### The file does not use the required CWR line endings. {#line-endings} **Why it matters:** Incorrect line endings can make the whole fixed-width file unreadable or cause it to be rejected. **How to fix it:** Regenerate the file from the source system and avoid opening and resaving it in a text editor. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_crlf_line_endings` ### The CWR file is incomplete or its header, group and trailer records are in an invalid order. {#file-structure} **Why it matters:** A malformed control-record structure can cause the whole file to be rejected before its works are processed. **How to fix it:** Regenerate the complete file from the source system and validate the new copy. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_3_4_file_level_validation` ### A line starts with an unknown or misplaced CWR record type. {#record-prefixes} **Why it matters:** The record prefix tells the recipient how to interpret every fixed-width line; an invalid prefix can prevent processing. **How to fix it:** Regenerate the file from the source system and avoid manually changing its record codes. **Where to fix it in the Workbench:** Your publishing administration system, then Validate **Rule:** `cwr_21_2_1_5_record_prefixes` --- *Source: [https://trackforge.studio/docs/cwr/problems-and-fixes](https://trackforge.studio/docs/cwr/problems-and-fixes)* --- ## docs/cwr/society-requirements.md # What each society requires > Recipient policies that sit outside the CWR file-format checks. Confirm them before sending a file. These recipient policies sit outside the CWR file-format checks. Confirm them before sending a file, even when the Workbench reports no blocking structural issue. ## CAPASSO Africa If a work includes a sub-publisher or publishing administrator, CAPASSO accepts that party only when it is directly affiliated with, or linked to, CAPASSO. Confirm the relationship before submission. TrackForge can validate the CWR publisher chain but cannot verify that external relationship from the file alone. --- *Source: [https://trackforge.studio/docs/cwr/society-requirements](https://trackforge.studio/docs/cwr/society-requirements)* --- # AI Assistants Documentation --- ## docs/ai-assistants.md # AI assistants > What you can ask an AI assistant once it is connected to TrackForge, and where to find the set-up steps and the full documentation. TrackForge runs a public server that an AI assistant can connect to. Once it is connected, you ask the assistant in plain words and it gets the answer from TrackForge. There is no account to create and no key to copy. ## What you can ask for - **A catalogue check.** Up to 50 recordings at a time, by ISRC. For each one you get whether The MLC has a work linked to it and whether any share is unclaimed. - **One recording and its song.** The writers and publishers with their IPI numbers, the song's ISWC and its first release, as MusicBrainz records them. You can give an ISRC, a Spotify link, a title or a YouTube link. - **A CWR file check.** Paste a CWR 2.1 file of up to 256 KB. Each error and warning comes back with its line and how to fix it. - **A follow-up from a person at TrackForge.** Only when you ask for one and agree to be contacted. The assistant records your request; no report is made automatically. Every answer is a finding from registration data, with the date it is true as of. It is not legal advice and not a statement of who owns a song. ## Where to go next - [Set up your assistant](https://trackforge.studio/mcp): the server address, the steps for Claude and ChatGPT, and example questions and answers. - [MCP server](https://trackforge.studio/docs/ai-assistants/mcp-server): every tool, the settings any assistant needs, how to read each verdict, where the data comes from, and the limits. --- *Source: [https://trackforge.studio/docs/ai-assistants/](https://trackforge.studio/docs/ai-assistants/)* --- ## docs/ai-assistants/mcp-server.md # Public MCP Server > Connect your AI assistant or any MCP client to TrackForge's public, no-auth MCP server. It checks a catalogue's MLC registration and unclaimed shares, up to 50 ISRCs a request, looks up a song's ISWCs, writers and publishers, and validates CWR files. TrackForge runs a public remote MCP (Model Context Protocol) server, named TrackForge. It gives an AI assistant four tools: - **`check_catalogue`**: up to 50 ISRCs a request, checked against The MLC's data. A verdict for each recording (registered, partial, nobody, conflict or unknown), any unclaimed share, and a count of each verdict. - **`lookup_recording`**: one ISRC, Spotify link, title or YouTube link. The recording's MLC verdict and, from MusicBrainz, the song's ISWCs, writers and publishers with IPI numbers, and its first release. - **`validate_cwr`**: a CWR 2.1 file, up to 256 KB. Each error and warning with its line, the rule and how to fix it. - **`request_full_report`**: records a request for a person at TrackForge to follow up. It generates nothing. The server is unauthenticated. There is no account, API key or OAuth flow. It is built for any assistant or app that can add a remote MCP server; the ones it has been tested with are under [Tested clients](#tested-clients). For example questions and answers and a short setup guide, see [trackforge.studio/mcp](https://trackforge.studio/mcp). **Findings, not advice** Every answer is a finding from registration data as of the date shown. It is not legal advice and not a statement of who owns a song or who may use a recording. ## Connect Any MCP client needs these settings and nothing else. | Setting | Value | |---|---| | Server URL | `https://api.trackforge.studio/api/v1/mcp` | | Transport | Streamable HTTP (JSON-RPC over `POST`; `GET` and `DELETE` return 405) | | Authentication | None. Leave any OAuth or API key field empty | | Server name | `trackforge`, with the title TrackForge | | Protocol versions | `2025-11-25`, `2025-06-18`, `2025-03-26`, `2024-11-05`. A client that opens with revision `2026-07-28` gets a 400 and falls back to `initialize`; Claude does this on its own. | | Registry entry | `studio.trackforge/music-registration-check` ([server.json](https://trackforge.studio/.well-known/mcp/server.json)) | ### Any MCP client Add the URL as a remote Streamable HTTP server with no authentication. - **Sessions.** `initialize` returns an `Mcp-Session-Id` header; send it on later requests. A session id the server does not recognise returns 404: send `initialize` again without it. - **Batches.** A JSON-RPC batch may hold at most 10 messages; a larger batch is refused with error `-32600` and none of it runs. - **User agent.** Send a `User-Agent` header that names your client. Cloudflare sits in front of the server and refuses Python `urllib`'s default user agent (`Python-urllib/3.x`) with HTTP 403 and error code 1010, before the request reaches the server (checked on 5 October 2026). - **Browsers.** A request that carries an `Origin` header is accepted only from trackforge.studio, so a page on another site cannot call the server from the browser. Call it from a server or a desktop app. ### Tested clients A client is listed here once it has been tested against the live server, with the date of the test. Other clients have not been tried. | Client | Tested | How to add it | |---|---|---| | Claude, as a custom connector on claude.ai | 3 October 2026 | The steps under [Claude](#claude) | | ChatGPT, in Developer mode on chatgpt.com | 5 October 2026 | The steps under [ChatGPT](#chatgpt) | | Claude Code | 3 October 2026 | `claude mcp add --transport http trackforge https://api.trackforge.studio/api/v1/mcp` | | Codex CLI | 5 October 2026 | `codex mcp add trackforge --url https://api.trackforge.studio/api/v1/mcp` | | MCP Inspector | 3 October 2026 | Enter the server URL and choose the Streamable HTTP transport | ### Claude On Free, Pro and Max plans (checked on a Max plan on 3 October 2026; Claude's screens can differ and change): 1. Open **Customize → Connectors** in Claude. 2. Select **Add**, then **Add custom connector**. 3. Give it a name, such as TrackForge, and enter `https://api.trackforge.studio/api/v1/mcp`, then select **Continue**. Claude marks **No sign-in** as detected; leave any OAuth fields empty. Select **Add**. 4. On the connector's page, select **Connect**. **Tool permissions** lists three read-only tools and one write tool. 5. In a new conversation the connector is already on (**+ → Connectors** shows it). The first time each tool is used, Claude asks whether to allow it. On Team and Enterprise plans, an Owner adds it first under **Organization settings → Connectors → Add → Custom → Web**; members then select **Connect** under **Customize → Connectors**. Free plans allow one custom connector. ### ChatGPT In Developer mode (tested on a Free plan on 5 October 2026; OpenAI's documentation lists Developer mode for Plus, Pro, Business, Enterprise and Education accounts, and ChatGPT's screens can change): 1. Open **Settings → Security and login** and turn on **Developer mode**. 2. Open **Plugins**, select the plus button, then **Create custom MCP server**, then **Create MCP App**. 3. Give it a name, such as TrackForge, enter `https://api.trackforge.studio/api/v1/mcp` as the server URL and set **Authentication** to **No Auth**. 4. Tick **I understand and want to continue**, select **Create**, then **Connect**. The app's page lists the four tools. 5. In a new conversation, select the plus button, type TrackForge and choose it. The read-only tools ran without a prompt under the default permission, **Allow low-risk tools**. Given three ISRCs, ChatGPT called `lookup_recording` once for each. Named in the question, `check_catalogue` was called once for the whole list. ## Tools ### `check_catalogue` Checks up to 50 ISRCs in one call; split a larger catalogue into several calls. Each row gives the recording's verdict and confidence, its MLC song code, any unclaimed share, and the ISWCs and writer names of the works MusicBrainz links to it. The summary counts each verdict, gives the next step for each verdict found, and carries the snapshot date. A row does not repeat the evidence or the next step: `lookup_recording` gives the evidence for one recording. Measured on 5 October 2026: six calls for 300 recordings took 34 seconds in one run and 47 in another, 4 to 9.5 seconds a call, with 18 to 29 KB returned per call. Invalid ISRCs are listed and skipped, and duplicates are removed. A call has about 45 seconds; ISRCs whose lookup has not finished by then are marked `checked: false` and listed in `summary.not_checked_isrcs`. Nothing is known about them, they are not counted as any verdict, and they should be sent again in a smaller call. If none finishes, the tool returns an error. ### `lookup_recording` Finds one recording and reports its MLC registration and the song's rights data. Give exactly one of: | Input | Notes | |---|---| | `isrc` | 12 characters, e.g. `USIR20400274`; hyphens and spaces are accepted | | `spotify_url` | A Spotify track link or `spotify:track:` URI; album and playlist links are refused | | `title` | With optional `artist` | | `youtube_url` | Resolved from the video title, so matches are low confidence | It returns the candidate recordings and MLC works, how each was matched and how confidently, and a verdict for each recording. When several matches are equally likely, `ambiguous` is true and all of them are returned for the user to choose from. For each recording it also returns what MusicBrainz records: - the works linked to the recording, with their ISWCs; - each work's writers and publishers, with IPI and ISNI numbers where MusicBrainz has them; - the earliest release: album, date, label and catalogue number; - how many releases carry the recording, and its page on musicbrainz.org. Set the optional `full_record` to `true` to add MusicBrainz's full record: every release with its label, catalogue number, country and date, the performer and producer credits, related recordings, links and aliases. That answer runs to tens of kilobytes, so leave it out unless the detail is needed. It applies to an ISRC, or to a Spotify link that resolves to one recording. ### `validate_cwr` Checks the text of a CWR 2.1 (Common Works Registration) file, up to 256 KB (262,144 characters) of ASCII text; upload larger files to the [CWR validation tool](https://trackforge.studio/cwr-tool). An optional `filename` such as `CW260001TF_000.V21` lets the society receiver code select that society's rules; `recipient_profile` sets them directly, and `cisac_base` is the default. It returns whether the file is valid, error and warning counts, and each issue with its line, rule, a plain-language explanation and how to fix it. The file is not stored. A valid result does not guarantee that a society will accept the file. ### `request_full_report` Records a request for a person at TrackForge to follow up by email about a catalogue review. It takes a contact name and email, an optional organisation, and the catalogue's ISRCs (up to 200), a description (up to 2,000 characters), or both. `consent_to_contact` must be `true`: an assistant should call this tool only after the user has asked for a follow-up and agreed to be contacted. No report is generated or sent automatically. A person replies by email within two working days with a free summary of what the registration data shows for up to 500 recordings; a full report is quoted as a fixed fee before any work starts, and nothing is charged or filed unless the user agrees. ## Reading the answers Each recording gets one verdict. When several apply, the first in this table wins. | Verdict | Meaning | |---|---| | `unknown` | TrackForge's copy of The MLC's data could not be read. It is never a negative finding. | | `conflict` | The recording is linked to more than one MLC work. | | `nobody` | The data was read and no MLC work is linked to the recording. This does not by itself mean the work is unregistered: the next step says whether to match the recording to an existing work or register one. | | `partial` | The recording is linked to one work, and a share is unclaimed or in dispute. | | `registered` | The recording is linked to one work with nothing unclaimed or in dispute. | Each verdict carries a confidence, dated evidence, an `as_of` date and a `next_step` that names who can act. A `nobody` verdict for a recording released within about 60 days of the snapshot date is marked low confidence: The MLC may not have processed it yet. ## Where the data comes from - **The MLC:** TrackForge's copy of The MLC's public bulk data (BWARM), refreshed weekly. The MLC publishes a new snapshot every five days. The server never queries The MLC live, so every MLC answer is true as of the snapshot date it carries. - **MusicBrainz:** TrackForge's copy of MusicBrainz's core data, which MusicBrainz dedicates to the public domain (CC0), refreshed about twice a month. MusicBrainz is edited by its community, so its record of a song's writers and publishers is evidence, not proof. Its tags, genres, ratings, annotations and cover art are licensed for non-commercial use only and are not returned. A title search that The MLC's data cannot answer is sent to musicbrainz.org. - **Discogs:** TrackForge's copy of Discogs's monthly data dumps, which Discogs dedicates to the public domain (CC0), refreshed monthly. It is used for one check only: when MusicBrainz names no writer for a recording, the writers The MLC lists for each linked work are compared with the writers Discogs's users have credited on releases of a track with that title by that artist. The answer says whether a name is shared, and nothing else from Discogs is returned. Discogs is edited by its users and the track is found by title and artist, not by ISRC, so this is evidence, not proof. - **Spotify:** used only to turn a Spotify track link into its ISRC, and to check that an ISRC is a track on Spotify. Spotify's own data (titles, albums, artwork) is not returned to assistants: Spotify's terms do not allow it to be fed into an AI model. - **YouTube:** a YouTube link is resolved from the video's title, which is read from YouTube. ## Example prompts - "Check these ISRCs against The MLC: how many have no linked work, and how many have a share unclaimed? …" - "Is ISRC USIR20400274 registered with The MLC, and is any share unclaimed?" - "Here is the CWR file I'm about to send to The MLC. Is it valid, and what should I fix?" - "Who is registered for the song at this Spotify link: …?" - "Who wrote the song on ISRC GBUM71029604, and what are the writers' IPI numbers and the ISWC?" - "Which label first released this recording, and under what catalogue number?" ## Limits Limits apply to each MCP session. Clients that send no session id are counted by source address and user agent. Each source address and contact email also has a daily allowance across all its sessions; shared ranges used by hosted assistants, such as Claude's connectors, are exempt from the per-address unit allowance. | Limit | Value | |---|---| | Usage units | 60 per 5 minutes and 600 per UTC day | | Unit cost | `lookup_recording` 1; `check_catalogue` 1 per 10 ISRCs; `validate_cwr` 2; `request_full_report` 1 | | CWR validations | 20 per hour | | Report requests | 5 per day | | Per source address | 3,000 units and 10 report requests per UTC day, across all sessions (an IPv6 address counts by its /64) | | Per contact email | 3 report requests per day | At 1 unit per 10 ISRCs, one session can check up to 600 recordings per 5 minutes and 6,000 per UTC day, less the units its other calls use. A call over a limit returns a tool error that says how long to wait. The CWR validator checks only a few files at once: a `validate_cwr` call made while it is busy returns a tool error asking you to try again in a minute. ## Privacy Requests are logged for usage measurement: the method and tool, the client name and version sent at `initialize`, the input kind, the ISRCs requested or resolved, the outcome, and a keyed one-way hash of the client address. The address itself is not stored. Titles, artist names, CWR file content and the contact details given to `request_full_report` are not logged; those contact details are stored only so that a person can follow up. The request log is kept for 12 months, and the address hash is removed after 90 days. Report requests are kept for 24 months, or less if the person who made one asks for it to be deleted. The [privacy policy](https://trackforge.studio/privacy) has the full terms, and [auth.md](https://trackforge.studio/auth.md) gives the same details in a form for automated clients. ## Support Email `hello@trackforge.studio`. --- *Source: [https://trackforge.studio/docs/ai-assistants/mcp-server](https://trackforge.studio/docs/ai-assistants/mcp-server)* --- # Certification Documentation --- ## docs/certification/overview/why-trackforge.md # Why TrackForge? > Why catalogue owners, lawyers, and buyers need deterministic royalty-leakage ratings instead of generic metadata scores. 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?](https://trackforge.studio/docs/certification/overview/what-is-certification)** - How ratings and proofs work. - **[Scope & Legal Positioning](https://trackforge.studio/docs/certification/for-lawyers/certification-scope)** - What the certificate does and does not claim. - **[Reading Your Certificate](https://trackforge.studio/docs/certification/for-catalogue-owners/reading-your-certificate)** - How to interpret rating fields. --- *Source: [https://trackforge.studio/docs/certification/overview/why-trackforge](https://trackforge.studio/docs/certification/overview/why-trackforge)* --- ## docs/certification/overview/the-problem.md # The Problem — Why Catalogues Are Hard to Value > Information asymmetry creates a market for lemons. Sellers with good catalogues are penalised. Buyers discount everything. The mid-tier is locked out. ## 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] When a streamed recording's metadata is complete, the CMO matches it to the rights holder and the royalty is paid; when it is not, the money goes to a suspense account, and is paid late if it is claimed within the window or ends in the black box if it is not. ```d2 direction: down released: Recording Released streams: DSP Streams Track complete: "Metadata\nComplete?" matches: "CMO Matches\nto Rights Holder" paid: Royalty Paid suspense: "Suspense\nAccount" claimed: "Claimed\nWithin\nWindow?" late: "Late Payment\n(months/years delayed)" blackbox: "Black Box\n(redistributed or\nwritten off)" released -> streams streams -> complete complete -> matches: "Yes" matches -> paid complete -> suspense: "No" suspense -> claimed claimed -> late: "Yes" claimed -> blackbox: "No" ``` *When a streamed recording's metadata is complete, the CMO matches it to the rights holder and the royalty is paid; when it is not, the money goes to a suspense account, and is paid late if it is claimed within the window or ends in the black box if it is not.* 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](https://trackforge.studio/docs/certification/overview/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. --- *Source: [https://trackforge.studio/docs/certification/overview/the-problem](https://trackforge.studio/docs/certification/overview/the-problem)* --- ## docs/certification/overview/the-market.md # The Market — Music Catalogues as Financial Assets > Over $20 billion in institutional capital has deployed into music rights since 2019, but the mid-tier market lacks standardised risk assessment. ## 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 Institutional investors put money into fund vehicles that acquire catalogues; 228 CMOs worldwide collect the royalty streams, which are distributed to investors and partly reinvested in the fund vehicles. ```d2 direction: right investors: "Institutional\nInvestors" funds: "Fund Vehicles\n(PE, dedicated funds,\nJVs, ABS)" acquisitions: "Catalogue\nAcquisitions" cmos: "228 CMOs\nWorldwide" streams: "Royalty\nStreams" distributions: "Distributions\nto Investors" investors -> funds funds -> acquisitions acquisitions -> cmos cmos -> streams streams -> distributions distributions -> funds: Reinvestment {class: arrow; style.stroke-dash: 3} ``` *Institutional investors put money into fund vehicles that acquire catalogues; 228 CMOs worldwide collect the royalty streams, which are distributed to investors and partly reinvested in the fund vehicles.* 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](https://trackforge.studio/docs/certification/overview/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. --- *Source: [https://trackforge.studio/docs/certification/overview/the-market](https://trackforge.studio/docs/certification/overview/the-market)* --- ## docs/certification/overview/the-solution.md # The Solution > TrackForge detects active royalty-leakage conditions, values the money at risk and produces proof-backed deliverables that fix problems at the source society. 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. --- *Source: [https://trackforge.studio/docs/certification/overview/the-solution](https://trackforge.studio/docs/certification/overview/the-solution)* --- ## docs/certification/overview/independent-verification-explained.md # Independent Verification — Why You Don't Have to Trust Us > Every TrackForge rating is mathematically verifiable by anyone, without TrackForge's involvement. Here is how it works, explained for a general audience. ## 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. Track metadata is put into canonical format and run through SHA-256, which gives a fingerprint of 64 hex characters. ```d2 direction: right metadata: "Track Metadata\nISRC: GBAYE0000001\nWriter: Freddie Mercury\nIPI: 00003926939\nShare: 25.00%" canonical: "Canonical\nFormat" sha: SHA-256 fingerprint: "Fingerprint\na7f3b2c1...\n(64 hex characters)" metadata -> canonical canonical -> sha sha -> fingerprint ``` *Track metadata is put into canonical format and run through SHA-256, which gives a fingerprint of 64 hex characters.* ### 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`. The root hash sits above two intermediate hashes, each of which sits above the fingerprints of two tracks. ```d2 direction: down root: "Root Hash\ne4d2f1a8..." ab: b3c7d9e2... cd: f1a4b8c3... t1: "Track 1\na7f3b2c1..." t2: "Track 2\nd8e5f4a2..." t3: "Track 3\nc2b9a7d4..." t4: "Track 4\n9f1e3c8b..." root -- ab root -- cd ab -- t1 ab -- t2 cd -- t3 cd -- t4 ``` *The root hash sits above two intermediate hashes, each of which sits above the fingerprints of two tracks.* ### 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. The rating methodology is run through SHA-256 to give the methodology hash, which OpenTimestamps anchors to the Bitcoin blockchain. ```d2 direction: right methodology: "Rating Methodology\nThresholds, criteria,\ndisclosure text" sha: SHA-256 hash: "Methodology Hash\nb4e2a1f7..." ots: OpenTimestamps btc: "Bitcoin\nBlockchain" methodology -> sha sha -> hash hash -> ots ots -> btc ``` *The rating methodology is run through SHA-256 to give the methodology hash, which OpenTimestamps anchors to the Bitcoin blockchain.* 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](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/methodology/golden-record-selection) and [rating input scoring schedule](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/methodology/blockchain-anchoring) for implementation details. --- *Source: [https://trackforge.studio/docs/certification/overview/independent-verification-explained](https://trackforge.studio/docs/certification/overview/independent-verification-explained)* --- ## docs/certification/overview/what-is-certification.md # What is TrackForge Rating Certification? > An introduction to TrackForge's methodology-versioned, cryptographically anchored catalogue and track rating system. 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 The current process in ten steps, from catalogue intake to the certificate and proof bundle, as the numbered list below describes. ```d2 direction: down intake: Catalogue Intake workflow: UK/US Workflow Execution snapshot: Evidence Packet Snapshot risk: Agreement + ISWC Risk Inputs taxonomy: Leakage Taxonomy Projection event: AAA-D Rating Event hashes: Canonical JSON + Hashes root: Merkle Root ots: OpenTimestamps Proof State bundle: Certificate / Proof Bundle intake -> workflow -> snapshot -> risk -> taxonomy -> event -> hashes -> root -> ots -> 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. --- *Source: [https://trackforge.studio/docs/certification/overview/what-is-certification](https://trackforge.studio/docs/certification/overview/what-is-certification)* --- ## docs/certification/overview/scope.md # What Certification Does And Does Not Mean > What TrackForge certification does and does not mean: a defined methodology applied to a frozen evidence snapshot — process fidelity, not legal ownership. 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. --- *Source: [https://trackforge.studio/docs/certification/overview/scope](https://trackforge.studio/docs/certification/overview/scope)* --- ## docs/certification/overview/audience.md # Who Uses TrackForge? > Who uses TrackForge: catalogue owners recovering royalties, lawyers running diligence, buyers pricing catalogue risk and operators fixing royalty infrastructure. 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](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/methodology/enrichment-validation). --- *Source: [https://trackforge.studio/docs/certification/overview/audience](https://trackforge.studio/docs/certification/overview/audience)* --- ## docs/certification/overview/logging-in.md # Logging In > How to log in to TrackForge: invite-only accounts, two-factor authentication, and what to do if you need access or lose your credentials. ## 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 [trackforge.studio/sign-in](https://trackforge.studio/sign-in). 2. Enter the email address and password for your TrackForge account. After login, you will be taken back to the page you were trying to open. ## Getting An Account The TrackForge team sets up your account and gives you your sign-in details. There is no separate invite or verification email. ## Troubleshooting ### I don't have sign-in details Ask the TrackForge team to set up your account. ### 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. --- *Source: [https://trackforge.studio/docs/certification/overview/logging-in](https://trackforge.studio/docs/certification/overview/logging-in)* --- ## docs/certification/methodology/golden-record-selection.md # Rating Methodology (AAA-D) > How TrackForge M58 v1.1 catalogue and track ratings are calculated from the leakage taxonomy, agreement binding, ISWC coverage, population defects, and proof hashes. **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](https://trackforge.studio/docs/certification/methodology/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](https://trackforge.studio/docs/certification/methodology/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. --- *Source: [https://trackforge.studio/docs/certification/methodology/golden-record-selection](https://trackforge.studio/docs/certification/methodology/golden-record-selection)* --- ## docs/certification/methodology/rating-input-scoring-schedule.md # Rating Input & Scoring Schedule > The public M58 v1.1 scoring contract for recomputing TrackForge AAA-D catalogue and track ratings from certified rating inputs. 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)](https://trackforge.studio/docs/certification/methodology/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. --- *Source: [https://trackforge.studio/docs/certification/methodology/rating-input-scoring-schedule](https://trackforge.studio/docs/certification/methodology/rating-input-scoring-schedule)* --- ## docs/certification/methodology/value-chain-maturity-model.md # Rating Contract & Maturity Model > How the Value Chain Maturity Model separates evidence maturity, royalty-leakage state and certificate-facing AAA-D ratings in TrackForge methodology. 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 The evidence packet gives the agreement and ISWC inputs, which give the leakage vector; the leakage vector, the methodology hash, the workflow and taxonomy versions and the jurisdictional scope go into the rating event, which produces the AAA-D rating and the proof bundle. ```d2 direction: right packet: Evidence Packet inputs: Agreement + ISWC Inputs vector: Leakage Vector hash: Methodology Hash versions: Workflow + Taxonomy Versions scope: Jurisdictional Scope event: Rating Event rating: AAA-D Rating bundle: Proof Bundle packet -> inputs inputs -> vector hash -> event versions -> event vector -> event scope -> event event -> rating event -> bundle ``` *The evidence packet gives the agreement and ISWC inputs, which give the leakage vector; the leakage vector, the methodology hash, the workflow and taxonomy versions and the jurisdictional scope go into the rating event, which produces the AAA-D rating and the 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. --- *Source: [https://trackforge.studio/docs/certification/methodology/value-chain-maturity-model](https://trackforge.studio/docs/certification/methodology/value-chain-maturity-model)* --- ## docs/certification/methodology/enrichment-validation.md # Evidence Assembly & Leakage Projection > How TrackForge assembles source evidence, freezes it into evidence packets, and projects deterministic leakage taxonomy state. **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)](https://trackforge.studio/docs/certification/methodology/golden-record-selection)** - The current scoring recipe. - **[Canonicalisation](https://trackforge.studio/docs/certification/methodology/canonicalization)** - How evidence is serialised for hashing. - **[Rating Independence](https://trackforge.studio/docs/certification/for-lawyers/rating-independence)** - The Chinese-wall model. --- *Source: [https://trackforge.studio/docs/certification/methodology/enrichment-validation](https://trackforge.studio/docs/certification/methodology/enrichment-validation)* --- ## docs/certification/methodology/canonicalization.md # Canonicalisation > How TrackForge canonicalises evidence packets, leakage vectors and rating events into deterministic JSON so identical inputs always produce identical hashes. 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](https://trackforge.studio/docs/certification/technical/canonical-json-schema) for the byte-level rules. --- *Source: [https://trackforge.studio/docs/certification/methodology/canonicalization](https://trackforge.studio/docs/certification/methodology/canonicalization)* --- ## docs/certification/methodology/hashing.md # Hashing > How TrackForge uses SHA-256 to bind ratings to exact inputs: evidence packet hashes, rating event hashes and versioned methodology artefact hashes. 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. --- *Source: [https://trackforge.studio/docs/certification/methodology/hashing](https://trackforge.studio/docs/certification/methodology/hashing)* --- ## docs/certification/methodology/merkle-tree.md # Merkle Tree Construction > 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. **Methodology Version** Methodology Version 1.1 - Effective May 2026 After each track in a certification batch has been [canonicalised](https://trackforge.studio/docs/certification/methodology/canonicalization) and [hashed](https://trackforge.studio/docs/certification/methodology/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. The Merkle root sits above two parent hashes: Parent AB above Tracks A and B, and Parent CD above Tracks C and D. ```d2 direction: down root: Merkle Root ab: Parent AB cd: Parent CD a: Track A b: Track B c: Track C d: Track D root -> ab root -> cd ab -> a ab -> b cd -> c cd -> d ``` *The Merkle root sits above two parent hashes: Parent AB above Tracks A and B, and Parent CD above Tracks C and D.* 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](https://trackforge.studio/docs/certification/methodology/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](https://trackforge.studio/docs/certification/methodology/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](https://trackforge.studio/docs/certification/methodology/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](https://trackforge.studio/docs/certification/methodology/hashing)** — How individual track hashes (the Merkle leaves) are computed - **[Blockchain Anchoring](https://trackforge.studio/docs/certification/methodology/blockchain-anchoring)** — How the Merkle root is anchored to the blockchain - **[Independent Verification](https://trackforge.studio/docs/certification/methodology/independent-verification)** — How Merkle proofs are used in the verification process --- *Source: [https://trackforge.studio/docs/certification/methodology/merkle-tree](https://trackforge.studio/docs/certification/methodology/merkle-tree)* --- ## docs/certification/methodology/blockchain-anchoring.md # Blockchain Anchoring > How the Merkle root hash is anchored to a public blockchain via the OpenTimestamps protocol, creating a permanent and independently verifiable timestamp. **Methodology Version** Methodology Version 1.1 - Effective May 2026 Once the [Merkle tree](https://trackforge.studio/docs/certification/methodology/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. **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](https://trackforge.studio/docs/certification/methodology/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](https://trackforge.studio/docs/certification/methodology/merkle-tree)** — How the root hash that gets anchored is produced - **[Independent Verification](https://trackforge.studio/docs/certification/methodology/independent-verification)** — How third parties verify the blockchain anchor - **[Hashing](https://trackforge.studio/docs/certification/methodology/hashing)** — The SHA-256 algorithm used throughout the pipeline --- *Source: [https://trackforge.studio/docs/certification/methodology/blockchain-anchoring](https://trackforge.studio/docs/certification/methodology/blockchain-anchoring)* --- ## docs/certification/methodology/independent-verification.md # Independent Verification > How any party can independently verify a TrackForge certification without access to TrackForge systems, using standard cryptographic tools. **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](https://trackforge.studio/docs/certification/methodology/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](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/methodology/golden-record-selection) and [Rating Input & Scoring Schedule](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/methodology/golden-record-selection) and the detailed [Rating Input & Scoring Schedule](https://trackforge.studio/docs/certification/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](https://trackforge.studio/docs/certification/for-lawyers/rating-independence). [^1]: TrackForge currently uses the Bitcoin blockchain via the [OpenTimestamps](https://opentimestamps.org/) protocol. ## Related methodology pages - **[Hashing](https://trackforge.studio/docs/certification/methodology/hashing)** — The SHA-256 algorithm used in Step 1 - **[Rating Input & Scoring Schedule](https://trackforge.studio/docs/certification/methodology/rating-input-scoring-schedule)** — The row inputs, risk points, caps, thresholds, and rating recomputation contract - **[Merkle Tree Construction](https://trackforge.studio/docs/certification/methodology/merkle-tree)** — The tree structure and inclusion proofs used in Step 2 - **[Blockchain Anchoring](https://trackforge.studio/docs/certification/methodology/blockchain-anchoring)** — The OpenTimestamps protocol verified in Step 3 - **[Re-Certification](https://trackforge.studio/docs/certification/methodology/recertification)** — How verification applies to tracks with multiple certification versions --- *Source: [https://trackforge.studio/docs/certification/methodology/independent-verification](https://trackforge.studio/docs/certification/methodology/independent-verification)* --- ## docs/certification/methodology/recertification.md # Re-Rating & Supersession > How re-rating works at TrackForge: new evidence or remediation creates a new versioned rating event and supersedes the old one without rewriting history. 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. --- *Source: [https://trackforge.studio/docs/certification/methodology/recertification](https://trackforge.studio/docs/certification/methodology/recertification)* --- ## docs/certification/for-lawyers/certification-scope.md # Scope & Legal Positioning > What a TrackForge rating certificate asserts, what it does not assert, and the current UK/US jurisdictional scope. 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. --- *Source: [https://trackforge.studio/docs/certification/for-lawyers/certification-scope](https://trackforge.studio/docs/certification/for-lawyers/certification-scope)* --- ## docs/certification/for-lawyers/liability-risk.md # Liability & Risk Boundaries > Liability boundaries for TrackForge rating certificates: process-fidelity statements, not ownership guarantees — what is asserted, excluded and disclaimed. 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. --- *Source: [https://trackforge.studio/docs/certification/for-lawyers/liability-risk](https://trackforge.studio/docs/certification/for-lawyers/liability-risk)* --- ## docs/certification/for-lawyers/data-handling-gdpr.md # Data Handling & GDPR > How TrackForge handles catalogue data under GDPR: public blockchains carry hash commitments only — no catalogue metadata, writer data or personal information. 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. --- *Source: [https://trackforge.studio/docs/certification/for-lawyers/data-handling-gdpr](https://trackforge.studio/docs/certification/for-lawyers/data-handling-gdpr)* --- ## docs/certification/for-lawyers/certificate-wording.md # Certificate Wording & Disclaimer > Standard wording for TrackForge AAA-D rating certificates: the rating disclaimer, methodology references, UK/US scope and legacy compatibility language. 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. --- *Source: [https://trackforge.studio/docs/certification/for-lawyers/certificate-wording](https://trackforge.studio/docs/certification/for-lawyers/certificate-wording)* --- ## docs/certification/for-lawyers/conflicting-certifications.md # Conflicting Certifications Policy > How TrackForge handles the situation where two certifications for the same ISRC contain different metadata. 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). **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. --- *Source: [https://trackforge.studio/docs/certification/for-lawyers/conflicting-certifications](https://trackforge.studio/docs/certification/for-lawyers/conflicting-certifications)* --- ## docs/certification/for-catalogue-owners/deliverables.md # Deliverables > What catalogue owners receive from TrackForge: proof bundles, evidence packets, CWR registration files and society-ready remediation 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. --- *Source: [https://trackforge.studio/docs/certification/for-catalogue-owners/deliverables](https://trackforge.studio/docs/certification/for-catalogue-owners/deliverables)* --- ## docs/certification/for-catalogue-owners/reading-your-certificate.md # Reading Your Certificate > How to read a TrackForge AAA-D rating certificate: the rating, methodology version and hash, jurisdictional scope, evidence snapshot and proof bundle fields. 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. --- *Source: [https://trackforge.studio/docs/certification/for-catalogue-owners/reading-your-certificate](https://trackforge.studio/docs/certification/for-catalogue-owners/reading-your-certificate)* --- ## docs/certification/for-catalogue-owners/verification.md # How to Verify Independently > Three methods for verifying a TrackForge certification — online, from the proof bundle, or from scratch. A TrackForge certification is designed to be verifiable by anyone, at any time, without needing to contact or trust TrackForge. This page describes three methods, from simplest to most thorough. ## Method 1: Online verification The quickest way to verify a certificate or rating proof. 1. Go to [trackforge.studio/docs/certification/for-catalogue-owners/verification](https://trackforge.studio/docs/certification/for-catalogue-owners/verification). 2. Paste the `canonical_json` field from your certificate into the input box. 3. The page computes the SHA-256 hash in your browser and checks it against the certification records. For current M58 rating events, Forge also exposes a grade proof endpoint that returns the AAA-D rating proof for the current certification root. Use that when the artefact you need to verify is a catalogue or track grade rather than a legacy canonical track record. **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](https://trackforge.studio/docs/certification/methodology/rating-input-scoring-schedule) to recompute row risk points, row scores, catalogue caps, and the final AAA-D rating. **Step 6 — Verify the proof wrapper** Open `proof/rating_event_proof.json` and confirm it references the same rating event, root, proof state, and snapshot links as `proof/rating_event.json`. **Step 7 — Follow the snapshot links** Open `proof/snapshot_links.json` to trace the proof back to the frozen evidence snapshot used by the rating workflow. **Step 8 — Verify optional blockchain anchor** If the bundle includes `.ots` files or transaction references, use an OpenTimestamps verifier to confirm that the root is anchored in the blockchain: ```bash # Using the ots command-line tool ots verify proofs/batch_.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. **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](https://trackforge.studio/docs/certification/for-catalogue-owners/proof-bundle)** — Detailed guide to the self-contained verification archive. - **[Rating Input & Scoring Schedule](https://trackforge.studio/docs/certification/methodology/rating-input-scoring-schedule)** — Detailed guide to recomputing the AAA-D grade from rating inputs. - **[Re-Certification](https://trackforge.studio/docs/certification/for-catalogue-owners/recertification)** — What happens when certified metadata changes. [^1]: TrackForge currently uses the Bitcoin blockchain via the [OpenTimestamps](https://opentimestamps.org/) protocol. See [Blockchain Anchoring](https://trackforge.studio/docs/certification/methodology/blockchain-anchoring) for implementation details. --- *Source: [https://trackforge.studio/docs/certification/for-catalogue-owners/verification](https://trackforge.studio/docs/certification/for-catalogue-owners/verification)* --- ## docs/certification/for-catalogue-owners/proof-bundle.md # The Proof Bundle > A guide to the self-contained certification archive — what it contains, how to use it, and why it matters. 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](https://trackforge.studio/docs/certification/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. **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](https://trackforge.studio/docs/certification/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. **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](https://trackforge.studio/docs/certification/for-catalogue-owners/verification)** — More detail on each verification method. - **[Re-Certification](https://trackforge.studio/docs/certification/for-catalogue-owners/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](https://trackforge.studio/docs/certification/methodology/blockchain-anchoring) for implementation details. --- *Source: [https://trackforge.studio/docs/certification/for-catalogue-owners/proof-bundle](https://trackforge.studio/docs/certification/for-catalogue-owners/proof-bundle)* --- ## docs/certification/for-catalogue-owners/recertification.md # Re-Certification: When and Why > What triggers re-certification, how the version chain works, and why previous certifications remain valid. 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. **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. **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](https://trackforge.studio/docs/certification/for-catalogue-owners/deliverables)** — Overview of all certification deliverables. - **[Understanding Your Certificate](https://trackforge.studio/docs/certification/for-catalogue-owners/reading-your-certificate)** — Field-by-field guide to the Track Certificate. --- *Source: [https://trackforge.studio/docs/certification/for-catalogue-owners/recertification](https://trackforge.studio/docs/certification/for-catalogue-owners/recertification)* --- ## docs/certification/technical/verification-api.md # Verification API > Current and legacy TrackForge verification endpoints: check the methodology hash, evidence hashes, Merkle root and OpenTimestamps proof state of any certificate. 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. **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 Verification for the published version of the ratings engine arrives at the freeze. Until then no rating is issued for public verification, and the public endpoint answers a notice rather than a verification result. The pages under `/verify` on trackforge.studio say the same. ```http POST /api/v1/certifications/verify ``` The request body is ignored. Response: ```json { "available": false, "message": "Verification for the published version arrives at the freeze.", "detail": "TrackForge is consolidating its catalogue rating into one ratings engine. When its methodology is published, this page will verify a rating from its tuple hash against the published proof bundle. Until then no rating is issued for public verification, and there is nothing here to look up." } ``` The earlier contract (a `canonical_json` request answered with `verified`, `record_hash`, `certification` and `anchors`) belonged to the generation 1 certification and is no longer served. ## 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. | --- *Source: [https://trackforge.studio/docs/certification/technical/verification-api](https://trackforge.studio/docs/certification/technical/verification-api)* --- ## docs/certification/technical/canonical-json-schema.md # Canonical JSON Schema > Deterministic JSON serialisation rules for TrackForge evidence packets and rating events: key ordering, encoding rules and reproducible SHA-256 hashing. 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. --- *Source: [https://trackforge.studio/docs/certification/technical/canonical-json-schema](https://trackforge.studio/docs/certification/technical/canonical-json-schema)* --- ## docs/certification/technical/merkle-proof-format.md # Merkle Proof Format > Specification of TrackForge's deterministic binary Merkle tree: how evidence packet hashes combine into one root and how inclusion proofs are verified. 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. --- *Source: [https://trackforge.studio/docs/certification/technical/merkle-proof-format](https://trackforge.studio/docs/certification/technical/merkle-proof-format)* --- ## docs/certification/technical/opentimestamps.md # OpenTimestamps Integration > How TrackForge submits Merkle root hash commitments to OpenTimestamps, records Bitcoin-anchored proof state, and reports pending versus confirmed status. 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 A 64-character hex hash is decoded to 32 bytes and committed with SHA-256, the commitment is posted to an OpenTimestamps calendar, and the pending .ots proof it returns is upgraded until it is confirmed or still pending. ```d2 direction: down hex: 64-char hex hash bytes: Decode to 32 bytes commit: SHA-256 commitment post: POST /digest to OTS calendar pending: Pending .ots proof upgrade: Upgrade / check confirmation result: Confirmed or still pending hex -> bytes -> commit -> post -> pending -> upgrade -> result ``` *A 64-character hex hash is decoded to 32 bytes and committed with SHA-256, the commitment is posted to an OpenTimestamps calendar, and the pending .ots proof it returns is upgraded until it is 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. --- *Source: [https://trackforge.studio/docs/certification/technical/opentimestamps](https://trackforge.studio/docs/certification/technical/opentimestamps)* --- ## docs/certification/technical/data-security.md # Data Security & Privacy > Technical analysis of data visibility boundaries, blockchain content, verification page privacy, and GDPR-relevant controls in the TrackForge certification system. 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. --- *Source: [https://trackforge.studio/docs/certification/technical/data-security](https://trackforge.studio/docs/certification/technical/data-security)* --- ## docs/certification/glossary.md # Glossary > Definitions of key TrackForge terms: AAA-D ratings, evidence packets, leakage taxonomy, rating events, Merkle roots, OpenTimestamps proof state and more. ### 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. --- *Source: [https://trackforge.studio/docs/certification/glossary](https://trackforge.studio/docs/certification/glossary)* --- ## docs/certification/for-lawyers/rating-independence.md # Rating Independence > How TrackForge separates evidence production, remediation and deterministic rating so the party fixing catalogue data cannot soften the published methodology. 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 Evidence and remediation services produce a frozen evidence snapshot; the snapshot, the published methodology hash and the taxonomy and workflow versions pass through a read-only rating boundary to a deterministic rating event, which produces the proof bundle. ```d2 direction: down services: Evidence / Remediation Services snapshot: Frozen Evidence Snapshot boundary: Read-Only Rating Boundary hash: Published Methodology Hash versions: Taxonomy + Workflow Versions event: Deterministic Rating Event bundle: Proof Bundle services -> snapshot snapshot -> boundary hash -> boundary versions -> boundary boundary -> event event -> bundle ``` *Evidence and remediation services produce a frozen evidence snapshot; the snapshot, the published methodology hash and the taxonomy and workflow versions pass through a read-only rating boundary to a deterministic rating event, which produces the 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. --- *Source: [https://trackforge.studio/docs/certification/for-lawyers/rating-independence](https://trackforge.studio/docs/certification/for-lawyers/rating-independence)* ---