Rating Independence

Methodology Version

Methodology Version 2.0 — Effective February 2026

TrackForge provides both enrichment services (modifying catalogue data for a fee) and rating services (independently assessing catalogue health). This creates a potential conflict of interest — the same entity that improves a catalogue's metadata also rates it. TrackForge addresses this through structural separation enforced at three independent levels: application architecture, database access control, and transaction isolation.

This page documents the technical implementation of that separation so that acquirer's counsel, auditors, and technical reviewers can independently verify it.

Why this matters

The conflict of interest is analogous to the one that destroyed Arthur Andersen: an entity that provides consulting services to a client and also audits that client's financial statements has an incentive to produce favourable audits. The music industry equivalent: if TrackForge fixes a catalogue's metadata (for a fee) and then certifies that the metadata is now correct (to prove the fix worked), institutional buyers may suspect the rating is not independent.

TrackForge's response is not policy-based ("we promise to be independent") but architecturally enforced ("the system cannot produce a non-independent rating"). The separation is verifiable by inspecting code, database configuration, and runtime behaviour.

The three-level Chinese Wall

Level 1: Application architecture

The Rating Oracle is a pure function. It:

• Has zero imports from any enrichment module, write-capable service, or data-modification component.
• Receives a data snapshot as input and returns a deterministic verdict as output.
• Cannot call any function that modifies data — there is no code path from rating to enrichment.
• Uses only frozen (immutable) data structures for its configuration and thresholds.

The rating criteria are defined as immutable constants in a global standard. They are not configurable per client, per catalogue, or per engagement. A track rated "GOLDEN" in one catalogue meets exactly the same thresholds as a track rated "GOLDEN" in any other catalogue. There are no per-client modifiers, custom weightings, or overrides.

What an auditor can verify:

• Inspect the Rating Oracle source code and confirm zero imports from enrichment modules.
• Confirm that all threshold values are defined as frozen dataclasses (Python @dataclass(frozen=True)), which cannot be modified at runtime.
• Confirm that the global standard version string is embedded in every rating output.

Level 2: Database access control

The rating engine connects to the database through a dedicated PostgreSQL role (rating_reader) with SELECT-only permissions:

GRANT SELECT ON entities.recordings TO rating_reader;
GRANT SELECT ON links.prs_catalog_track TO rating_reader;
GRANT SELECT ON links.isrc_iswc TO rating_reader;
GRANT SELECT ON prs.works TO rating_reader;
GRANT SELECT ON reference.catalogs TO rating_reader;

INSERT, UPDATE, and DELETE are explicitly revoked on all tables in the rating-accessible schemas. Even if a bug in the application code attempted to write data through the rating connection, PostgreSQL would reject the operation at the database level.

The enrichment service uses a separate database role (ma_scraper) with full read-write permissions. The two roles connect through separate connection pools with separate credentials.

What an auditor can verify:

• Connect to the database as rating_reader and confirm that any INSERT, UPDATE, or DELETE statement is rejected.
• Inspect the database role grants using \dp (PostgreSQL) to confirm SELECT-only permissions.
• Confirm that the rating engine's connection string uses the rating_reader role, not the enrichment role.

Level 3: Transaction isolation

All rating queries execute within PostgreSQL read-only transactions:

BEGIN READ ONLY;
-- all rating queries here
COMMIT;

This provides a third layer of protection. Even if the rating connection pool were misconfigured to use the wrong role, PostgreSQL would still reject write operations within a read-only transaction.

What an auditor can verify:

• Inspect the rating engine's database connection code and confirm that readonly=True is set on the connection or that SET TRANSACTION READ ONLY is issued.

Data flow direction

Data flows in one direction only: from the database through the Rating Oracle to the rating output. There is no reverse path.

┌─────────────────────────────────────────────────┐
│  ENRICHMENT SERVICES                            │
│  (Read-Write, ma_scraper role)                  │
│  ┌─────────┐ ┌──────────┐ ┌──────────────────┐ │
│  │ Spotify │ │ PRS      │ │ Other sources    │ │
│  └────┬────┘ └────┬─────┘ └────────┬─────────┘ │
│       └───────────┼────────────────┘            │
│                   ▼                             │
│           ┌───────────────┐                     │
│           │  PostgreSQL   │                     │
│           │  (Hetzner)    │                     │
│           └───────┬───────┘                     │
└───────────────────┼─────────────────────────────┘
                    │
          ══════════╪══════════  ← CHINESE WALL
                    │
┌───────────────────┼─────────────────────────────┐
│  RATING SERVICES  │ (Read-Only, rating_reader)  │
│                   ▼                             │
│           ┌───────────────┐                     │
│           │ Data Reader   │ SELECT only         │
│           │ (readonly tx) │                     │
│           └───────┬───────┘                     │
│                   ▼                             │
│           ┌───────────────┐                     │
│           │ Rating Oracle │ Pure function        │
│           │ (no imports   │ Frozen thresholds   │
│           │  from above)  │                     │
│           └───────┬───────┘                     │
│                   ▼                             │
│           ┌───────────────┐                     │
│           │ Portfolio     │ Aggregation          │
│           │ Rating        │ AAA-D grade          │
│           └───────┬───────┘                     │
│                   ▼                             │
│           Rating Output + Evidence Hash         │
└─────────────────────────────────────────────────┘

The enrichment service writes data to the database. The rating service reads a snapshot of that data. There is no mechanism for the rating service to communicate back to the enrichment service, request data modifications, or influence the enrichment process.

Global standards (immutable criteria)

Rating criteria are defined as a versioned global standard. The standard specifies:

• Six completeness levels (MINIMAL through FORENSIC_GRADE) with explicit field requirements and minimum source counts for each level.
• Three assurance levels (COLLECTION_READY, CERTIFIED, LITIGATION_GRADE) based on corroboration depth and attestation method.
• Ten portfolio grades (AAA through D) based on the proportion of revenue secured by tracks at GOLDEN completeness or higher.

These criteria are implemented as frozen Python dataclasses that cannot be modified at runtime. The standard version string (e.g., GLOBAL_STANDARD_v1.0) is embedded in every rating output.

What this means for independence: A track that scores GOLDEN in a catalogue that paid for enrichment services is evaluated against exactly the same thresholds as a track in a catalogue that did not. There is no mechanism to relax thresholds, add bonus points, or apply client-specific modifiers.

Conflict-of-interest disclosure

Every rating output includes a mandatory disclosure statement:

TrackForge may provide both enrichment and rating services. This rating was produced by the Rating Oracle using GLOBAL_STANDARD version [X], applied identically to all catalogues. The Rating Oracle operates with read-only database access and zero imports from enrichment services. Rating criteria are immutable constants — no per-client configuration is possible.

This disclosure is embedded programmatically. It cannot be removed or modified without changing the global standard version, which would be visible in the rating output.

Evidence hash chain

Every track rating includes a SHA-256 evidence hash computed from the canonical JSON representation of the track's rights-critical metadata. This hash serves as a tamper-evident seal:

1. The canonical JSON is produced using deterministic serialisation (sorted keys, no whitespace, ASCII-safe encoding).
2. The SHA-256 hash of this canonical JSON is the evidence hash.
3. The evidence hash is included in the rating output.
4. The methodology_hash — a SHA-256 of the complete rating ruleset (all thresholds, criteria, and disclosure text) — is also bound to every rating, providing cryptographic proof of which exact rules were applied.

Given the same input data, the Rating Oracle will always produce the same evidence hash. An auditor can independently verify a rating by:

1. Obtaining the catalogue data snapshot used for the rating.
2. Applying the published methodology (the decision trees are deterministic — same inputs always produce same outputs).
3. Computing evidence hashes and comparing them to the published values.
4. Any discrepancy indicates either data tampering or a methodology deviation.

Auditor verification checklist

For technical auditors reviewing TrackForge's rating independence:

#	Verification step	What to check
1	Code isolation	Rating Oracle source has zero imports from enrichment modules
2	Frozen thresholds	All threshold dataclasses use frozen=True; no setter methods exist
3	Global standard version	Every rating output includes the standard version string
4	Database role	rating_reader role has SELECT-only grants; INSERT/UPDATE/DELETE revoked
5	Connection string	Rating engine connects using rating_reader credentials
6	Read-only transactions	All rating queries execute within BEGIN READ ONLY transactions
7	No reverse data flow	No code path from rating output back to enrichment input
8	Disclosure present	Every rating output contains the conflict-of-interest disclosure
9	Deterministic output	Same input data produces identical rating and evidence hash
10	Methodology hash	Recompute SHA-256 of the published rating criteria (from methodology.json in the proof bundle) and confirm it matches the methodology_hash in the certification
11	Methodology anchor	Verify methodology_standard.ots using OpenTimestamps; confirm the methodology was anchored to Bitcoin before the certification timestamp
12	No per-client config	No configuration mechanism exists for client-specific threshold overrides

Governance framework

Rating independence is maintained through the following governance principles:

1. Global Standards — Rating criteria are versioned, published, and immutable. Changes require a new version with full disclosure.
2. Separation of Concerns — Enrichment and rating are architecturally separate at code, database, and transaction levels.
3. Deterministic Evaluation — The Rating Oracle is a pure function. Given identical inputs, it always produces identical outputs.
4. Methodology Versioning — Every rating records the methodology version used. Historical ratings can be re-verified against the published methodology.
5. Conflict-of-Interest Disclosure — Every rating output includes a mandatory disclosure statement.
6. Cryptographic Methodology Binding — Every certification includes a methodology_hash: a SHA-256 digest of the complete rating ruleset. This cryptographically binds each rating to the exact criteria that governed it, preventing post-hoc modification of standards. Any change to any threshold, criterion, or disclosure text produces a different hash, making methodology drift detectable.
7. Blockchain Methodology Anchoring — The methodology hash is independently timestamped on the Bitcoin blockchain via OpenTimestamps, separately from any individual certification. This creates an immutable, publicly verifiable record that the rating rules existed at a specific point in time. TrackForge cannot retroactively change what rules were in effect for a past rating — the methodology's OTS proof (methodology_standard.ots, included in every proof bundle) provides blockchain-level evidence that the methodology predated the certification it governed. Auditors can verify this using the OpenTimestamps verifier or the /verify/methodology endpoint.

Related pages

• Scope & Legal Positioning — The broader legal positioning of TrackForge certification.
• Rating Methodology — The full technical methodology, including the six-level completeness model and assurance axis.
• Independent Verification — How to verify certification hashes and blockchain anchors.