---
name: project-data-expert-knowledge
description: "Business logic dati dominio ICR — diritti, anagrafica prodotti, edizioni, linker, mediatrack (letti oggi via MyICR_Suite, dominio agnostico rispetto all'applicativo). Non contiene l'architettura del progetto app PowerBricks, quella vive in Mauro/lavoro/lavoro-python-ecosistema/PowerBricks.md"
metadata:
  type: project
---

Conoscenza di dominio sui dati ICR (diritti, anagrafica, edizioni, linker, mediatrack — oggi letti via MyICR_Suite), costruita insieme a Mauro a partire dal 2026-07-17. **(30/08/2026) Letta all'avvio dall'esperto persistente `expert-data`** (`scripts/slave-sentinels/expert-data/CLAUDE.md`) — il subagente `data-expert` che la leggeva prima è stato dismesso lo stesso giorno (preferenza di Mauro per istanze persistenti/nominabili invece di subagenti), il suo ruolo di consultazione è assorbito da `expert-data`. Letta anche da Claude.ai via `mcp-query` (mirror Drive "SecondBrain").

**Why:** una fonte di conoscenza sola-lettura sui dati (mirror SQLite/parquet lato Nave) dedicata alla business logic reale del dominio ICR — non legata a un singolo applicativo (MyICR_Suite oggi, PowerBricks se costruito domani, o altro in futuro). Base per il futuro PowerBricks ufficio e per un eventuale accesso di Elon ai dati — deve restare affidabile anche crescendo in autonomia.

**Nota storica (04/08/2026)**: questo file e il subagente si chiamavano `powerbricks-expert`/`powerbricks.md` — rinominati perché il nome lasciava intendere "esperto del progetto app PowerBricks", mentre lo scope reale è il dominio dati ICR, agnostico rispetto a quale applicativo lo consulta (vedi `project_alleggerimento_elon.md` per la distinzione fatta lo stesso giorno tra `flussi-expert` = percorso dei dati e questo = significato dei dati).

**How to apply:** Adrian scrive qui direttamente durante una sessione di lavoro sul dominio dati, in parallelo alla conversazione (non è un output da approvare voce per voce) — `expert-data` oggi è sola lettura, segnala eventuali scoperte ma non scrive qui direttamente (vedi `archivio/Adrian/riferimento/claude-cli-headless.md`, criterio operativo/architetturale). Ogni voce porta un tag di stato: `[CONFERMATO]` (validato in conversazione con Mauro/Adrian) o `[IPOTESI]` (dedotto da schema/dati, non ancora validato) — il tag è quello che rende il documento affidabile anche senza revisione a ogni riga. Sezioni vuote finché non emerge conoscenza reale.

## Due binari — PowerBricks classico vs PowerBricks LLM (Mauro, 2026-07-30)

`[CONFERMATO]` — Mauro tiene esplicitamente **due prodotti separati, non due fasi dello stesso**:
- **PowerBricks classico** — uso ufficio/colleghi: query builder visuale Blockly→JSON→SQL, **zero LLM**, 100% locale (architettura completa in `Mauro/lavoro/lavoro-python-ecosistema/PowerBricks.md`, posizionamento strategico in `Mauro/lavoro/lavoro-progetti-strumenti.md`). Questo è quello che si distribuisce.
- **PowerBricks LLM** — **solo sperimentazione**, mai distribuito ai colleghi. **È lo stesso progetto già chiamato NL query prototype** (l'"asso coperto personale" di Mauro, stesso layer semantico condiviso col classico) — non un'evoluzione, un rinominamento: "PowerBricks Plus"/NL query prototype/PowerBricks LLM sono la stessa cosa, il nome si è solo assestato nel tempo.

`[CONFERMATO — architettura candidata, non ancora scoping tecnico definitivo]` — Il 30/07 Mauro ha portato una proposta concreta per il ramo LLM: webapp vocale basata su **OpenAI Realtime API + WebRTC** (bassa latenza, gestione nativa di eco/interruzioni) con **function calling** per instradare i comandi vocali su azioni reali. Pattern: backend genera un token effimero (la API key OpenAI non è mai esposta al client) → il browser apre una peer connection WebRTC diretta con `api.openai.com` (audio + un data channel `oai-events` per eventi JSON) → il modello riconosce l'intento e emette una function call → il frontend esegue l'azione vera (nel caso PowerBricks: query sul layer semantico) e rimanda l'esito → il modello risponde a voce. Documento di riferimento portato da Mauro (con contributo Gemini): `proposta_webapp_vocale_openai.md`. Nato come idea la notte del 17/18 luglio nel contesto "come parlare con Adrian a voce su iPhone", poi riletto come modulo riusabile per PowerBricks. Da riprendere quando si vorrà scoping reale (quali funzioni esporre, routing verso il layer semantico condiviso col classico, latenza, costo per query).

## Architettura app PowerBricks classico — spostata (04/08/2026)

Non più qui: l'architettura/design del progetto app PowerBricks (specifica tecnica, discrepanza sulla join, domande aperte, scorporo da MyICR_Suite) vive ora in `Mauro/lavoro/lavoro-python-ecosistema/PowerBricks.md` — è farina del sacco di Mauro (progetto di lavoro), non conoscenza di dominio dati. Questo file (`data-expert.md`) resta la KB sulla **business logic dei dati as-is** (diritti, veg, tipologie, join tra dataset) — leggila per quello, non per l'architettura applicativa.

## Principio generale — macroanalisi, non gestionale

`[CONFERMATO]` (Mauro, 2026-07-17) — La maggior parte delle analisi richieste saranno **macroanalisi**, non un gestionale che richiede valori esatti al singolo record. **Alcune approssimazioni sono accettabili**: non serve inseguire la precisione perfetta su ogni edge case (es. i 277 prodotti con anno variabile, i 568 politipologici, singoli record anomali) quando l'obiettivo è un quadro d'insieme corretto nell'ordine di grandezza. Questo non significa essere sciatti sui dati o smettere di segnalare `[IPOTESI]` vs `[CONFERMATO]` — significa calibrare lo sforzo: le convenzioni di semplificazione già stabilite (edizione 1 di default, rifer-only, un solo campo per paesi/genere) esistono proprio per questo, e non è necessario cercare ulteriore precisione oltre quella salvo richiesta esplicita.

## Convenzioni di presentazione output

`[CONFERMATO]` (Mauro, 2026-07-17):
- **Per domande che potrebbero restituire liste lunghe**: nel dubbio, dare prima un dato di sintesi (conteggio/aggregato), e offrire il dettaglio solo su richiesta — non buttare subito l'elenco completo.
- **"ALTRI" (o qualsiasi valore residuo/aggregato di categorie minori) va sempre messo in coda** in una tabella raggruppata, indipendentemente dal suo valore numerico — non va ordinato per quantità insieme alle altre righe.
- Quando si raggruppa su un campo che ha una convenzione "solo primo campo" (paesi_produzione1, genere1), segnalarlo sempre esplicitamente (v. sopra).
- **Numeri allineati a destra nelle tabelle** (convenzione simil Excel) — in markdown, usare la sintassi di allineamento colonna (`---:`) sulle colonne numeriche.

## Schema — tabelle note

*(da popolare: struttura, chiavi, relazioni tra LINKER_REPOSITORY, LINKER_VALUTAZIONE, OTT_EXT, OTT, AnagraficaMedia, Distributori, OmdbData, Contesti, product_annotations — mirror SQLite non ancora esplorati in questa sessione)*

### Nota metodologica — accesso ai parquet

`[CONFERMATO]` (2026-07-17) — I parquet in `PYTHON/MyICR_Suite/local_db/parquet/` si leggono con `/mnt/ssd/data/Dropbox/adrian/tools/data-expert/venv/bin/python` + `duckdb.connect(':memory:').execute(f"... read_parquet('{path}') ...")`. Il modulo `pandas`/`numpy` NON è installato in quel venv → `.fetchdf()` fallisce con `ModuleNotFoundError: numpy`; usare sempre `.fetchall()` + `DESCRIBE SELECT ...` per gli schemi. Gotcha osservato: `matched` risulta una parola quasi-riservata per il parser DuckDB in questa versione (errore di sintassi come alias di colonna in certe query con subquery multiple) — usare alias tipo `mtc` per evitare il problema.

**Chiarito 30/07/2026 — non è lo stesso canale del relay di sola lettura, oggi su `gate-ufficio` (migrato 28/08/2026 dal vecchio Frank-relay).** `tools/data-expert/venv` è locale alla Nave: interroga i parquet **già sincronizzati** via Dropbox, nessun ponte, nessuna attesa. Il canale `gate-ufficio` (azione `duckdb_query`, v. `flussi-expert.md` sezione "Protocollo gate-ufficio") è un canale diverso e più lento (~30s, file-based) usato solo da `flussi-expert` per raggiungere dati **non presenti sulla Nave** (`I:\SOFTWARE\SCHEDULATORE\...`). `data-expert` non usa quel canale — non gli serve, lavora solo su dati già locali. I due meccanismi sono complementari, non ridondanti: eliminare il venv locale costringerebbe ogni query, anche su dati già disponibili, a passare dal giro lento via `gate-ufficio`.

`PYTHON/MyICR_Suite/local_db/parquet/parquet_agg/` **non esiste** al 2026-07-17 (contraddice l'istruzione base che lo dava per presente) — `emesso_agg.parquet` e `custom_agg.parquet` non trovati nel filesystem attuale. Da verificare in una prossima sessione se il path è cambiato o se gli aggregati non sono ancora stati generati.

**Provenienza sistema sorgente (Mauro, 2026-07-17)**: `[CONFERMATO]` — tutti i parquet in questa cartella arrivano da **OnAir** (sistema aziendale Mediaset), **eccetto** `gemma.parquet`, `imdb_full.parquet`, `reti_cluster.parquet` (fonti diverse). "rifer" è il nome comune del codice prodotto in OnAir (v. glossario).

### Dataset esplorati in questa sessione (schema + cardinalità)

`[CONFERMATO]` (2026-07-17, via DuckDB `DESCRIBE`/`COUNT(*)` diretti sui parquet)

| File | Righe | Colonne principali | Note |
|---|---|---|---|
| `scelte_rete.parquet` | 9.599 | `prodotto` (INT), `codice_rete` (VARCHAR, es. B6/KI/7C), `slot` (VARCHAR, es. "MA", "PT E", "PT G") | Mapping prodotto→rete+slot di palinsesto. `[IPOTESI aperta, 2026-07-17]`: il codice `ParquetToAccessWeekly/core/custom_anagrafica.py` (flussi-expert) usa una colonna `s.rete`/`s.tipologia`/`s.stagione` su questo stesso parquet con valori estesi (es. `'CANALE 5'`, `'CINE34'`, `'RETEQUATTRO'`) — colonne non censite nel campione originale (solo `prodotto`/`codice_rete`/`slot` erano state osservate). Lo schema reale di `scelte_rete.parquet` è quindi più ricco di quanto documentato qui — da riverificare con `DESCRIBE` completo. |
| `reti_cluster.parquet` | 36 | `codice_rete`, `rete_6chr`, `rete_2chr`, `rete_estesa`, `cluster_rete` | Anagrafica reti — dimensionale piccola, mappa i codici brevi (es. `B6`→`CINE34`, cluster `MED. TEM.`) usati altrove (scelte_rete, emesso). **Terza codifica scoperta (2026-07-17, da codice pipeline)**: esiste ANCHE un set di codici legacy VBA a 2 caratteri, diverso sia da `codice_rete` (B6/KI/7C) sia da `rete_estesa` (CINE34) — usato solo per l'output legacy `SC_RETE_SINTESI`: `CANALE 5→C5`, `ITALIA 1→I1`, `RETEQUATTRO→R4`, `LA 5→L5`, `IRIS→IR`, `CINE34→C34`, `TWENTYSEVEN→C27`, `ITALIA 2→I2`, `20→20`, `FOCUS→FO`, `TOP CRIME→TC`. **Attenzione**: tre sistemi di codifica rete coesistono (codice_rete tipo B6, rete_estesa tipo CINE34, codice legacy tipo C34) — non confonderli tra loro, contesti diversi usano codifiche diverse.
| `osservatorio.parquet` | 34.306 | `codice`, `imdb`, `titolo`, `paese`, `genere`, `tipologia`, `subgenere`, `anno`, `rete`, `platform`, `stato`, `produttore`, `regia`, `cast`, `episodi`, `durata`, `giorno_ora`, `trama`, `note_programmazione`, ... | Tutto VARCHAR (anche numeri/date come stringa). Sembra un dataset di "osservazione mercato/palinsesto" (titoli visti su reti terze, non necessariamente Mediaset) — non ancora chiaro il suo ruolo nel flusso di business |
| `cast.parquet` | 1.774.501 | `prodotto` (INT), `ruolo`, `descr_ruolo` (es. FOTOGRAFO, MONTATORE, COSTUMISTA), `progr_ruolo`, `progr_cast`, `nome`, `cognome`, `ccprodtip` | Cast/troupe per prodotto (non per edizione) — un prodotto ha molte righe cast |
| `imdb.parquet` | 110.631 | `codice` (INT), `riferimento_imdb` (VARCHAR, es. `tt0068446`) | Mapping codice prodotto interno → id IMDb |
| `imdb_full.parquet` | 1.280.205 | `IMDB_CODICE`, `TIPOL`, `TO` (titolo originale), `TI` (titolo italiano?), `DUR`, `ANNO`, `GENERE`, `VOTO`, `VOTANTI`, `REGISTA`, `CAST` | Sembra un dump/mirror locale del dataset pubblico IMDb (dimensioni compatibili con IMDb non-Mediaset-specific) |
| `gemma.parquet` | 51.921 | prefissi `A_*` (acquisizione: stato, titolo, data, distributore, tipologia, autore/regista, cast, codice prodotto, cod imdb, episodio, supporto, deadline, note...) e `V_*` (valutazione/screening: stato + colonne per rete — C5, I1, R4, LA5, I2, IRIS, TOP, FOC, C20, CI34, C27, CIN, INF, EMO, ENE, COM, STO, CRI, ACT) | Sembra il tracking di acquisizioni/screener di prodotti in valutazione (prima ancora di diventare "prodotto" Mediaset a tutti gli effetti) — le colonne V_* per rete ricordano gli stessi codici rete/cluster di `reti_cluster` e `scelte_rete` (IRIS, C20, ecc.) `[IPOTESI]` |

### Verifica chiave (prodotto, edizione) su prodotti.parquet

`[CONFERMATO]` (2026-07-17) — `prodotti.parquet` ha 226.125 righe e 226.125 combinazioni distinte di `(prodotto, edizione)`: **è una chiave univoca**, zero duplicati (`GROUP BY prodotto, edizione HAVING COUNT(*)>1` → 0 righe). `prodotto` da solo NON è univoco (208.818 valori distinti su 226.125 righe) → un `prodotto` può avere più `edizione` (edizioni multiple = probabilmente doppiaggi/versioni/rimontaggi dello stesso titolo). `prodotti.parquet` è la tabella dimensionale prodotto+edizione, confermata.

### Struttura diritti.parquet — osservazione diretta (non ancora business logic)

`[CONFERMATO]` (2026-07-17, osservazione diretta di record) — `diritti.parquet` ha **75 colonne** (non 60+ come stimato inizialmente), non 51.378 di cui verificate cardinalità+join sotto. Struttura:
- Blocco base per riga-diritto: `id_diritto` (BIGINT, PK), `prod`, `ediz` (→ prodotti), `tipologia`, `d_t` (visto: solo valori `D`/`T`), `ragsoc_distr` (ragione sociale distributore), `perc` (percentuale, es. 100.0), `pass_cons`/`pass_cons_tot`/`pass_eff`/`pass_eff_tot` (DOUBLE — passaggi consentiti vs effettivi, totale vs per-riga? `[IPOTESI]`), `decr`/`scad` (date di decorrenza/scadenza del diritto), `causale` (codice VARCHAR tipo '01','03','20'...), `flag_inib` (S/null — flag inibizione), `decr_inib`/`scad_inib` (date inibizione), `contratto` (INT, id contratto), `riga` (INT, riga nel contratto), `situazione` (INT, molti valori distinti: 1,3,6,10,11,12,15,16,18,19,23,27,32,66,80,82,84,86,181,361 — codice di stato del diritto `[IPOTESI]`), `fr_rr` (visto: F/R/M/S/null — probabile Free/Rete? o First-Run/Repeat-Run `[IPOTESI]` da validare)
- **Blocco "WIN" ripetuto 9 volte** (`_WIN_1` … `_WIN_9`): `CONTRAENTE_WIN_n`, `DECR_WIN_n`, `SCAD_WIN_n`, `CAUSALE_WIN_n`, `CAUSALE_INIBIZIONE_WIN_n`, `NOTE_WIN_n` — 9 "finestre" (window di sfruttamento/cessione?) associate allo stesso diritto, tipicamente valorizzate solo le prime N (es. record osservato con WIN_1..WIN_3 popolati con `CONTRAENTE_WIN=BUENAV`, decorrenze annuali consecutive 2007→2008→2009, `CAUSALE_INIBIZIONE_WIN='BLOCCO WINDOW RETI FREE'`, `NOTE_WIN='CESSIONE A DISNEY CHANNEL'`) — pattern che suggerisce **cessioni/sub-licenze del diritto a terzi per finestre temporali successive**, con causale di inibizione che blocca lo sfruttamento su reti free durante quella finestra. `[IPOTESI] — da validare con chi conosce la regola reale, massima cautela`
- Molti diritti "semplici" (osservati id 1, 2) hanno tutte le colonne WIN_* a NULL — il pattern multi-finestra non è la norma, è un caso particolare (cessioni/co-produzioni?)
- **Priorità (2026-07-17, indicazione di Mauro)**: il blocco WIN è importanza secondaria — da tralasciare completamente per ora, focus su altre parti dello schema diritti/business logic.

### diritti_enrich.parquet

`[CONFERMATO]` (2026-07-17) — 51.378 righe, chiave `id_diritto` univoca, **match 1:1 completo con `diritti.parquet`** (51.378=51.378, join perfetto). Colonne: `id_diritto`, `fornitore_cluster` (VARCHAR, es. `'altro'`), `ESCLUSIVO_TEM` (BOOLEAN, es. `False`). Sembra un arricchimento derivato a valle (clustering fornitore + flag esclusività temporale) calcolato dalla pipeline, non dato sorgente. `[IPOTESI]`

### emesso_enrich.parquet

`[CONFERMATO]` (2026-07-17) — 8.821.773 righe (stessa cardinalità di `emesso.parquet`). Colonne: `rete`, `data_emissione`, `ora_inizio`, `fornitore_diritto`, `fornitore_cluster`, `is_primetime_main` (INT/flag), `timestamp_normalizzato`, `prima_visione_recalc`. Arricchimento calcolato su `emesso` — nota: la chiave di join con `emesso` non è un id esplicito ma probabilmente `(rete, data_emissione, ora_inizio)` — da verificare in una prossima sessione se è sufficiente a garantire univocità del join.

## Come si collegano i dataset — mappa dei join (verificati)

`[CONFERMATO]` (2026-07-17, verifica diretta via JOIN DuckDB — tassi di match calcolati su valori DISTINCT)

| Join | Chiave | Copertura | Interpretazione |
|---|---|---|---|
| `diritti.(prod,ediz)` → `prodotti.(prodotto,edizione)` | prod+ediz | **31.142 / 31.142 = 100%** | Ogni combinazione (prod,ediz) presente in diritti esiste in prodotti. Join pulito, prodotti è davvero la dimensionale di riferimento |
| `diritti.prod` → `prodotti.prodotto` (solo prod) | prod | 30.314 / 30.314 = 100% | idem, anche ignorando edizione |
| `diritti_enrich.id_diritto` → `diritti.id_diritto` | id_diritto | 51.378 / 51.378 = 100% | arricchimento 1:1 puro |
| `emesso.(prodotto,edizione)` → `prodotti.(prodotto,edizione)` | prod+ediz | 131.209 / 131.219 = **99,99%** (10 combinazioni orfane) | quasi completo, minime eccezioni — possibile disallineamento temporale pipeline (emesso più aggiornato di prodotti, o viceversa) `[IPOTESI]` |
| `cast.prodotto` → `prodotti.prodotto` | prodotto | 123.824 / 123.826 = **99,998%** | quasi completo |
| `scelte_rete.prodotto` → `prodotti.prodotto` | prodotto | 6.043 / 6.043 = **100%** | join pulito |
| `imdb.codice` → `prodotti.prodotto` | codice≡prodotto | 110.627 / 110.631 = **99,996%** | `imdb.codice` è quasi certamente lo stesso spazio-id di `prodotti.prodotto` (non prod+ediz — mapping a livello di prodotto, non di singola edizione) `[IPOTESI]` |
| `imdb.riferimento_imdb` → `imdb_full.IMDB_CODICE` | tt-code | 89.291 / 100.102 = **89%** | buona ma non totale copertura — `imdb_full` è più recente/ampio (1.28M righe) ma non copre tutti i riferimenti_imdb usati internamente, oppure alcuni tt-code interni sono obsoleti/errati `[IPOTESI]` |
| `osservatorio.imdb` → `imdb.riferimento_imdb` | tt-code | — | **0 righe di osservatorio hanno `imdb` valorizzato** nel campione controllato in modo utile: la query di join non ha prodotto risultati interpretabili in questa sessione, da riverificare — molte righe hanno `imdb IS NULL` (visto nei sample) |
| `gemma.A_CODICE_PRODOTTO` → `prodotti.prodotto` | codice≡prodotto | 4.872 / 4.873 = **99,98%** (su 51.921 righe totali, solo 4.873 hanno A_CODICE_PRODOTTO non-null — la maggioranza delle righe gemma NON è ancora collegata a un prodotto Mediaset) | coerente con l'ipotesi che gemma tracci acquisizioni/screener *prima* di diventare prodotto anagrafato — molte righe restano senza codice prodotto perché scartate/non ancora finalizzate `[IPOTESI]` |
| `ott.mediaset_id` → `prodotti.prodotto` | — | **non testabile come INT**: `mediaset_id` ha formato `M_<numero>` (es. `M_20715`, `M_814004`) — nessun cast diretto a INT riesce (0/54.902 con TRY_CAST semplice). Serve strip del prefisso `M_` prima di confrontare con `prodotti.prodotto` — da rifare in una prossima sessione | namespace diverso, servirebbe normalizzazione esplicita |
| `boxoffice.prodotto` → `prodotti.prodotto` | prodotto | non ancora verificato il join (solo verificata cardinalità: 39.741 righe, 39.741 prodotti distinti → **un solo record boxoffice per prodotto**, niente edizione in boxoffice) | `incasso`/`spettatori` valorizzati solo per 20.533/20.530 righe su 39.741 (~52%) — molti prodotti hanno boxoffice "anagrafico" (stagione, data_debutto, distributore) senza i numeri economici `[CONFERMATO su null-rate]` |

### Sintesi struttura dati emergente `[IPOTESI]`

- `prodotti.(prodotto, edizione)` è la vera tabella dimensionale/anagrafica centrale — quasi tutti i fact table (diritti, emesso, cast tramite prodotto, scelte_rete, imdb) joinano con copertura ≥99,99%.
- `prodotto` da solo è quasi un id "titolo/opera"; `edizione` distingue varianti (doppiaggi/versioni) dello stesso prodotto — coerente con cast e imdb che sono chiavati solo su `prodotto` (il cast non cambia per edizione, l'id IMDb nemmeno).
- `diritti`/`diritti_enrich` sono il cuore del dominio economico-legale: chi ha il diritto di trasmettere cosa, per quanto, con eventuali cessioni a terzi (blocco "WIN").
- `emesso`/`emesso_enrich` sono il cuore del dominio di messa in onda effettiva (palinsesto storico).
- `gemma` sembra il livello "a monte" di acquisizione/valutazione (pre-prodotto), con l'80%+ delle righe non ancora collegate a un prodotto Mediaset codificato.
- `ott` vive in un namespace di id separato (`M_<n>`) — probabilmente id di piattaforma streaming Mediaset Infinity/OTT, da riconciliare esplicitamente con `imdb_id` (colonna presente in ott.parquet) piuttosto che con `prodotti.prodotto` direttamente.

## Business logic — diritti

*(da popolare oltre alla struttura osservata sopra — sensibile, richiede validazione esplicita prima di essere data per acquisita. Ipotesi correnti sul pattern WIN_1..9 riportate sopra nella sezione schema, tutte `[IPOTESI]` non validate)*

**Il bacino "core" dei diritti = Free+Analogico (2026-07-17, Mauro)**: `[CONFERMATO]` — storicamente, per ICR, i diritti che contano al 100% sono quelli **Free+Analogico**, usati dalle reti Free principali Mediaset (C5/I1/R4 e affini). Il nostro `diritti.parquet` (L2) è filtrato esattamente per riflettere questo bacino (v. `flussi.md`, Passi 16-18, per il dettaglio tecnico e quantitativo del filtro).

**Free+DVB-T — origine e problema noto (Mauro, 2026-07-17)**: `[CONFERMATO]` — introdotto ~1-2 anni fa dall'**ufficio diritti/contratti** (stesso ufficio che gestisce anagrafica/emesso OnAir, responsabile **Sara Ragazzi**) per gestire contratti di prodotti trasmissibili su **canali secondari** (non C5/I1/R4), senza coinvolgere ICR. ICR ha dovuto costruire un workaround (la logica `NOT EXISTS` nel filtro L1→L2, v. KB flussi) per far confluire questi prodotti nello stesso bacino evitando duplicati con l'Analogico. **Problema aperto segnalato da Mauro**: oggi **non c'è alcun modo di sapere, guardando `diritti.parquet` o MyICR_Suite/PowerBricks, che un prodotto è arrivato tramite questo canale "secondario"** — l'informazione (colonna `piattaforma`) viene rimossa dal filtro. Dovrebbe invece essere sempre esposto che questi prodotti sono "utilizzabili sui secondary channels" — candidato concreto per un fix futuro, non ancora implementato.

## Business logic — edizioni

`[IPOTESI]` (2026-07-17) — `edizione` sembra rappresentare varianti dello stesso `prodotto` (es. doppiaggi diversi, rimontaggi, versioni per piattaforma) piuttosto che episodi di una serie — dedotto dal fatto che cast e imdb sono chiavati solo su `prodotto`, non su `(prodotto, edizione)`. Da validare: non ho ancora verificato la semantica esatta guardando `prodotti.parquet` per un singolo `prodotto` con più `edizione` fianco a fianco.

## prodotti.parquet — approfondimento (sessione 2026-07-17, seconda sessione)

### Schema completo

`[CONFERMATO]` — 226.125 righe, 25 colonne totali (non "60+" come stimato genericamente nell'istruzione iniziale — quella cifra era probabilmente riferita a `diritti.parquet`, che ha davvero 75 colonne). Chiave univoca `(prodotto, edizione)` già confermata in sessione precedente.

| Colonna | Tipo | Note |
|---|---|---|
| `prodotto` | INTEGER | id opera/installment |
| `edizione` | INTEGER | id variante di montaggio/versione |
| `program_id` | VARCHAR | **chiave surrogata univoca a livello di riga**: 226.125 valori distinti su 226.125 righe — id tecnico 1:1 con (prodotto,edizione), sembra un id di sistema (forse EPG/palinsesto) `[IPOTESI]` |
| `titolo_italiano` | VARCHAR | include suffisso `[Ed. N]`/`[ED. N]` per edizioni successive alla prima |
| `titolo_originale` | VARCHAR | costante tra le edizioni dello stesso prodotto |
| `descr_edizione` | VARCHAR | descrizione testuale della variante — **campo mai usato operativamente** `[CONFERMATO]` (Mauro, 2026-07-17). Utile solo com'è stato usato finora: per capire retrospettivamente la semantica di `edizione` durante l'esplorazione (v. Pattern A/B sotto), non da includere in filtri/output di analisi richieste |
| `unico_seriale` | VARCHAR | `U`/`S` — v. sotto |
| `superserie_descr` | VARCHAR | nome del franchise/saga (v. sotto) |
| `superserie_id` | INTEGER | id franchise/saga |
| `superserie_extkey` | VARCHAR | chiave esterna del franchise — 10.079 valori distinti, stesso numero di `superserie_id` distinti → mappa 1:1 con superserie_id, probabile id di un catalogo esterno/legacy `[IPOTESI]` |
| `stagione` | INTEGER | numero di stagione — proprietà del `prodotto` (v. sotto), quasi sempre valorizzata solo sulla riga `edizione=1` |
| `durata` | INTEGER | minuti, varia per edizione (lunghezza del taglio) |
| `cromia` | VARCHAR | enum, v. sotto |
| `veg` | VARCHAR | enum, v. sotto — **non è "versione edulcorata/genitori"**, l'ipotesi di partenza era sbagliata |
| `num_episodi` | INTEGER | **numero di episodi anagrafici** (non necessariamente coincidente con gli episodi effettivamente andati in onda in `emesso`) — `[CONFERMATO]` (Mauro, 2026-07-17). Fonte variabile: può arrivare dal fornitore o da fonti diverse, quindi non è garantita coerenza/precisione assoluta. Varia per edizione (stesso prodotto confezionato in più/meno episodi tra edizioni diverse) — vale la regola generale: **per default considerare solo l'edizione 1** come standard. |
| `paesi_produzione1/2/3` | VARCHAR | fino a 3 paesi, **in ordine di importanza decrescente** (`paesi_produzione1` = paese più importante) — `[CONFERMATO]` (Mauro, 2026-07-17). Regola per filtri tipo "dammi tutti i prodotti con paese=Italia": per default si considera **solo `paesi_produzione1`**, a meno che non venga richiesto esplicitamente di guardare anche gli altri campi — **ma a differenza della regola analoga su `tipologia`/edizione, qui va sempre segnalato esplicitamente all'utente che si sta considerando solo il primo campo**, così può affinare la richiesta se intendeva includere anche paesi_produzione2/3. `[CONFERMATO]`
| `anno_produzione` | INTEGER | `[CONFERMATO]` (Mauro, 2026-07-17): `NULL` e `0` sono **equivalenti**, entrambi significano "campo vuoto/non impostato" (1.306 NULL + 13.811 a `0` su 226.125 righe) — trattare `0` come NULL in ogni query/filtro. Valori fuori range comune (es. 2027-2029, o 1895-1899) sono **da considerarsi validi se ragionevoli**, non rumore da scartare a priori. Come `tipologia`, una minoranza di prodotti (277 su ~207.525 con anno noto) ha `anno_produzione` diverso tra edizioni — vale la stessa convenzione generale: **considerare sempre solo l'edizione 1**. |
| `genere1/2/3` | VARCHAR | fino a 3 generi, **stessa convenzione di `paesi_produzione1/2/3`** — ordine di importanza decrescente (`genere1` = più importante), per filtri su genere si considera default solo `genere1`, **segnalando sempre esplicitamente** che si sta considerando solo il primo campo — `[CONFERMATO]` (Mauro, 2026-07-17) |
| `provenienza` | VARCHAR | enum: `DA DEFINIRE` (133.115), `ACQUISTATO` (70.352), `AUTOPRODOTTO RTI` (20.729), `AUTOPRODOTTO GRUPPO` (735), `COPRODOTTO RTI` (710), `COPRODOTTO GRUPPO` (481). **Regola definitiva (Mauro, 2026-07-17)**: `[CONFERMATO]` — **non considerare `provenienza` per default**, va usata solo se una richiesta chiede esplicitamente un'analisi specifica su di essa. Il campo di riferimento per identificare l'autoproduzione è **`veg='FICTION AUTOPRODOTTA'`**, non `provenienza` — coerente col fatto che la corrispondenza tra i due campi è debole/incoerente (v. sotto). |
| `vm` | VARCHAR | enum, v. sotto — vietato ai minori/classificazione censura |
| `tipologia` | VARCHAR | enum, es. FILM, TELEFILM, MINISERIE, SIT COM, CARTOON, SPORT, DOCUMENTARI, ecc. (~60 valori distinti) |

### Semantica di `edizione` — osservazione diretta su esempi concreti

`[CONFERMATO]` — `edizione` **non** rappresenta doppiaggi/lingue (ipotesi della sessione precedente, ora corretta) ma **varianti di montaggio/taglio/censura dello stesso contenuto**. Due pattern distinti osservati, a seconda del `tipologia`:

**Pattern A — seriali/sitcom (es. `LOVE BUGS 1` prodotto 116629, `CAMERA CAFE' '05` prodotto 119948, entrambe 11 edizioni)**: ogni edizione è un **diverso formato di confezionamento degli stessi contenuti** per la messa in onda — `descr_edizione` varia da `SEGMENTI` (812 pezzi da 2') a `PUNTATE "ORIGINALI"` (24 episodi da 50') a `DA 40'` (12 ep da 42') fino a `VENDITA - SENZA RIMANDI/CARTELLI` (114 ep da 22'). `durata` e `num_episodi` cambiano ad ogni edizione, `titolo_originale` resta identico. Sembra la stessa materia prima tagliata in modi diversi per slot di palinsesto o canali di vendita diversi.

**Pattern B — film (es. prodotto 69 `FIAMMA DEL PECCATO`, 224, 232, 276, 293, 310, 318, ecc., quasi tutti con 2 edizioni)**: le due edizioni sono quasi sempre una coppia **versione con divieti / versione "libero da divieti"** — `descr_edizione`='VM 16' + `vm`='V.M. 16' su un'edizione, `descr_edizione`='LIBERO DA DIVIETI' + `vm`='LIBERO DA DIVIETI' sull'altra, stessa `durata`, stessa `cromia`. In questo pattern `vm` e `descr_edizione` sono praticamente ridondanti/allineati. Altri casi minori: `DIVISO IN 2 PARTI`, `PROVENIENZA VIDEOTECA` vs `ORIGINALE`.

`cromia` e `veg` **non variano tra edizioni dello stesso prodotto** nei campioni controllati (sia seriali che film) — sono proprietà del `prodotto` (del materiale sorgente), non della singola edizione. `[CONFERMATO su campione, non su tutto il dataset]`

`descr_edizione` valori più frequenti: `ORIGINALE` (202.358, stragrande maggioranza — la prima edizione "di base"), poi `LIBERO DA DIVIETI` (1.774), `VM 14`/`VM 18` (1.644/1.227), `TURNER` (1.041 — probabile fornitore/broadcaster di provenienza), `AUTOCENSURA` (976), `RIDOTTA` (622), tagli a durata fissa (`DA 78'`, `DA 3'`, ecc.), `4K` (420 — variante di qualità/formato tecnico).

### Prodotti "politipologici" — tipologia diversa tra edizioni dello stesso rifer

`[CONFERMATO]` (2026-07-17, termine confermato da Mauro: "politipologici") — normalmente `tipologia` è stabile per `prodotto` (208.249/208.818 prodotti = 99,7% ha una sola tipologia su tutte le sue edizioni), ma esiste una minoranza reale: **568 prodotti** (563 con 2 tipologie diverse, 5 con 3) hanno `tipologia` diversa tra le edizioni dello stesso rifer. Esempi concreti verificati:
- prodotto 1361 "BATTAGLIE NELLA GALASSIA": ediz.1 = FILM (ORIGINALE), ediz.2 = TV MOVIE (TELEVISIVA)
- prodotto 1531 "IL CASTELLO DI CAGLIOSTRO": ediz.2 = FILM (CINEMATOGRAFICA, col titolo "LUPIN III: IL CASTELLO DI CAGLIOSTRO"), ediz.1/3 = TV MOVIE
- prodotto 6078 "LA CASA NELLA PRATERIA": alterna TELEFILM (ediz.1/2) e TV MOVIE (ediz.3/4/5) tra le edizioni
- prodotto 6481 "AIUTAMI A SOGNARE": ediz.1 = FILM, ediz.2 = MINISERIE (EDIZIONE TELEVISIVA DA 185')

Pattern coerente con la logica già nota di `edizione` come variante di formato/confezionamento: quando la variante di montaggio cambia abbastanza da attraversare il confine tra due tipologie (es. film cinema → tv movie per la messa in onda, o film → miniserie per una versione spezzata), la `tipologia` cambia insieme all'edizione. **Nota operativa**: quando si filtra/aggrega per `tipologia` (es. per lo scope ICR), un prodotto "politipologico" può comparire in più bucket di tipologia a seconda dell'edizione considerata — da tenere presente per non contare o escludere erroneamente questi 568 casi.

**Regola di convenzione per filtri su tipologia (Mauro, 2026-07-17)**: `[CONFERMATO]`. Per domande tipo "dammi tutti i FILM in library", la convenzione è filtrare **solo su `edizione=1`** — coerente con la regola generale "usa rifer/edizione=1 per semplificare le estrazioni" già stabilita. Se `tipologia` dell'edizione 1 è `FILM`, il prodotto è incluso; se l'edizione 1 non è `FILM` (anche se un'altra edizione lo è, caso politipologico), il prodotto **non** viene incluso — l'edizione 1 è l'unica fonte di verità per questo tipo di filtro, non si guarda alle altre edizioni.

**⚠️ Ambito della regola, precisato il 30/08/2026 dopo un errore reale**: questo filtro `edizione=1` riguarda **domande sulla composizione dell'anagrafica/library** (`prodotti.parquet`, o join che passano da lì) — serve a non contare due volte lo stesso prodotto quando ha più edizioni. **Non si applica a conteggi di eventi di messa in onda su `emesso.parquet`**: lì ogni riga è già una trasmissione reale distinta (non un prodotto anagrafico), quindi filtrare a `edizione=1` esclude scorrettamente trasmissioni vere andate in onda con un'edizione diversa dalla 1 — non è una convenzione di semplificazione lì, è un errore. Esempio reale: "quanti FILM ha trasmesso Rete4 in prima serata nel 2026" va contato su `emesso` con `tipologia='FILM'` e `fascia='PR'`, **senza** filtro su `edizione` — la sentinella `expert-data` ha applicato la regola fuori scope la prima volta che è stata interrogata, dando 31 invece del corretto 38.

### `superserie_id`/`superserie_descr`/`superserie_extkey` — franchise/saga, NON stagione

`[CONFERMATO]` — un `superserie_id` raggruppa **più `prodotto` diversi** (non edizioni dello stesso prodotto). Media 6,4 prodotti per superserie (mediana 3), fino a 346 (caso `OLIMPIADI`, superserie_id=16441 — evento ricorrente, non serie TV in senso stretto). 10.079 superserie distinte, 74.113 righe (~33% del totale) hanno superserie_id valorizzato — non tutti i prodotti appartengono a un franchise.

Esempio pulito, serie TV vera (`BEAUTIFUL`, superserie_id=14380, 49 prodotti distinti): ogni **stagione è un `prodotto` diverso** (`BEAUTIFUL I` = prodotto 77916 stagione=1, `BEAUTIFUL II` = prodotto 54283 stagione=2, ... fino a `BEAUTIFUL XX` = prodotto 3029276 stagione=20), più prodotti "satellite" senza numero di stagione (speciali, riedizioni, assemblaggi, DVD, versioni per pay-tv). **Conferma il punto 5 della consegna**: la stagione di una serie TV NON è codificata come edizione diversa dello stesso prodotto, ma come **prodotto diverso nella stessa superserie**. `edizione` all'interno di un singolo prodotto/stagione resta un taglio/formato di montaggio (coerente col Pattern A sopra).

`superserie_extkey`: 10.079 valori distinti = stesso conteggio di `superserie_id` distinti → mappa 1:1, probabile id di un catalogo esterno (es. legacy o EIDR-like) per lo stesso franchise. `[IPOTESI]`

### `unico_seriale` — flag film-vs-serie confermato con eccezioni

`[CONFERMATO]` — due valori dominanti: `U` (151.684 righe) e `S` (74.438 righe), più 3 righe anomale/sporche (`CAMPO`, un titolo portoghese, `ORIGINALE` — probabile errore di data entry, valore finito nella colonna sbagliata). Forte correlazione con `tipologia`:
- `U` (Unico) → 83.962 `FILM`, 17.549 `TV MOVIE`, 14.160 `CORTOMETRAGGIO` — contenuti stand-alone
- `S` (Seriale) → 9.633 `TELEFILM`, 8.605 `INTRATTENIMENTO LEGGERO`, 6.148 `PROGRAMMI INFORMATIVI`, 5.666 `MUSICA`, 5.168 `CARTOON`, 3.344 `MINISERIE`, 2.068 `SIT COM`, 810 `TELENOVELAS`, ecc. — contenuti seriali/programmi ricorrenti

La correlazione non è perfetta al 100% (es. 10 `FILM` con `S`, 140 `TV MOVIE` con `S`, 362 `TELEFILM` con `U`) ma è fortissima — conferma l'ipotesi del punto 4 della consegna: `unico_seriale` è sostanzialmente un flag "film/opera singola" vs "programma seriale/ricorrente".

### Colonne enum — valori distinti con conteggio

`[CONFERMATO]`, colonne enum-like osservate:

- **`cromia`**: `COLORI` (195.171), `BIANCO NERO` (23.195), `SCONOSCIUTO` (5.961), `MISTO` (1.668), `COLORIZZATO` (127), `NULL` (2), `'78'` (1, probabile errore data entry — valore che sembra un anno finito qui per sbaglio)
- **`veg`**: `[CONFERMATO]` (2026-07-17, validato a voce da Mauro) — acronimo di **Valutazione Economico Gestionale**, classificazione interna Mediaset del valore del prodotto. Valori osservati: `NULL` (83.185), `DA ATTRIBUIRE` (80.519), `UNIVOCA` (14.160), lettere `E`/`D`/`C`/`B`/`A`/`F`/`G`/`H` (da 350 a 10.707 occorrenze), `FICTION AUTOPRODOTTA` (3.426), `FICTION AUTOPRODOTTA RAI` (1.950), `EVER GREEN` (411), `ALTRI` (383), `VISTO-DA ATTRIBUIRE` (224), `TOP` (204), `SUPER TOP` (46), `NON GESTITA` (3). Resta da chiarire la scala/ordine esatto delle lettere A-H e il criterio di attribuzione — non più il nome/scopo della colonna, quello è confermato.
- **`vm`** (vietato ai minori — questo sì è la classificazione età/censura): `NULL` (171.746), `LIBERO DA DIVIETI` (35.109), `INEDITO` (8.021), `V.M. 14` (5.419), `V.M. 18` (4.936), `V.M. 16` (877), `BOCCIATO` (13), `SCONOSCIUTO` (3), `DA DEFINIRE` (1)
- **`tipologia`**: ~60 valori, top: `FILM` (83.972), `TV MOVIE` (17.689), `CORTOMETRAGGIO` (14.178), `INTRATTENIMENTO LEGGERO` (13.643), `DOCUMENTARI` (10.424), `SPORT` (10.171), `TELEFILM` (9.995), `MUSICA` (9.594), `PROGRAMMI INFORMATIVI` (7.502), `CARTOON` (5.855), `REALITY` (4.612), `MINISERIE` (3.514), `SIT COM` (2.098), `NOTIZIARI` (1.208), coda lunga di tipologie di nicchia (RIASSUNTO*, SPONSOR*, INTERATTIVO*, VODCAST, PODCAST, MICRODRAMA...)
- **`unico_seriale`**: v. sopra
- **`provenienza`**: v. tabella schema sopra

### Correzione a ipotesi precedenti

`[CONFERMATO]` — Corregge la voce in "Business logic — edizioni" scritta nella sessione precedente: l'ipotesi che `edizione` fosse "doppiaggi diversi, rimontaggi, versioni per piattaforma" era nella direzione giusta per il concetto generale (variante dello stesso prodotto) ma la formulazione "doppiaggi" non trova riscontro nei dati — non è mai emerso un pattern lingua/doppiaggio negli esempi controllati. Il pattern reale è: **taglio/formato di montaggio** (seriali: confezionamento in episodi di lunghezza diversa) o **variante di censura/rating** (film: VM vs libero da divieti). La voce originale resta `[IPOTESI]` ma va integrata con questa osservazione più precisa.

## Business logic — rifer/edizione (sessione 2026-07-17, terza sessione)

*Priorità esplicita di Mauro: "Fondamentale è capire la logica di rifer e edizione". Approfondimento oltre lo schema (già in "prodotti.parquet — approfondimento" sopra), guardando l'uso a valle in diritti/emesso/boxoffice.*

### 1. Distribuzione quantitativa edizioni per prodotto

`[CONFERMATO]` (query aggregata su tutte le 208.818 combinazioni `prodotto` distinte di `prodotti.parquet`, 226.125 righe totali):

| N. edizioni | N. prodotti | % |
|---|---|---|
| 1 | 195.923 | 93,82% |
| 2 | 9.878 | 4,73% |
| 3 | 2.146 | 1,03% |
| 4 | 549 | 0,26% |
| 5 | 206 | 0,10% |
| 6–11 | 116 | 0,06% |

Media 1,08 edizioni/prodotto, mediana 1, massimo osservato 11. **La stragrande maggioranza dei prodotti (93,8%) ha un'unica edizione** — il caso multi-edizione è una minoranza reale ma non trascurabile (~6,2%, oltre 12.800 prodotti).

**Edizione "principale"/default**: `[CONFERMATO]` — `edizione=1` è **sempre presente** per ogni prodotto (208.818/208.818, 100%), è sistematicamente la `MIN(edizione)` e non esiste alcun prodotto con edizione minima diversa da 1. Per i prodotti multi-edizione, la numerazione è quasi sempre contigua da 1 a N (12.800/12.895 = 99,3% dei casi con MAX(edizione)=N. edizioni), con una piccola minoranza (95 casi) di numerazione non contigua (edizioni "saltate", verosimilmente eliminate/deprecate nel tempo). **`edizione=1` è l'edizione di riferimento/default** — coerente con l'osservazione già fatta in sessione 2 che `descr_edizione='ORIGINALE'` è il valore stragrande maggioranza (202.358/226.125).

### 2. diritti.parquet: a quale (prod, ediz) sono legati i diritti?

`[CONFERMATO]` (join `diritti.(prod,ediz)` vs conteggio edizioni disponibili in `prodotti` per lo stesso `prod`, su tutti i 31.142 prod distinti presenti in diritti):

Per i prodotti che hanno **una sola edizione** in `prodotti.parquet`, ovviamente i diritti usano quella (22.758 casi, banale). Il dato interessante è sui prodotti **multi-edizione**:

| N. edizioni in prodotti | N. edizioni distinte toccate da diritti | N. casi |
|---|---|---|
| 2 | 1 | 4.920 (90,1%) |
| 2 | 2 (tutte) | 538 (9,9%) |
| 3 | 1 | 1.371 (94,4%) |
| 3 | 2 | 53 |
| 3 | 3 (tutte) | 28 |
| 4 | 1 | 314 (79,3%) |
| 4 | 2–4 | 77 |

**Pattern dominante (≥90% nella maggior parte delle fasce): i diritti sono legati a UNA SOLA edizione del prodotto, tipicamente `edizione=1`** (6.745/6.821 = 98,9% dei casi "1 sola edizione toccata" su prodotti multi-edizione, quella edizione è proprio la 1). Solo una minoranza di prodotti ha diritti distinti per più edizioni.

Osservando i casi in cui i diritti **coprono più edizioni dello stesso prodotto** (campione qualitativo, es. prod 1689 "film VM16/VM14 + colorizzate", prod 3096066/3138760 "miniserie ORIGINALE/DA 50'/4K"), emerge che **quando ci sono più righe diritti per edizioni diverse, tendono ad avere causale/contratto/decorrenza diversi** — non è un semplice "duplica il diritto su ogni edizione", ma diritti effettivamente distinti (es. prod 7316: `ediz=1` diritto Turner 1997-2002, `ediz=2` stesso Turner 1997-2002 **più** un secondo diritto Warner 2002-2006 sulla stessa edizione 2 — la colorizzazione ha una storia contrattuale propria).

`[IPOTESI]` — il pattern suggerisce che **il diritto normalmente si acquisisce sull'edizione "madre" (edizione=1, la versione originale/di riferimento)**, e viene esteso/duplicato su altre edizioni solo quando quella specifica variante (es. colorizzata, 4K, taglio per durata) ha una storia di sfruttamento/contratto propria e distinta. Da validare con chi gestisce i contratti.

### 3. emesso.parquet: quale edizione va effettivamente in onda, e coincide col diritto attivo?

`[CONFERMATO]` — distribuzione delle edizioni trasmesse su 8.821.773 messe in onda: `edizione=1` copre 8.373.859/8.821.773 = **94,9%** dei passaggi totali, il resto si distribuisce su edizioni 2-11 in ordine decrescente (ediz=2: 310.346, ediz=3: 76.547, ...). Anche isolando solo i prodotti multi-edizione (quelli dove la scelta non è banale), `edizione=1` resta la stragrande maggioranza dei passaggi effettivi. **La messa in onda usa quasi sempre l'edizione 1/default**, coerente col fatto che è la versione "ORIGINALE".

**JOIN emesso→diritti su (prodotto=prod, edizione=ediz)**, con verifica se `data_emissione` cade nel range `[decr, scad]` del diritto (campione ~130-260K righe, con `TRY_CAST` perché `data_emissione` è VARCHAR):
- Match diretto su (prod,ediz) esistente in diritti: solo **~36-40%** delle righe emesso (indipendentemente dalla data)
- Di queste, solo **~31%** cade effettivamente nel range decr-scad del diritto trovato (quindi ~11-12% delle righe emesso totali hanno un diritto attivo e coerente in data sulla stessa combinazione prod+ediz)

**Causa identificata**: `[CONFERMATO]` — la bassa copertura è in larga parte spiegata da `provenienza` del prodotto. Filtrando il campione emesso per prodotti **senza alcun diritto associato** (a livello di `prod`, ignorando la data), la distribuzione di `provenienza` è dominata da `AUTOPRODOTTO RTI` (64.733 casi) e `DA DEFINIRE` (113.762) — cioè contenuti auto-prodotti da RTI, che **non hanno bisogno di un diritto di acquisizione** (Mediaset è già proprietaria). Filtrando invece i prodotti **con** diritto associato, la distribuzione è dominata da `ACQUISTATO` (55.951) — cioè i diritti tracciano principalmente contenuti di terzi acquisiti. `[IPOTESI]`: `diritti.parquet` è quindi (in gran parte) il registro dei contratti di **licenza/acquisizione da fornitori esterni**, non un registro universale di "permesso a trasmettere" per ogni contenuto — l'autoproduzione non ha (o ha in minima parte, 4.306 casi residui) una riga diritti corrispondente.

Isolando solo `provenienza='ACQUISTATO'` (dove ci si aspetterebbe massima copertura): il match diretto (prod,ediz) + range date resta comunque solo ~20% (25.941/129.685). Allargando il match a "qualsiasi edizione dello stesso prod copra la data" (non solo l'edizione emessa), la copertura sale a **34,2%** (26.235/76.667 sul sottocampione con almeno un diritto sul prod) — e **quando esiste un diritto che copre la data, l'edizione del diritto coincide con l'edizione effettivamente trasmessa nel 90,7% dei casi** (23.672/26.094). Questo conferma che **quando il match c'è, edizione-diritto ed edizione-emessa sono coerenti** — il problema principale non è un mismatch di edizione, ma una copertura temporale incompleta del dataset diritti.

**Sulle emissioni ACQUISTATO senza copertura in-range** (campione di 18.477 casi con almeno un diritto noto per il prod): 2.027 (11%) cadono **prima** della prima `decr` nota, 3.085 (17%) cadono **dopo** l'ultima `scad` nota, solo 326 (1,8%) cadono in un vero "buco" tra due contratti consecutivi.

`[CONFERMATO]` (validato a voce da Mauro, 2026-07-17) — **`diritti.parquet` è uno storico completo**, non uno snapshot dei soli contratti correnti/attivi: contiene tutti i diritti, anche quelli passati/scaduti. Questo **esclude** l'ipotesi che il gap di copertura fosse dovuto a uno snapshot parziale — essendo lo storico completo, le emissioni fuori range (prima della prima `decr` o dopo l'ultima `scad` nota) restano un fenomeno reale da spiegare altrimenti (es. dati mancanti a monte, contratti non digitalizzati/tracciati in questo sistema, o casi legittimi di trasmissione fuori diritto formale) — non un artefatto di "snapshot non aggiornato". `[IPOTESI aperta]` sulla causa specifica del gap residuo, ma la domanda sullo snapshot-vs-storico è chiusa.

### 4. boxoffice.parquet: nessuna edizione, ha senso?

`[CONFERMATO]` — `boxoffice.parquet` è chiavato solo su `prodotto` (39.741 righe = 39.741 prodotti distinti, un solo record per prodotto). Incrociando con `prodotti.parquet`: 36.282 di questi prodotti hanno 1 sola edizione, ma **2.843 ne hanno 2, 518 ne hanno 3, fino a 8 in un caso** — cioè esistono prodotti con box office noto che HANNO più edizioni in prodotti.parquet, eppure il box office resta un valore unico per `prodotto`. **Ha senso semanticamente**: l'incasso al cinema è un evento che accade una volta, sulla release cinematografica originale — le edizioni successive (VM diverso, 4K, taglio TV, colorizzata) sono rimontaggi/varianti post-hoc per la messa in onda TV, non nuove uscite cinematografiche con incasso proprio. `[IPOTESI]` — coerente con l'idea che `edizione` sia un concetto "a valle" (di broadcasting/confezionamento), mentre il box office è un dato "a monte" (dell'opera cinematografica in sé, quindi del `prodotto`).

### Tipologie prodotto — scope ICR (in corso di definizione)

`[CONFERMATO]` (2026-07-17) — Ricognizione `prodotti.tipologia` incrociata con presenza in `diritti.parquet` (LEFT JOIN su `prodotto`, quota di prodotti per tipologia con almeno un `id_diritto` associato):

| tipologia | n_prodotti | con_diritto | % |
|---|---|---|---|
| FILM | 79.607 | 15.155 | 19,0% |
| TV MOVIE | 15.460 | 5.443 | 35,2% |
| CORTOMETRAGGIO | 14.141 | 977 | 6,9% |
| INTRATTENIMENTO LEGGERO | 11.592 | 728 | 6,3% |
| SPORT | 10.079 | 66 | 0,7% |
| DOCUMENTARI | 9.967 | 2.036 | 20,4% |
| MUSICA | 9.416 | 198 | 2,1% |
| TELEFILM | 7.403 | 2.593 | 35,0% |
| PROGRAMMI INFORMATIVI | 7.353 | 1 | 0,0% |
| INFORMAZIONE/ATTUALITA'/NEWS | 7.291 | 117 | 1,6% |
| CARTOON | 4.642 | 1.283 | 27,6% |
| EVENTI SPORTIVI | 4.433 | 0 | 0,0% |
| REALITY | 4.367 | 77 | 1,8% |
| SOFT NEWS | 3.636 | 3 | 0,1% |
| PROGRAMMI CULTURALI | 3.511 | 43 | 1,2% |
| MINISERIE | 2.627 | 669 | 25,5% |
| PROGRAMMI SPORTIVI | 2.368 | 0 | 0,0% |
| EVENTI | 2.154 | 0 | 0,0% |
| SIT COM | 1.597 | 799 | 50,0% |
| NOTIZIARI | 1.200 | 0 | 0,0% |
| GAME SHOW/QUIZ | 1.068 | 70 | 6,6% |
| PROSA | 961 | 3 | 0,3% |
| SIGLE | 918 | 0 | 0,0% |
| TELEVENDITE | 509 | 0 | 0,0% |
| TALK SHOW | 492 | 0 | 0,0% |
| TELENOVELAS | 461 | 273 | 59,2% |
| RIASSUNTO MINISERIE | 377 | 1 | 0,3% |
| SOAP | 363 | 122 | 33,6% |
| SHOPPING | 343 | 0 | 0,0% |
| NOTIZIARI SPORTIVI | 245 | 0 | 0,0% |
| RIASSUNTO TELEFILM | 151 | 0 | 0,0% |
| SEGNALE ORARIO/INTERVALLO | 144 | 0 | 0,0% |
| PROMO | 139 | 0 | 0,0% |
| MONOSCOPIO | 123 | 0 | 0,0% |
| TELEROMANZO | 46 | 12 | 26,1% |
| RIASSUNTO TELENOVELAS | 35 | 0 | 0,0% |
| SPONSOR SIGLE/CARTELLI/PROMO | 55 | 0 | 0,0% |
| MICRODRAMA | 16 | 0 | 0,0% |
| PODCAST | 13 | 8 | 61,5% |
| (coda lunga: RIASSUNTO*, INTERATTIVO*, TELESHOPPING, JINGLE, VODCAST, SOSPESI, BUMPER, DA DEFINIRE, NULL, ecc.) | ~40 righe totali | ~0 | ~0% |

**Confermato (Mauro, 2026-07-17)**: le tipologie a copertura quasi-nulla **non interessano ICR** — e per Mauro non dovrebbero nemmeno comparire nella tabella diritti (le poche righe con diritto lì presenti, es. SPORT 0,7% o PROGRAMMI INFORMATIVI 1 riga, sono eccezioni/rumore, non un pattern sistemico da spiegare). Tipologie escluse dallo scope ICR (confermato): SPORT, EVENTI SPORTIVI, PROGRAMMI SPORTIVI, NOTIZIARI, NOTIZIARI SPORTIVI, TALK SHOW, TELEVENDITE, SHOPPING, PROGRAMMI INFORMATIVI, INFORMAZIONE/ATTUALITA'/NEWS, MUSICA, REALITY, SOFT NEWS, PROGRAMMI CULTURALI, PROSA, SIGLE, RIASSUNTO*, SPONSOR*, INTERATTIVO*, MICRODRAMA, e tutta la coda lunga a conteggio marginale.

**Tipologie core ICR — confermato (Mauro, 2026-07-17)**: FILM, TV MOVIE, TELEFILM, MINISERIE, SIT COM, TELENOVELAS, SOAP, TELEROMANZO, DOCUMENTARI, CORTOMETRAGGIO. `[CONFERMATO]` — nota: CORTOMETRAGGIO e TELEROMANZO sono core ma di **interesse residuale** (pochissimi prodotti, specialmente TELEROMANZO che ha solo 46 prodotti totali) — non il focus principale del lavoro quotidiano, ma vanno comunque trattati come in-scope quando compaiono.

**Nota di priorità pratica (Mauro, 2026-07-17)**: queste 10 tipologie core copriranno **~99% del numero di richieste** che verranno fatte al subagente — è la base su cui va costruita la comprensione approfondita della business logic, il resto è edge case.

**Ulteriori esclusioni confermate (Mauro, 2026-07-17)**, oltre al gruppo a copertura quasi-nulla già escluso sopra: **PODCAST, GAME SHOW/QUIZ, INTRATTENIMENTO LEGGERO, CARTOON** sono out of scope ICR nonostante una copertura diritti non trascurabile (61,5%, 6,6%, 6,3%, 27,6%) — conferma che la % di copertura diritti è solo un indizio, non il criterio di scope: lo scope ICR è definito dal business, non deducibile puramente dai dati. `[CONFERMATO]`

### Sintesi operativa: come si sceglie l'edizione in un contesto X

`[IPOTESI]` (pattern osservato consistentemente su più dataset, ma la logica di *decisione* non è mai esplicita nei dati — solo il risultato):

- **Default universale**: se non specificato altrimenti, l'edizione di riferimento è **`edizione=1`** ("ORIGINALE") — è sempre presente, copre il 94,9% delle messe in onda reali, ed è il target implicito della maggior parte dei diritti.
- **I diritti si acquisiscono principalmente sull'edizione 1**; un'edizione alternativa (colorizzata, 4K, taglio diverso) ottiene una riga diritti propria solo quando ha una storia di sfruttamento/contratto distinta e documentata (minoranza di casi, ~10% dei prodotti multi-edizione).
- **La messa in onda (emesso) sceglie l'edizione in base a esigenze di palinsesto/durata/formato** (coerente col Pattern A/B di sessione 2: segmenti vs puntate intere, VM vs libero da divieti) — quando c'è un diritto attivo per quella specifica edizione/data, coincide nel 90%+ dei casi; quando manca, è più probabile un buco nella copertura temporale di `diritti.parquet` che un errore di edizione.
- **Il box office non segue l'edizione**: è un attributo del `prodotto` (opera cinematografica), non ri-articolato per variante di montaggio TV.
- **Confermato (Mauro, 2026-07-17)**: `diritti.parquet` è uno storico completo di tutti i diritti, anche passati/scaduti — non uno snapshot parziale.
- **Causa del gap identificata (Mauro, 2026-07-17)**: il calcolo del gap sopra usava **tutto `emesso.parquet` senza filtrare per rete**, e questo altera il risultato. Due fattori concorrenti, entrambi confermati da Mauro:
  1. **`emesso.parquet` comprende anche le reti della concorrenza**, non solo le reti Mediaset — è naturale che una trasmissione su una rete concorrente non abbia un diritto Mediaset associato, non è un buco nei dati.
  2. `diritti.parquet` **copre solo alcune tipologie di prodotto** — quelle che sono il focus dell'ufficio ICR (Indirizzo e Controllo Risorse, l'ufficio di Mauro — v. glossario), non l'universo di tutto ciò che va in onda su tutte le reti.
  
  Quindi il "gap" ~60-65% non è (solo/principalmente) un problema di dati mancanti/contratti non tracciati — è in buona parte strutturale: **trasmissioni su reti concorrenti, o prodotti/tipologie fuori dallo scope ICR, semplicemente non hanno diritti Mediaset in questo dataset, per definizione, non per errore**. `[IPOTESI aperta]`: quali tipologie esattamente sono in-scope ICR, e quali codici `rete`/`codice_rete` sono Mediaset vs concorrenza — da chiarire in una prossima sessione, ripetendo l'analisi del gap filtrando per rete Mediaset e/o tipologia invece che su tutto emesso indistintamente.
- **Regola di convenzione — tabelle senza `edizione` (Mauro, 2026-07-17)**: `[CONFERMATO]`. Alcune tabelle si joinano solo su rifer/`prodotto`, senza `edizione` (es. `boxoffice`, `cast`, `imdb`, `scelte_rete`) — non perché l'informazione sia indifferente all'edizione in senso assoluto, ma **per convenzione si assume edizione=1 per non duplicare le righe estratte** quando un prodotto ha più edizioni. Non è quindi un'evidenza che quei dati "non varino per edizione" (l'ipotesi fatta in sessione 1 per boxoffice era nella direzione giusta per intuito ma la ragione vera è questa convenzione operativa, non solo la natura del dato) — è una regola pratica di join per evitare la fan-out quando si estrae.
- **Regola di semplificazione più generale (Mauro, 2026-07-17, rafforzata)**: `[CONFERMATO]`. Non è limitata alle tabelle che mancano fisicamente di `edizione` — **in molte estrazioni conviene comunque considerare solo rifer/`prodotto` come chiave**, anche quando `edizione` sarebbe disponibile, per semplificare (evitare fan-out/duplicazione quando non è strettamente necessario scendere al dettaglio edizione). **Regola operativa esplicita**: di default si vuole **una sola riga per prodotto**, cioè si considera **solo edizione=1**, a meno che la domanda non richieda esplicitamente di scendere a livello di edizione. Esempio concreto dato da Mauro: "quanti film abbiamo in library" → si contano i prodotti con `tipologia='FILM'` **sulla sola edizione 1**, non su tutte le edizioni. **L'uso del dettaglio per edizione è quindi il caso residuale/eccezionale**, non il default — va attivato solo quando esplicitamente richiesto (es. domande su montaggio/formato/censura, dove l'edizione è l'oggetto stesso dell'analisi).

## Glossario termini di dominio

- **ICR**: acronimo di **Indirizzo e Controllo Risorse** — l'ufficio di Mauro, quello per cui MyICR_Suite/PowerBricks vengono costruiti. `[CONFERMATO]` (Mauro, 2026-07-17). Importante per interpretare `diritti.parquet`: il dataset copre solo le tipologie di prodotto in-scope per ICR, non l'intero universo di contenuti trasmessi — v. "Business logic — rifer/edizione" per l'implicazione sul gap emesso→diritti.
- **prod/prodotto**: id del titolo/opera/installment (es. una singola stagione di una serie, o un film) nell'anagrafica MyICR — `[CONFERMATO]` livello "opera/installment", raggruppabile in un `superserie_id` se fa parte di un franchise. **Nome comune nel business: "rifer"** (riferimento/codice del prodotto) — `[CONFERMATO]` (validato a voce da Mauro, 2026-07-17). La coppia rilevante è **(rifer/prodotto, edizione)** — coerente con la chiave univoca già confermata su `prodotti.parquet`. **"rifer" = il codice OnAir** (v. voce OnAir sotto) — `[CONFERMATO]` (Mauro, 2026-07-17).
- **OnAir**: sistema aziendale Mediaset, fonte di provenienza di quasi tutti i parquet in `PYTHON/MyICR_Suite/local_db/parquet/` — `[CONFERMATO]` (Mauro, 2026-07-17). **Eccezioni (NON da OnAir)**: `gemma.parquet`, `imdb_full.parquet`, `reti_cluster.parquet` — tutti gli altri file (diritti, prodotti, emesso, boxoffice, cast, scelte_rete, imdb, osservatorio, ecc.) arrivano da OnAir. "rifer" è il nome comune del codice prodotto **in OnAir**.
- **ediz/edizione**: variante di montaggio/taglio/formato dello stesso prodotto — `[CONFERMATO]` (aggiornato 2026-07-17, seconda sessione: **non** doppiaggio/lingua come ipotizzato prima, ma taglio/durata/confezionamento episodi per i seriali, o variante di censura/rating (VM vs libero da divieti) per i film — v. sezione "prodotti.parquet — approfondimento" per il dettaglio)
- **superserie_id/superserie_descr**: id/nome del franchise o saga che raggruppa più `prodotto` (es. tutte le stagioni di BEAUTIFUL, o tutte le edizioni delle Olimpiadi) — `[CONFERMATO]`. Non tutti i prodotti hanno una superserie (solo ~33% delle righe la valorizza)
- **stagione**: numero di stagione di una serie TV — `[CONFERMATO]` è una proprietà del `prodotto` (ogni stagione = prodotto diverso nella stessa superserie), non dell'`edizione`
- **unico_seriale**: flag `U` (unico/stand-alone: film, tv movie, cortometraggio) vs `S` (seriale/ricorrente: telefilm, sitcom, programmi, notiziari) — `[CONFERMATO]`, correlazione fortissima ma non perfetta con `tipologia`
- **veg**: **Valutazione Economico Gestionale** — classificazione interna Mediaset del valore del prodotto — `[CONFERMATO]` (validato a voce da Mauro, 2026-07-17). **Scala di importanza completa, dalla più alta alla più bassa (confermato da Mauro, 2026-07-17)**:
  1. SUPER TOP
  2. TOP
  3. EVER GREEN
  4. A
  5. B
  6. C
  7. D
  8. E
  9. F
  10. G
  11. H
  12. FICTION AUTOPRODOTTA
  13. DA ATTRIBUIRE — *stessa rilevanza dei successivi fino a FICTION AUTOPRODOTTA RAI incluso*
  14. UNIVOCA
  15. NON GESTITA
  16. VISTO-DA ATTRIBUIRE
  17. ALTRI
  18. FICTION AUTOPRODOTTA RAI

  **Valori-errore identificati (Mauro, 2026-07-17)**: `BIANCO NERO`, `119`, `107` compaiono come valori di `veg` nei dati ma sono **palesemente errori di data entry** (valori che appartengono ad altre colonne, es. `cromia` o un anno, finiti per sbaglio in `veg`) — da escludere/ignorare in qualsiasi analisi su questa colonna, non rappresentano livelli reali della scala.

  **`FICTION AUTOPRODOTTA` — nota operativa importante (Mauro, 2026-07-17)**: `[CONFERMATO]`. Nonostante la posizione nella scala (sotto H), **non è un livello di valore come gli altri** — è una categoria a sé stante e molto rilevante: identifica i prodotti **autoprodotti da Mediaset** (come dice il nome). Spesso le richieste chiederanno di **scorporare/evidenziare separatamente** la fiction autoprodotta dal resto dei prodotti — va trattata come una dimensione di analisi propria, non solo come un gradino della scala di valore.
  - `FICTION AUTOPRODOTTA RAI` **non ha la stessa affidabilità**: i criteri di classificazione usati per questo valore non sono certi — trattarla con più cautela rispetto a `FICTION AUTOPRODOTTA` (Mediaset).
  - **Verifica fatta (2026-07-17)**: l'ipotesi "FICTION AUTOPRODOTTA non dovrebbe avere diritti salvo residuali" è **smentita dai dati** — `[CONFERMATO]` (verifica diretta, non più ipotesi). Su 1.677 prodotti con `veg='FICTION AUTOPRODOTTA'`, ben **1.268 (75,6%) hanno almeno un diritto associato** in `diritti.parquet` — tutt'altro che residuale. `FICTION AUTOPRODOTTA RAI` invece ha **0/1.479 (0%)** con diritto — coerente con l'essere gestita da RAI e non da Mediaset (nessun contratto Mediaset da tracciare).
  - **Spiegazione confermata (Mauro, 2026-07-17 + verifica dati)**: sono in gran parte **diritti illimitati**. Su ~2.060 righe diritti collegate a prodotti FICTION AUTOPRODOTTA, **1.740 (causale `'07'`) hanno `scad = 9999-12-31`** — una data-placeholder che rappresenta l'assenza di scadenza reale (diritto perpetuo, coerente col fatto che Mediaset possiede l'opera). Stesso pattern per `causale '04'` (21 casi). Durata media calcolata ~2,5 milioni di giorni conferma il pattern. `[CONFERMATO]`: `scad=9999-12-31` con `causale='07'` è il marcatore di "diritto illimitato" nel dataset — utile pattern generale, non solo per fiction autoprodotta, da tenere presente ovunque si interpreti `decr`/`scad`.
  - **Verifica corrispondenza `veg` ↔ `provenienza` (2026-07-17, su richiesta di Mauro)**: `[CONFERMATO]` — **la corrispondenza è debole, non un mapping 1:1**. Per `veg='FICTION AUTOPRODOTTA'` (a livello riga prodotto+edizione, 3.426 righe), `provenienza` si distribuisce su: `AUTOPRODOTTO RTI` (1.436), `COPRODOTTO RTI` (634), `ACQUISTATO` (602 — **incoerenza interna**: una riga "fiction autoprodotta" con provenienza "acquistato"), `AUTOPRODOTTO GRUPPO` (521), `COPRODOTTO GRUPPO` (225), `DA DEFINIRE` (8). Viceversa, **la stragrande maggioranza delle righe con `provenienza='AUTOPRODOTTO RTI'` (19.160/20.729 ≈ 92%) ha `veg` NULL**, non FICTION AUTOPRODOTTA — quindi "autoprodotto RTI" non implica affatto quella classificazione veg. Unica correlazione forte trovata: `veg='FICTION AUTOPRODOTTA RAI'` → `provenienza='DA DEFINIRE'` nel 99,6% dei casi (1.942/1.950), coerente col fatto che per contenuti RAI Mediaset non traccia la provenienza. **Conclusione**: `provenienza` e `veg` sono classificazioni indipendenti/incoerenti tra loro, non ridondanti — non usare l'una come proxy dell'altra. **Decisione operativa (Mauro, 2026-07-17)**: per identificare l'autoproduzione si usa sempre `veg='FICTION AUTOPRODOTTA'`, `provenienza` si ignora salvo richiesta esplicita.
- **vm**: classificazione età/divieti del prodotto (LIBERO DA DIVIETI, V.M.14/16/18, INEDITO, BOCCIATO) — `[CONFERMATO]`, spesso ridondante con `descr_edizione` quando l'edizione è proprio la variante di censura
- **cromia**: colore/bianco-nero del materiale — `[CONFERMATO]` proprietà stabile del prodotto, non varia tra edizioni nei campioni controllati
- **program_id**: colonna in prodotti.parquet, chiave surrogata univoca 1:1 con (prodotto,edizione) — 226.125 valori distinti su 226.125 righe, probabile id tecnico di sistema esterno (EPG?). **Non rilevante per il business**: campo non usato — `[CONFERMATO]` (Mauro, 2026-07-17). Il riferimento che conta è "rifer"/`prodotto` + `edizione`, non `program_id`.
- **d_t**: colonna in diritti.parquet, valori osservati solo `D`/`T` — significato non ancora dedotto `[IPOTESI aperta]`
- **fr_rr**: colonna in diritti.parquet, valori osservati `F`/`R`/`M`/`S`/null. **Chiarito da flussi-expert (2026-07-17)** — dizionario dati ufficiale (`PYTHON/MyICR_Suite/app/modules/powerbricks/NL_semantic_layer/NL_QUERY_SCHEMA.md`, non ancora confermato a voce da Mauro): `F`=First Run (prima visione), `R`=Repeat (replica), `S`=Sospeso, `M`=Mixed — quindi tutti e 4 i valori sono spiegati, nessuno resta "sporco"/anomalo. Da tenere distinto `CalFrRr` (in `ParquetToAccessWeekly/core/custom_diritti.py`): è una **ricalcolazione derivata** solo F/R per la vista legacy Access, non il valore originale di `fr_rr` — le due cose non vanno confuse. `[IPOTESI forte, da documentazione interna, non confermata a voce da Mauro]`.
- **fascia** (in emesso.parquet): tabella di decodifica trovata in `NL_QUERY_SCHEMA.md` — `MA`=Mattina (06-12), `ME`=Mezzogiorno (12-14), `PO`=Pomeriggio (14-18), `PS`=Preserale (18-20), `PR`=Prima serata (20-22:30), `SS`=Seconda serata (22:30-01), `NO`=Notte (01-06), `AR`=Alba, `GR`=Giorno generico (non classificato). **Gotcha**: ~2,1M record (24% del totale) hanno `fascia` NULL — non assumere che tutti i record abbiano fascia valorizzata. `[IPOTESI, da documentazione interna]`
- **WIN_n (CONTRAENTE/DECR/SCAD/CAUSALE/CAUSALE_INIBIZIONE/NOTE)**: blocco ripetuto 9 volte in diritti.parquet, sembra rappresentare cessioni/sub-licenze successive del diritto a terzi contraenti per finestre temporali — `[IPOTESI], massima cautela, da validare con chi conosce la regola reale`
- **fornitore_cluster**: colonna in diritti_enrich e emesso_enrich — clustering derivato del fornitore/distributore, calcolato a valle `[IPOTESI]`
- **gemma**: dataset di tracking acquisizioni/screener con colonne A_* (acquisizione) e V_* (valutazione per rete) — livello pre-prodotto anagrafato `[IPOTESI]`