Rating Independence
TrackForge may both identify/fix royalty leakage and rate catalogue state. That creates an obvious conflict risk: the same organisation that improves the data must not be able to soften the rating methodology after the fact.
TrackForge addresses that risk with architecture, not trust language.
Separation Model
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:
- Recompute the methodology hash from the published methodology artefact.
- Recompute evidence packet hashes from canonical JSON.
- Rebuild the Merkle root from the committed packet hashes.
- Confirm the rating event references the same run, scope, methodology hash, and Merkle root.
- Verify OpenTimestamps proof files where the proof state is confirmed.
- 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.