---
name: project-powerbricks-knowledge
description: "Base di conoscenza business logic MyICR_Suite/PowerBricks (linker, diritti, edizioni, mediatrack) — costruita con Mauro, letta dal subagente powerbricks-expert"
metadata:
  type: project
---

Conoscenza di dominio su MyICR_Suite/PowerBricks, costruita insieme a Mauro a partire dal 2026-07-17. Letta a inizio task dal subagente `powerbricks-expert` (`.claude/agents/powerbricks-expert.md`).

**Why:** progetto derivato di PowerBricks — un subagente sandboxed (sola lettura sui dati, mirror SQLite lato Nave) dedicato a imparare la business logic reale. Base per il futuro PowerBricks ufficio e per un eventuale accesso di Elon ai dati — deve restare affidabile anche crescendo in autonomia.

**How to apply:** il subagente `powerbricks-expert` scrive qui direttamente, in parallelo al lavoro (non è un output da approvare voce per voce). 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.

## Vision — "PowerBricks Plus" (Mauro, 2026-07-18)

`[CONFERMATO — nome/vision, non ancora un progetto avviato]` — Mauro immagina un'evoluzione di PowerBricks con LLM integrato ("PowerBricks Plus"): non solo query builder visuale, ma interazione in linguaggio naturale — inclusa, come primo esempio discusso, un'interfaccia **vocale bidirezionale** (utente parla, il sistema risponde a voce) che usa lo stesso layer semantico/business logic che stiamo costruendo qui e in `project_myicr_flussi_knowledge.md`. Non ancora scoping tecnico — nato come idea la notte del 17/18 luglio, discusso nel contesto di "come parlare con Adrian a voce su iPhone", poi riletto come modulo riusabile per PowerBricks stesso, non solo per conversare con Adrian. Da riprendere quando si vorrà scoping reale (STT/TTS, routing verso il layer semantico, latenza).

## 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/powerbricks/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.

`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` (myicr-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. `project_myicr_flussi_knowledge.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.

### `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 myicr-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]`