Evaluating AI claims at scale: a policy stack for platforms and distributors

Most enforcement problems in this area come from one signal being asked to carry a decision it cannot support — usually a classifier score being treated as a finding. It is worth being explicit about what each layer is for.

The three signals

1. Declarations

Carried in DDEX metadata from the distributor, covering AI use in vocals, instrumentation, composition, lyrics, and post-production separately. Strength: attributable — a named party is on the record, which makes it actionable under your terms and gives you recourse when it turns out to be false. Weakness: unverified at the point of filing, and only as good as the filer's understanding of what counts.

Best used for: labelling, routing, and establishing accountability. Poorly used as: a completeness guarantee.

2. Detection

Strength: it can be applied to catalogue that predates any disclosure regime. Weakness: it is a probability, and research shows that performance changes across generators, datasets, and ordinary audio transformations. The evidence and limitations matter more than a headline accuracy number.

A fixed threshold applied catalogue-wide is only uniform if the model behaves uniformly across your catalogue. Measure flags, appeals, and reversals by genre, distributor, codec, and detector version; otherwise aggregate accuracy can hide a concentrated failure mode.

Best used for: triage and prioritisation. Poorly used as: grounds for removal without a human step.

3. Provenance

A signed record of how a work was produced, bound to the file — in practice carried as C2PA / Content Credentials, whose trust model is worth understanding before you rely on it. Strength: it is contemporaneous and verifiable, and it is the only one of the three that carries information the finished audio does not contain. Weakness: coverage. Most of the catalogue has none and never will, so it can only ever be a positive signal.

That asymmetry is the design constraint that matters most: absence of provenance must never be treated as evidence of anything. A policy that penalises files without a credential penalises the entire back catalogue and every artist who had not heard of the format, which is nearly all of them.

Putting them together

1. Let declarations label. If a creator declares AI components, apply your labelling and routing. No investigation needed — they told you.
2. Let detection prioritise. Use scores to order a review queue, not to decide its outcomes. Track your flag distribution by genre; if it is lopsided, that is your calibration telling you something.
3. Let provenance resolve, one direction only. A verifiable record should be able to close a case quickly. Its absence should return the case to the ordinary queue, never escalate it.
4. Keep a human step before anything irreversible. Takedowns and payout holds are the actions artists cannot undo themselves, and they are where a probability is least appropriate as the deciding input.
5. Tell people what would resolve it. The most common failure in appeals is not the decision — it is a template reply that never states what evidence would change it, which converts a solvable ticket into a public grievance.

What a provenance record gives you operationally

The value at ingest is not philosophical, it is throughput. A verifiable record turns "assess this artist's story" into "check a signature and read a structured report" — a step that can run automatically, before anything reaches a human queue.

This is the part we build, so read it accordingly. Chronatum is deliberately report-only: it returns what was observed during production, separated from what was inferred, what the creator declared, what conflicts, and what could not be determined — and it does not return a verdict, a score you can threshold, or a compliance certificate. Your screening policy stays yours, which is the correct division: we can tell you what a session looked like, and only you know what your catalogue rules are.

Two properties are worth checking against any provenance vendor, including us. Does the report distinguish observation from inference? A system that merges them is hiding its uncertainty. Does it say what it could not see? Imported audio carries no history of its own, and a record that quietly omits that is worse than no record, because it reads as coverage it does not have.

The integration guide covers verdict semantics, retries, and privacy-safe monitoring; the reference is generated from the API model. Verification is one call against the delivered file.

The uncomfortable part

No arrangement of these three signals produces certainty about a finished recording, because the information needed to be certain was never in the file. What a good stack does is allocate the residual uncertainty deliberately — decide which errors you would rather make, in which direction, and at whose expense — instead of letting a threshold somebody picked make that choice invisibly. That is a policy decision, and it belongs to you rather than to a vendor.