AI Features
Running Your First Catalog Audit
Run the Rights & Metadata Audit Engine, review deterministic findings, correct source records, and verify changes with another audit.
- 12 min read
- 12 min read
- Last reviewed 2026-08-10
- Last reviewed 2026-08-10
- Beginner
- Beginner
Overview
The Rights & Metadata Audit Engine evaluates persisted CatalogIQOS records for supported administrative and catalog-governance conditions. It checks core metadata completeness, ISRC format and duplication, duplicate titles and asset filenames, writer and publisher data, PRO and IPI coverage, writer and publisher ownership totals, rights-readiness fields, genre taxonomy, and orphaned assets.
The workflow is Run Audit → Review Findings → Resolve Issues → Review Tracks → Re-run. Findings report observed conditions; they do not edit canonical records. CatalogIQOS audit results are not legal opinions, guaranteed clearance, guaranteed monetization, or guaranteed licensing readiness.
- Select the correct Workspace and Catalog.
- Run Catalog Audit and monitor its background job.
- Review scores and deterministic findings.
- Open affected tracks and correct canonical metadata or rights data.
- Re-run the audit to evaluate the updated persisted state while retaining history.
Step 1 — Select your catalog
Workspace Context shows the active Workspace and Catalog. CatalogSwitcher reloads audit data for another authorized catalog. Before the first run, Tracks to Audit is the number of catalog tracks eligible for analysis; it is not Tracks Scanned. Finish imports and save source records before auditing.
Step 2 — Run Catalog Audit
Choose Run Catalog Audit in the guided panel. CatalogIQOS queues a CATALOG_AUDIT job and creates a persisted Catalog Audit run. While its status is queued, processing, or retrying, the page shows Catalog audit in progress and links to /jobs. Duplicate submissions are blocked while an audit is active. Read-only Enterprise Demo viewers may inspect results but cannot run an audit.
If the run fails, the guide displays Catalog audit could not be completed rather than presenting its default zero score fields as current results. Use View Processing Details, resolve the reported operational issue, and retry after the previous job reaches a final state.
Step 3 — Understand your results
Scores appear only after a completed audit. Before measurement, the UI displays an em dash and Not evaluated—zero means a measured zero, not missing data.
- Tracks Scanned is the number of Track records processed by the completed run.
- Metadata Health averages track completeness across eight implemented checks: artist, ISRC, writers, publishers, PRO, genre, mood, and keywords. Each track’s score is (8 - missing checks) / 8 × 100.
- Duplicate Integrity is a higher-is-better safety score. It starts at 100 and subtracts the combined count of tracks implicated in duplicate ISRC, duplicate title, and duplicate filename groups divided by total tracks, then clamps the result to 0–100. A 100 result is shown only after an audit calculates it.
- Catalog Integrity combines Metadata Health at 45%, rights-readiness scores at 30%, and Duplicate Integrity at 25%, subtracting two points per orphaned asset, then clamps to 0–100.
- The Latest Audit also reports Rights, the average implemented rights-readiness score.
These administrative scores summarize tested fields. They are not proof of ownership, legal compliance, or readiness for a specific buyer.
Step 4 — Review findings
Audit Findings at #findings contains deterministic results from the latest completed audit. Each item shows type, severity, title, explanation, recommended action, and an affected-track action when tracks are linked. Current generated severities are critical and warning. Begin with critical identifier, split, or ownership conflicts, then review warnings.
Implemented finding families include missing metadata, low metadata quality, malformed or duplicate ISRC, duplicate titles and filenames, split-total mismatch, missing PRO/IPI/publisher/ownership, ownership conflicts, orphaned assets, and invalid taxonomy. A finding describes the observed rule result; it does not automatically repair anything.
Step 5 — Review affected tracks
Choose Review affected track to move to Track Audit Review at #track-review. The affected-track selector is limited to track IDs linked by findings from the latest run. Review identifier, splits, publisher, rights signals, and the issue list, then use Open Canonical Track, Review Rights, or Open AI Optimization as appropriate.
The review panel is diagnostic. Selecting or reading a finding does not alter Track data.
Step 6 — Resolve source data
Correct the authoritative source record:
- Use Track Detail for titles, artists, genres, mood, ISRC, and other canonical track metadata.
- Use Rights workflows for contributors, PRO/IPI data, publishers, ownership, and split conflicts.
- Use asset/catalog workflows for orphaned or duplicate file associations.
- Use AI Optimization only for supported reviewable descriptive suggestions; AI output is not a verified fact and is never an automatic audit repair.
Save changes before verification. Do not delete a record solely because a duplicate signal exists; compare identifiers, versions, titles, and assets first.
Step 7 — Re-run the audit
After correcting source data, choose Re-run Catalog Audit. A new run evaluates current persisted state and does not overwrite previous Catalog Audit records. Audit History retains recent runs so users can compare run dates and integrity scores. A cleared finding means the implemented condition no longer appeared; it is not a legal clearance decision.
Reviewing tracks after an audit
Use the affected-track search when many tracks are linked. The relationship is Audit Finding → Track Audit Review → canonical Track or Rights record. Make changes only in the canonical workflow, then re-run.
Understanding Catalog Audit history
Latest Catalog Audit summarizes the newest run. Audit History lists recent persisted runs with their timestamps and integrity scores. During a running or failed latest audit, score cards remain unevaluated rather than borrowing stale metrics and presenting them as current.
Catalog Audit troubleshooting
- Run Catalog Audit disabled: confirm an editable role and a non-demo workspace. Wait for any queued, processing, or retrying audit to finish.
- Audit remains processing: use View Processing Details in /jobs; do not submit duplicates.
- No findings appear: confirm the latest audit completed. A completed run with no findings is a conservative healthy result, not proof the catalog is error-free.
- Finding remains after a correction: confirm the canonical record saved, check the active Catalog, then re-run. Existing findings remain attached to historical runs.
- Affected track is unavailable: the page loads up to 50 recently updated tracks for interactive review, while the engine audits the full catalog. Open the canonical catalog search if an affected ID is outside the loaded review set.
- Score did not improve: the changed field may have limited weight, other gaps may remain, or duplicate/right-readiness signals may offset it. Review the current findings and formula above.
- Audit failed: inspect Processing Details and retry only after the failed job is final.
AI-assisted insights
AI Insights are supplemental interpretations derived from track context. They are visually separated from deterministic Audit Findings and must not be treated as equivalent evidence.
Product boundary
Catalog Audit provides administrative catalog-governance signals. Rights and clearance decisions require authoritative documentation and qualified human review.