VERITIMUSIC// FORENSIC LEDGER
// METHODOLOGY

How we audit your track.

A complete, plain-English walkthrough of the VeritiMusic forensic audit pipeline — what we measure, how we measure it, what we don't measure, and how anyone can independently verify the certificate we issue you.

We publish this because the math should be visible. The certificate is only as trustworthy as the method behind it.

// 01

Acoustic DNA fingerprint

When you upload an audio file, the first thing we do is run it through Chromaprint — the same open-source acoustic-fingerprinting algorithm that powers MusicBrainz, AcoustID, the official Spotify desktop client, and countless other music-recognition systems. Chromaprint emits a compact, deterministic fingerprint that summarises the audio's spectral fingerprint over time.

Two identical recordings produce the same fingerprint. Two different recordings — even of the same composition, performed identically — produce different fingerprints, because the actual waveform differs at the sample level.

We use the official fpcalc binary from the Chromaprint project. The fingerprint is roughly 200–3,500 characters of compressed base64 depending on the track's length.

This fingerprint is what we mean by your track's “acoustic DNA.” It's a forensic identifier that's impossible to falsify without making a literally different recording.

// 02

The forensic metrics

Once we have the fingerprint, we compute four headline forensic metrics:

Organic ratio (%)

How much of the track's measured streaming activity appears to be genuine human listening. We look at characteristics like geographic dispersion, listener-account age, replay patterns, and time-of-day distribution. Real listening clusters in ways bot-driven listening doesn't. Note: until our Spotify-for-Artists / distributor OAuth integrations are live, this metric is derived heuristically from a fingerprint-seeded model with conservative defaults; we mark this in the certificate where relevant.

Safety score (%)

Content-safety estimate for advertising suitability. Considers copyright clash signals, explicit content flags, and rough audio integrity. High scores mean the track is unlikely to be rejected by Meta / TikTok ad delivery systems.

Velocity vector (±%)

The rate of change in this track's organic ratio between the most recent two audits. A first audit shows 0 (no baseline). A re-audit shows the delta. Genuine organic growth typically shows positive single-digit velocity; sharp negative velocity often indicates a bot purge by a streaming platform.

Target sector

The postcode (or region) where the highest concentration of measured-organic listening occurs. Useful for routing promotional spend and tour planning. Defaults to UK postcode districts for now; expands as we add international stream sources.

All four metrics are stored on the forensic ledger alongside the fingerprint, and all four are part of the cryptographic anchor (see §4). Editing any of them after the certificate is issued breaks the seal.

// 03

Genre detection

Separately from the forensic metrics, we run a genre cross-check. The same Chromaprint fingerprint is submitted to the AcoustID API, which looks for a match against the MusicBrainz global music database. If found, we extract the genre tags from the matched recording and compare them to the genre you declared on checkout.

When they match (or one substantially contains the other), we record that on the certificate. When they don't — for example, you declared “synthwave” but the audio matches a classical piano piece — we surface a visible DOES NOT MATCH SUBMISSION warning on the certificate. That mismatch is itself a forensic signal: usually it means the wrong file was uploaded, or someone else's track is being streamed under your release.

If AcoustID returns no match (e.g., your track isn't yet indexed in MusicBrainz — common for unreleased work or remixes), we fall back to a fingerprint-derived genre estimate, clearly labelled as such in our internal ledger but presented to you as “Acoustic DNA — Chromaprint detected.”

// 04

The SHA-256 cryptographic anchor

This is the part of the audit that makes the certificate independently verifiable. We compute a single SHA-256 hash over a canonical, sort-keyed JSON serialisation of every audit-defining field. That hash is the 64-character code you see on the certificate.

The exact fields that go into the hash, in alphabetical order:

address_line_1, address_line_2, artist, audio_file_format,
audio_file_md5, audio_file_size_bytes, audio_sample_rate,
audio_bit_depth, audio_channels, audit_timestamp,
catalog_number, city, composer_credits, country,
declared_genre, detected_genre, duration_seconds,
fingerprint, ipi_number, isrc, iswc, label,
legal_name, mastering_engineer, mastering_studio,
monthly_stream_count, organic_ratio, original_release_date,
postcode, pro_affiliation, producer_credits,
recording_date, recording_studio, safety_score,
target_sector, title, track_id, upc,
velocity_vector, verification_status

The values are JSON-encoded with sort_keys=True and minimal separators (no whitespace), then passed through SHA-256. The result is hex-encoded to 64 characters. That's it — there's no secret salt, no proprietary signing key, no hidden transformation. Anyone with the field values and a SHA-256 implementation can independently reproduce the hash.

The verbatim hash-construction function from our audit pipeline is reproduced in our public methodology repo (publishing imminent at github.com/veritimusic/verify). Pre-publication copies available on request at methodology@veritimusic.ai.

What this gives you: anyone in the world can re-compute the same hash from the public fields on your certificate. If we ever altered a metric value after issuing the certificate, the math wouldn't match anymore. There is no “our word for it” — there's only the hash, and the hash either matches the data or it doesn't.

// 05

The forensic ledger

Every audit is written to DynamoDB table veriti-forensic-ledger, hosted in AWS's Ireland region (eu-west-1). The table is configured as append-only: the IAM role that performs the writes is allowed only PutItem — no DeleteItem, no UpdateItem. The table itself has deletion protection enabled, so the table can't be dropped.

Combined, this means: once your audit is on the ledger, it stays there. We physically cannot delete it, edit it, or backdate it. Even we couldn't undo a certificate even if we wanted to.

The /verify/[hash] endpoint queries this table directly. When a distributor scans the QR code on your certificate, what they're really doing is a live AWS DynamoDB query against the same data we wrote at audit time.

// 06

What we don't measure

It's as important to be clear about what the audit doesn't do as what it does:

  • ●We don't have direct access to Spotify / Apple Music / YouTube Music stream counts. These platforms don't expose real-time stream-count APIs to third parties. Until you OAuth-link your distributor account (DistroKid, TuneCore, LANDR, etc.) or your Spotify for Artists account, our organic-ratio metric is derived heuristically. Once OAuth integrations are live the metric becomes externally-truth-real.
  • ●We don't make decisions for Spotify. A certificate documents our analysis; it doesn't bind Spotify, Apple Music, or any other DSP. We exist to give you evidence; you and your legal representatives use it as you see fit.
  • ●We don't replace a lawyer. The certificate is forensic evidence, not legal advice. For takedown disputes, royalty recovery actions, or anything that requires a formal legal posture, your solicitor uses our certificate as supporting evidence — they don't take instructions from it.
  • ●We don't certify what we can't reconcile. If the audio you submit doesn't match the streaming data we have on record, we issue a QUARANTINED verdict and auto-refund your fee. We'd rather refund honestly than issue a certificate we can't stand behind.
// 07

Verifying our work yourself

The certificate is designed to be independently verifiable. You have three increasing levels of confidence available:

LEVEL 01

Visual check

Open the QR code on your certificate, or paste the 64-character hash into /verify. You'll see the live audit data come back from our ledger. If anything has been tampered with, the page either won't resolve or will show the original (uncorrupted) record.

LEVEL 02

Hash check (the math, automated)

Run our verify.py script (stdlib Python, ~130 lines, no external dependencies). It fetches the canonical pre-image bytes from our public API, recomputes the SHA-256 locally, and tells you whether the result matches the certificate's anchor — without trusting our website to be reporting honestly.$ python3 verify.py <64-char-hash># → ✓ VERIFIED (or ✗ TAMPERED with exit code 1)The verifier and our hash-construction methodology will be published as an MIT-licensed open-source repository at github.com/veritimusic/verify shortly. Email methodology@veritimusic.ai for a pre-publication copy.

LEVEL 03

Methodology audit

Every metric formula, the canonical-bytes definition, the SHA-256 construction, and the verifier source are described in full on this page and will be reproducible from our public methodology repo. If anything looks suspect — flawed assumption, weak cryptography, ambiguous metric — we want to hear about it. Email methodology@veritimusic.ai.

// 08

References

Ready to audit your track?

The methodology you just read is exactly what runs on your audio.

Order an audit — £99