---
title: "Data handling: what crosses from the Workspace, and what never does"
description: "A rating of a catalogue kept in the TrackForge Workspace reads a derived spine of the works, not the Workspace itself. Writers, shares, publisher chains, members and users never leave the Workspace. Owner documents are hashed and parsed; the files stay in the client archive."
image: "https://trackforge.studio/docs/img/trackforge-social-card.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://trackforge.studio/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Data handling: what crosses from the Workspace, and what never does

The TrackForge Workspace is where an owner keeps their catalogue: works, writers, shares, publisher chains, the files they prepare and the responses they get back. The rating runs on a different system with a narrower remit, and the two are joined by a bridge that copies only what the rating needs.

## What crosses

For each work the owner has saved, the bridge copies a **derived spine**:

- the title and the first artist,
- the ISWC, where the work has one,
- the valid ISRCs of its recordings, and any recording identifier that is not an ISRC, as written,
- the release facts per recording (what is needed to judge whether the work is in use and since when),
- the society work numbers a society has confirmed,
- the registration positions the owner's own uploads recorded, as **position and number only**,
- whether the owner named a writer on the work (a yes or no, not the writer).

Each import is versioned, hashed, and kept; a work keeps its key across imports, and nothing is deleted when a work leaves the list.

**Acknowledged sends** also cross, for the in-flight overlay: the date a registration was sent, the society, the acknowledged result and the society's work number where one was returned. These are catalogue facts, not user data.

## What never crosses

- **Writers**: names, IPI numbers and roles stay in the Workspace. The rating learns only that a writer was named.
- **Shares and publisher chains**: who owns what and through whom. The rating takes only the owner's attributable share of each work, one number per work: declared by the owner, or, where none is declared, worked out from the Workspace draft's writer and publisher shares, and labelled with its source.
- **Members and users**: who can sign in to the Workspace, who did what, when.
- **The files themselves**: a CWR file the owner prepared, a society's response file, an uploaded list or statement.

## Owner documents

A document the owner supplies for a catalogue rating (a society's works list, a statement, an agreement) is kept in TrackForge's client archive. The rating's ledger holds its **hash** and the **parsed facts** the survey derived from it (a work's title state, a statement line's route, period and amount), never the file. A rating's sources manifest names each document by kind, the date it is true as of and its hash, so the owner can check that the document the rating rests on is the one they supplied.

## Where it is held

The rating's ledger holds catalogue data only: works, their states per component and route, defect rows with their evidence, the sources manifest and the rating events. It holds no user data. The Workspace stays canonical for the owner's catalogue; the rating's copy is a derived, versioned import, and a change in the Workspace reaches the rating only through a new import.

## What the owner sees

The Workspace shows the rating's result for the catalogue (components, coverage, states per work in plain words, the fix list, and the sources with their dates) beside the owner's own uploaded positions, with the newer named. The letter is shown only at the catalogue-rating level and only after the freeze, if TrackForge decides to show letters to Workspace users.

Source: https://trackforge.studio/docs/certification/rating/data-handling/index.mdx