Reading the issuance registry…
ChoonWatermarkManifests
demoThis build is a demo. The catalog and detections are a fixed sample.Scopereading…Sound is used for one thing: a short tone when a long scan finishes while this tab is in the background. The A/B listening check plays audio either way, because there the sound is the evidence.Reading the issuance registry…
Which payloads were issued, for what — and which of them have turned up in the wild?
ai_generated is already a column in the schema and is surfaced here rather than buried: a registry that can answer which of these masters are AI-generated is answering a procurement question for free.
single_payload_per_recording — one payload per recording per backend. Per-recipient issuance needs the unique indexes on records(track_id, backend), records(isrc, backend) and watermark_records(track_id, backend) dropped (Gate 1g, production DDL, awaiting sign-off), plus recipient_id / issued_at / output_uri / revoked_at columns. Until then recipient_id is null because no issuance exists to attribute, not because attribution failed.
Sample data — Three records, carrying only fields records really declares (manifest_store.py:297), wrapped in the envelope GET /api/watermark/manifests returns. Source: src/lib/fixtures/watermark.ts. Nothing below was measured from your catalog.
| Payload | Recording | ISRC | Backend | Recipient | Rights label | Encoded label | Recorded | SNR | File | Territories | AI-generated | Last seen in the wild |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Corso Notturno rec_02044 | ITB151900024 | wavmark | no column | External | no field the record the API returns carries neither | 2026-03-12created_at, not the issuance date | 38.4 dB | gs://vibeset-fingerprinting-data/watermarked_clips/rec_02044_wavmark.wav | IT | No | gHj5tYu1OiP 0:12–0:40 · Detected | |
| Bright Room rec_00777 | USUM72100884 | audioseal | no column | Verve Catalog | no field the record the API returns carries neither | 2026-06-02created_at, not the issuance date | 41.1 dB | — no output recorded for this embed | WW | No | not read back | |
| Interstitial (generated bed) rec_03310 | — | wavmark | no column | Verve Catalog | no field the record the API returns carries neither | 2026-07-21created_at, not the issuance date | — | gs://vibeset-fingerprinting-data/watermarked_clips/rec_03310_wavmark.wav | WW | Yes | not read back |
Not read back means the join ran over 8 fixture detections and returned nothing for that payload — not that nobody has used the file. Nothing scans for a payload that was never detected in the first place, so this column is bounded by what the monitor looked at. Law 3.
§13.7 asks for ten columns. 4 of them have no field behind them in records, which declares 16 columns and none of these.
| Column asked for | Field | Why it is absent |
|---|---|---|
| Recipient | recipient_id | No column. §13.7 item 2 asks for it; nothing in records names who a payload was issued to, so per-recipient attribution — the highest-value case in the product — cannot be answered at all. |
| Issued | issued_at | created_at is preserved across re-embed (manifest_store.py:85), so it is the record’s birthday rather than the issuance date. Showing it under a column headed "Issued" would print one quantity under another’s name. |
| Revoked | revoked_at | No column. A payload issued to someone who left the label can only be deleted, and a deleted row cannot be distinguished from one that never existed. |
| Last seen in the wild | — | Derived, and the derivation has nowhere to run: it joins issued payloads to detections whose watermark read returned them. monitor_detections carries watermark_payload, so the join is possible; nothing computes it yet. |
Two rows of that table have gone stale, and both are recorded here rather than quietly rewritten. recipient_id and revoked_at are described above as “no column”. They are columns now: Gate 1g part one added recipient_id, issued_at and revoked_at to records and watermark_records, with mark_issued and revoke writing them. What is still absent is the READ: ProvenanceRecord declares none of the three and _row_to_record reads none of them, so list_records cannot carry them and the endpoint fills recipient_id and revoked_at with null from a setdefault. The column exists, the serving path does not read it, and a feature is live when the serving path reads it — so the cell above says not attributed and means it, but the reason on the record is now one layer nearer than that table says.
Filtering the registry by recipient — the query §13.7 calls the point of the page — cannot be built on this schema.
“Everything we gave this person, and where it has turned up” needs a recipient ON THE RECORD THE API RETURNS and a second payload per recording. The unique indexes at manifest_store.py:325 and :382 forbid the second payload, and the read path drops the first. The filter is missing because the data model is, which is a different problem from a missing control and is fixed in a different file. The endpoint does take backend and isrc filters and this page wires neither — those two ARE missing controls, and they are a smaller thing.