Catch a release's problems before a store does.

The check that protects you from delivering something you do not have the right to deliver. Each track is scanned by audio recognition, and the findings sit on the review screen and on the uploader's own track rows. Approval waits until every track has been scanned.

• Matches, covers and remixes, each with where it plays, its ISRC, its rights holder and its store links
• A match against the artist's own earlier release marked as theirs, not flagged as a problem
• AI-generated audio detected, with the generator named where the engine reports it
• Reported as evidence for a reviewer, never as an automatic refusal
• Approval refused until every track in the release has its result

Deterministic rules run first and cost nothing. Titles, versions, casing, featuring conventions, explicit flags, language and script consistency, identifier validity — checked against a published catalogue rather than a reviewer's memory.

• A 112-rule catalogue drawn from the store style guides that actually reject releases
• The Apple Music Style Guide as the worldwide baseline, with per-store profiles on top
• Per-account overrides — your standards can be stricter than the baseline, never looser than the store's
• Severity per rule, so a warning does not block what a failure should
• Deterministic checks run before anything expensive is called

Resolution and format are the easy half. The half that gets releases rejected is the content — social handles, store logos, URLs, explicit imagery, a face that belongs to somebody else. Those need to be looked at.

• Dimensions, colour space, format and compression against store specifications
• Text and logo detection — URLs, social handles and store marks that stores reject
• Explicit-content classification with a review path rather than an automatic refusal
• Likeness and impersonation signals routed to a human
• Every verdict carries the evidence that produced it

One analysis pass over the master produces every measurement the checks need. The defects that get a release taken down after delivery are exactly the ones that are cheap to catch before it.

• Leading and trailing silence measured against a published threshold
• Clipping, true-peak and integrated loudness
• Dropouts, digital silence mid-track and channel anomalies
• Fake hi-res detection — spectral analysis against the declared sample rate
• Browser-side pre-checks so the obvious problems never reach the queue

The analysis that powers the defect checks also describes the music. Exposed to artists and labels, that becomes a product of its own: what this track is, and how it sits against the catalogue around it.

• BPM, key and scale
• Danceability, energy and mood descriptors
• Hook and chorus timestamps for clip selection
• Comparative percentiles against a reference catalogue
• Available to the artist, not only to the reviewer

The difference between quality control and rejection. When something is ambiguous rather than wrong, the run asks — in the upload session, in plain language, with a proposed correction the uploader can accept in one click.

• Questions raised during the upload, not in a rejection email three days later
• Each question carries a proposed patch to the metadata
• Accepting a patch re-runs only the checks it affects
• Unanswered questions hold the release rather than failing it
• Every question and answer is part of the release's permanent record

A verdict is a decision with its reasoning attached. Clean releases are approved automatically with the full evidence recorded; everything else routes to the right queue, so human review is spent on the cases that need a human.

• Five outcomes: pass, pass with warnings, needs clarification, manual review, fail
• Per-rule evidence rows — what was checked, what was found, what it cost
• Automatic approval for clean releases, with the audit trail to defend it later
• Manual review routed by reason, not dumped in one queue
• A published turnaround target for the fast lane

Quality control is useful to every distributor, not only to the one that owns the catalogue. The engine is being built as a standalone service from the first commit so it can be consumed over an API by platforms that will never use anything else here.

• REST submission with idempotency keys and retrying signed webhooks
• DDEX input accepted alongside a native payload
• A sandbox that returns realistic verdicts without consuming metering
• Per-tenant rule profiles and thresholds
• Metered per release, with the cost ledger visible to the tenant

The builder as a component another platform can embed — their branding, their session, their users, with the checks and the clarification loop running live as the release is assembled.

• Embeddable component with short-lived session tokens
• Checks run live as fields are filled, not on submit
• The clarification loop rendered inside the host product
• Uploads go directly to storage from the visitor's browser
• Host-controlled styling