Come usare l'AI per controllare le versioni dei documenti di un evento

Ore 17:42. Arriva RUNSHOW_FINAL_v7_OK2.pdf. La regia lavora sulla versione 7. Il briefing speaker cita l'orario della versione 5. La mail partecipanti è partita dalla 6.

Qual è la versione corretta?

Da sola, la domanda è sbagliata. Un evento usa più documenti collegati. Serve sapere quale insieme di versioni era approvato in un momento preciso e cosa va ricontrollato dopo una modifica.

Noi lo chiamiamo pacchetto di verità dell'evento: ID documento, versione, stato, owner, fonte, dipendenze e baseline. L'AI trova differenze e conflitti. Non decide quale file abbia autorità.

Finale non è uno stato

Un nome file racconta l'intenzione di chi lo ha salvato. Non prova che il documento sia stato approvato, distribuito o ancora valido.

finale, definitivo e ok producono una falsa certezza. La versione 8 può essere una bozza, mentre la 7 resta quella approvata per la regia.

Usa stati separati dal numero:

document_id: DOC-RUNSHOW
version: 7
status: approved
owner: show-caller
approved_at: 2026-08-16T16:30:00+02:00
supersedes: DOC-RUNSHOW@6

Il numero dice che il file è cambiato. Lo stato dice cosa puoi farci.

Il run of show dell'evento contiene cue, tempi e responsabilità operative. La gestione versioni non riscrive quei contenuti. Dimostra quale versione entra nel pacchetto usato dal team.

Scegli cosa merita una versione

Non tracciare ogni appunto. Il Teal Book, nella guida sulla tracciabilità, raccomanda un carico proporzionato: non tutto deve diventare un elemento configurabile.

Versiona ciò che riceve approvazione o crea dipendenze. In un evento possono essere:

• agenda,
• run of show,
• pianta sale,
• briefing speaker,
• lista contributi,
• piano comunicazioni,
• specifiche tecniche,
• segnaletica approvata.

Una nota personale può avere data e autore senza entrare nella baseline. Il verbale di una decisione resta una fonte. Il documento che cambia il lavoro riceve ID, versione e stato.

Un inventario corto e mantenuto batte una tassonomia perfetta che nessuno aggiorna.

Assegna ID stabili

Il nome leggibile può cambiare. L'ID no.

DOC-AGENDA: agenda editoriale
DOC-RUNSHOW: sequenza operativa
DOC-SPEAKER-07: briefing speaker 07
DOC-COMMS-PRE: comunicazioni prima dell'evento

Non mettere la data dentro l'ID stabile. La data appartiene alla versione o alla baseline. In questo modo puoi seguire lo stesso oggetto dal primo brief al pacchetto finale.

Ogni versione conserva almeno:

Campo	Uso
version	identifica la revisione
status	draft, review, approved, superseded, retired
owner	risponde del contenuto
source_ref	collega la causa del cambio
created_at	ordina gli eventi
approved_by	registra il ruolo che accetta
hash	controlla che il file non sia cambiato

L'hash verifica identità dei byte. Non verifica che il contenuto sia corretto.

Disegna le dipendenze

Il valore arriva quando sai cosa cambia insieme.

Se la sessione 3 passa dalle 15:10 alle 15:35, possono cambiare agenda, run of show, briefing del moderatore, timer, catering break e comunicazione nell'app.

Registra la relazione:

dependency:
  source: DOC-AGENDA@12
  target: DOC-RUNSHOW@7
  fields:
    - session_03.start
    - session_03.duration
  owner: show-caller

Il Teal Book descrive la tracciabilità come relazione tra componenti e documentazione lungo il ciclo di vita. Una baseline permette di riprodurre l'insieme e capire l'impatto di un cambio.

Per gli speaker, collega l'agenda al briefing e alle prove speaker. Non copiare l'orario in 4 file senza sapere da quale campo nasce.

Congela una baseline

Una baseline è una fotografia approvata di versioni compatibili.

Esempio fittizio:

baseline_id: EVT-024-T0
frozen_at: 2026-08-16T17:30:00+02:00
purpose: technical-rehearsal
documents:
  - DOC-AGENDA@12
  - DOC-RUNSHOW@7
  - DOC-SPEAKER-07@4
  - DOC-COMMS-PRE@6
approved_by:
  - event-project-manager
  - show-caller

Il T0 non significa che l'evento sia finito. Significa che prove e decisioni successive fanno riferimento a quell'insieme.

Puoi avere una baseline per prova tecnica, una per approvazione cliente e una per live. Ogni nuova baseline deriva dalla precedente e registra i cambi.

Qui tocca fermarsi 30 secondi. Se non sai dire quale baseline usa la regia, non lanciare un altro confronto AI. Prima scegli il punto di riferimento.

Prepara il diff per campi

L'AI è utile quando i documenti non hanno lo stesso formato. Può estrarre campi, allineare oggetti e proporre differenze.

Un diff leggibile contiene:

Campo	Prima	Dopo	Fonte	Impatto
sessione 3, inizio	15:10	15:35	change CHG-018	regia, speaker, app
sessione 3, durata	25 min	20 min	change CHG-018	timer, contenuti
break, inizio	15:40	16:00	derivato	catering, staff

Derivato non equivale ad approvato. Significa che il cambio a monte suggerisce una modifica. L'owner del documento la verifica.

Chiedi al modello di restituire riferimento, valore precedente, valore nuovo, confidenza e campo non trovato. Vietagli di riempire i vuoti con una stima.

change_id: CHG-018
source_ref: client-confirmation-011
proposed_updates:
  - document: DOC-RUNSHOW
    field: session_03.start
    old: 15:10
    new: 15:35
    confidence: exact
missing_evidence:
  - catering_acceptance

Controlla conflitti, non soltanto differenze

Una differenza è prevista quando una versione sostituisce la precedente. Un conflitto esiste quando 2 documenti della stessa baseline non sono compatibili.

Esempi:

• agenda approvata alle 15:35, run of show alle 15:10,
• briefing speaker con 20 minuti, timer con 25,
• comunicazione partecipanti con sala A, segnaletica con sala B,
• contributo video versione 3, regia con checksum della 2.

L'AI può scansionare la baseline e aprire conflitti. Ogni conflitto ha owner e blocco:

conflict_id: CF-022
baseline: EVT-024-T1
documents:
  - DOC-AGENDA@12
  - DOC-RUNSHOW@7
field: session_03.start
owner: show-caller
blocks:
  - technical-rehearsal

Non correggere il file in silenzio. Chiudi il conflitto con una decisione e una nuova versione.

Riapprova ciò che il cambio rende vecchio

Il Teal Book avverte che la modifica di un elemento approvato annulla quell'approvazione e può richiedere nuova verifica anche sulle parti collegate.

Nel nostro metodo, il change impact produce 3 esiti:

• no_content_change, il documento resta valido e si registra la verifica,
• new_version_required, l'owner prepara e approva una revisione,
• baseline_blocked, l'insieme non può essere usato finché il conflitto resta aperto.

Non riapprovare tutto per abitudine. Verifica solo gli elementi toccati e quelli che dipendono davvero dal cambio.

La comunicazione ai partecipanti può contenere orari e sale. Se un cambio non raggiunge quel documento, il testo pubblico diventa vecchio anche se la regia è corretta.

Distribuisci un pacchetto, non 8 allegati

Prima della prova o del live, genera un indice firmato dalla baseline:

release_pack: EVT-024-LIVE-01
baseline: EVT-024-T2
generated_at: 2026-08-21T06:45:00+02:00
file:
  - id: DOC-RUNSHOW
    version: 9
    hash: sha256:...
  - id: DOC-AGENDA
    version: 13
    hash: sha256:...
open_conflicts: 0

Il team scarica o apre quel pacchetto. Non cerca l'ultima mail.

L'indice può essere stampato. Se la connessione cade, regia e producer devono poter riconoscere il documento valido senza interrogare un agent.

Un esempio completo

Scenario fittizio. Un evento ha 4 documenti configurabili e una baseline per la prova generale.

ID	Versione	Stato	Dipende da	Owner
DOC-AGENDA	12	approved	proposta e change log	content lead
DOC-RUNSHOW	7	approved	DOC-AGENDA@12	show-caller
DOC-SPEAKER-07	4	approved	DOC-AGENDA@12	speaker manager
DOC-COMMS-PRE	6	approved	DOC-AGENDA@12	participant comms

Arriva CHG-018. La sessione 3 slitta di 25 minuti. L'AI prepara 3 diff e segnala che DOC-COMMS-PRE contiene ancora l'orario precedente.

Gli owner verificano. Nascono DOC-RUNSHOW@8, DOC-SPEAKER-07@5 e DOC-COMMS-PRE@7. La baseline T0 resta immutata. La prova usa T1.

La cronologia permette di capire quale informazione aveva il team in ogni momento, senza confondere gli stati del documento.

Misura il controllo versioni

Conta conflitti trovati prima della distribuzione, documenti senza owner, modifiche senza fonte, baseline con elementi non approvati, pacchetti aperti dopo il freeze e incidenti causati da una versione sbagliata.

Non misurare il numero di versioni come difetto. Un evento complesso può richiedere 14 revisioni corrette. Il problema è una revisione non tracciata che entra nel pacchetto sbagliato.

Guarda anche il tempo tra change e baseline aggiornata. Se il team chiude il file ma dimentica comunicazioni e speaker, il collo di bottiglia è la propagazione.

Errori che creano versioni fantasma

• usare finale come stato,
• cambiare nome e perdere l'ID,
• sovrascrivere la versione approvata,
• versionare ogni appunto,
• salvare un diff senza la fonte del cambio,
• accettare il suggerimento AI senza owner,
• aggiornare un documento e ignorare le dipendenze,
• distribuire allegati senza indice e hash,
• copiare PII o credenziali nel registro delle versioni.

La cartella delle 17:42

Prendi agenda, run of show, 1 briefing speaker e 1 comunicazione. Assegna ID e versione. Poi scrivi quale versione di ciascuno forma la baseline di oggi.

Cambia un orario.

Se non sai elencare i file da ricontrollare, hai trovato la prima dipendenza da registrare.

Porta a MAIKER HUB i 4 documenti che oggi divergono. Nel percorso Think -> Build -> Enable costruiamo ID, baseline, diff e gate di distribuzione senza lasciare che finale_v7 scelga al posto del team.