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?
Reading the issuance registry…
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.
Last seen in the wild reads not computed on this path, and that is the honest rendering rather than a missing feature dressed as a clean result. The join is issued payloads against detections whose watermark read returned them; monitor_detections carries watermark_payload, so it is possible, and nothing computes it. On the sample the derivation runs over 8 fixture detections, as a demonstration of the column and not as a capability.
§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.