Defensive publication

The disclosure concerns systems for certifying the authorship, priority, and integrity of audio works, in particular for defending human creators against false claims that their work is machine-generated, and for tracing redistributed copies to a certified source.

Streaming platforms and rights bodies increasingly apply automated AI-detection to submitted music. Such detectors produce false positives, and an artist flagged in error has no standard way to demonstrate the human production history of the work. Existing time stamping services prove only that a file existed at a moment in time; they do not capture the progression of a work, do not bind intermediate versions to a final master, and do not survive redistribution of the audio in modified form.

The system combines four elements. First, an append-only ledger in which each record incorporates a hash of the preceding record, rendering any post-hoc modification, insertion, or deletion detectable by walking the chain, with chain integrity exposed through a public health endpoint. Second, a production trail: a container record for a work in progress, to which the creator appends snapshot records during production. Each snapshot stores only the SHA-256 hash of an audio file together with a sequence number, an optional descriptive note, the registering account, and a timestamp; the audio itself is not retained, so the creator keeps sole possession of unfinished work while the trail remains provable. Contributor credit and split records may likewise be appended, each timestamped and signed at declaration. Third, certification of a finished master: the input is transcoded to a canonical intermediate format, fingerprinted by SHA-256, screened by an anti-fraud gate (comparison of the source hash against all previously certified source and master hashes, and a watermark scan of the normalized audio including a scan of the audio reversed, to prevent re-certification of transcoded, clipped, or reversed copies), then watermarked with a psycho acoustically shaped, key-scoped inaudible watermark carrying a randomly generated 128-bit certificate identifier, delivered back in the original upload format, and recorded on the ledger. Fourth, signing and independent verifiability: each record is serialized as canonical JSON with alphabetically sorted keys and signed with ECDSA over the P-256 curve using SHA-256, each record stores the version of the signing key used, and every public key ever used is published permanently, with key rotation adding new versions and never removing old ones, so any certificate remains checkable by third parties without trusting the operator.

Any party may verify a file without an account. Verification performs two independent checks: an exact SHA-256 match against certified master hashes, confirming a byte-identical certified master; and a watermark scan performed on the audio in forward playback, reversed playback, and optionally across a range of playback speeds to detect resample-based pitch shifts, with any recovered payload resolved against the ledger to identify the source certificate. The response distinguishes an exact-match original from a watermark-traced modified copy and discloses when recovery required reversal or speed shifting. Verification uploads are deleted immediately after processing. A separate programmatic interface accepts a SHA-256 hash alone, authenticated by API key, and returns registration status with an explicit statement of the limits of hash-only matching.

The method includes a companion application running on the creator's own computer that automates the construction of the production trail without the audio ever leaving the creator's device.
The application is paired to a user account by means of a device token issued by the service and tied to that account, revocable from the account's web interface, with account recovery supported through a recovery key. Once paired, the application monitors one or more user-designated watch folders on the local file system. When a new audio file appears in a watched folder, the application computes the file's cryptographic hash locally and transmits only the hash, together with descriptive metadata, to the registry as a snapshot record for a selected work in progress. The audio file itself is never uploaded and never retained by the service, preserving the creator's sole possession of unfinished work.
The application permits the creator to select which work-in-progress container captures are attached to, to switch between multiple simultaneously active works, and to close a work whose production has been abandoned. Closing a work destroys nothing: the decision is recorded as a further ledger record, consistent with the append-only design of the whole system.

Each automatically captured snapshot may carry derived, human-readable process signals, recorded expressly as descriptive context and kept distinct from the cryptographic claims of the trail. Disclosed signals include the following.
First, a first-capture signal: when a snapshot is the first ever registered for a work, the record is flagged as the start of the trail, derived from the work's snapshot sequence number.
Second, an origin signal distinguishing freshly created files from files moved into the watched folder. The application compares the file's operating-system creation timestamp with the moment the file was first observed in the watched folder. A negligible gap indicates the file was written directly into the folder, consistent with an export or bounce from a creation tool; a substantial gap indicates the file was created elsewhere and later moved in. The signal is recorded in hedged form together with the raw time gap, so that a reader of the trail can weigh the evidence themselves, and the system does not assert a verdict beyond what the measurement supports.
Third, further descriptive context per snapshot, including the elapsed time since the preceding snapshot and whether the file's hash was previously seen by the capturing device.
Fourth, relaying of third-party provenance credentials: the application may scan a captured file for disclosed AI-generation credentials embedded by external providers, such as content-credential or watermark schemes, and where such a credential is present, record that the file carries a disclosed credential from the identified provider. The absence of such a credential is never treated as evidence of anything, and the system makes no claim to detect machine-generated content as such.
The general principle disclosed is a two-layer trail record: a cryptographically proven layer (hash, timestamp, signature, sequence, actor) and a descriptive-context layer of derived process signals that assist human interpretation without being asserted as proof.

The method as disclosed encompasses, without limitation: use of alternative hash functions, signature curves, or watermarking implementations; storage of the ledger in a database, flat file, or distributed structure; snapshot registration of any file type, including DAW project files, stems, MIDI, and session data; capture triggered by any file-system event mechanism, by a plugin executing inside audio workstation software at save or export time, by integration with cloud-synchronized folders, or by hooks into version-control systems; capture agents running on desktop, mobile, or embedded operating systems; multiple paired devices per account, with per-device attribution of snapshots; offline capture with deferred, queued upload of hashes once connectivity returns; derivation of additional process signals from file-system metadata, file naming patterns, export cadence, or session duration, recorded in the same hedged descriptive layer; and application of the entire trail, capture-agent, fingerprint, and watermark structure to other media, including video, images, and text.

The techniques above are hereby placed in the public domain as prior art as of the publication date. This publication does not grant any trademark rights, and does not constitute a license to VMI's private keys, brand, or service.