Un contenuto social può sembrare un'immagine con una didascalia. In realtà, quando racconta luoghi e memoria, è una piccola pipeline: parte da materiali con una provenienza, li trasforma in un contenuto e deve arrivare alla pubblicazione senza perdere accuratezza per strada.
Sto lavorando a un progetto editoriale locale, Radici di San Giovanni Lipioni. La parte interessante, dal punto di vista dello sviluppo, non è soltanto impaginare un post: è rendere espliciti i controlli che separano una bozza da un contenuto che ci si può assumere la responsabilità di pubblicare.
Nota di trasparenza: il progetto ha regole e un workflow documentati; non sto presentando questi controlli come un sistema di automazione già implementato.
1. Prima del rendering: sapere da dove arrivano i dati
Una fotografia, una data o una testimonianza non sono input intercambiabili. Per ciascun elemento serve sapere almeno:
- qual è la fonte;
- se il fatto è documentato, ipotizzato o riportato oralmente;
- chi detiene i diritti del materiale;
- se la pubblicazione può esporre dati personali.
È una forma di provenance, simile a quella che useremmo in una pipeline dati: se non so da dove arriva un valore, non dovrei trattarlo come verificato.
2. Rendere deterministica la composizione
Per il formato principale del progetto, il canvas è 1080 × 1350 px, rapporto 4:5 e profilo sRGB. La regola è mantenere la fotografia documentaria: niente edifici aggiunti, cieli sostituiti o ricostruzioni che cambino ciò che l'immagine testimonia.
Anche il testo dovrebbe essere composto con regole esplicite: gerarchia, margini sicuri, dimensioni e posizioni prevedibili. Lasciare che ogni generazione decida liberamente dove mettere titolo e firma rende più difficile riprodurre e verificare il risultato.
3. Validare più del file
Controllare che il PNG esista non basta. La checklist del progetto considera:
- dimensioni e rapporto corretti;
- apertura dell'esportazione;
- leggibilità al 100% e al 25%;
- resa su smartphone e nel ritaglio centrale;
- contrasto, margini, overflow e collisioni;
- corrispondenza tra testo, didascalia e fonti.
Alcuni controlli si prestano all'automazione — per esempio dimensioni e rapporto — mentre altri richiedono una revisione umana. La pipeline dovrebbe distinguere chiaramente i due casi, invece di trasformare un controllo non eseguito in un finto “OK”.
4. Modellare lo stato, non solo il file
Un piccolo modello di stato rende esplicito ciò che è successo:
type PublicationState =
| "draft"
| "needs-review"
| "approved"
| "published";
Questo è uno schema illustrativo, non codice già presente nel progetto. L'idea è semplice: approved dovrebbe essere raggiungibile solo dopo i controlli richiesti; published solo dopo una pubblicazione realmente avvenuta. Non si dovrebbe mai dedurre uno stato dal nome del file o da un messaggio generato.
In un'implementazione, la transizione potrebbe essere verificata da una funzione che riceve i risultati dei controlli e rifiuta l'avanzamento se ne manca uno. La revisione visiva resterebbe comunque una decisione esplicita, non un valore inventato dal sistema.
5. La lezione pratica
La qualità non deriva dall'aggiungere più automazione, ma dal rendere verificabili i passaggi e visibile l'incertezza. Una checklist ben definita aiuta già a individuare cosa automatizzare, cosa deve restare umano e quali informazioni mancano prima di pubblicare.
Per questo progetto il passo successivo è completare l'inventario dei materiali, delle fonti e dei diritti. Solo dopo ha senso decidere quali verifiche trasformare in codice. È un ordine meno spettacolare di “aggiungiamo l'AI”, ma riduce il rischio di pubblicare qualcosa di elegante e sbagliato.
Domanda per chi lavora su strumenti di publishing o content ops: quali controlli automatizzate e quali mantenete deliberatamente come revisione umana?
