La matrice definisce la consegna prevista.
Ogni riga rappresenta un requisito dotato di versione e include: campagna, mercato, locale, canale, formato, dimensioni, tipi di file accettati, dimensione massima in byte, convenzione di denominazione e stato (obbligatorio/facoltativo).
Le importazioni richiedono: mercato, locale, canale, formato, larghezza e altezza. ID duplicati, interi positivi non validi, celle di dimensioni eccessive, file superiori a 2 MB e matrici con più di 5.000 righe causano un errore esplicito.
I metadati dei file creativi vengono ispezionati localmente.
Un *worker* del browser legge nomi, percorsi, tipi MIME, dimensioni in byte, dimensioni dell'immagine, voci ZIP e hash SHA-256. I byte grezzi dei file creativi non vengono mai inviati a VariantGate, Convex, WorkOS, Stripe o a un provider di log.
Confine di persistenzaI conteggi aggregati possono essere salvati dopo un audit autenticato. I nomi dei file dettagliati richiedono un consenso esplicito separato in futuro.
I token dei nomi dei file generano un punteggio spiegabile.
I nomi vengono convertiti in minuscolo e suddivisi in base a separatori non alfanumerici. Gli alias di locale supportati vengono normalizzati prima che i requisiti vengano classificati.
- Sotto i 46 punti: nessuna corrispondenza; il file viene segnalato come imprevisto.
- 96+ punti con un vantaggio di 15 punti: corrispondenza esatta.
- 76+ punti con un vantaggio di 12 punti: probabile corrispondenza.
- Tutti gli altri candidati accettati: incerti; richiedono una revisione.
La convalida viene eseguita dopo la fase di abbinamento.
La corrispondenza del nome file non rende il file valido di per sé. VariantGate verifica autonomamente: file da zero byte, dimensioni, tipi di file accettati, dimensione massima, completezza della nomenclatura, coerenza tra mercato e locale, copertura dei requisiti per i duplicati ed esatta duplicazione SHA-256.
Gli errori impediscono lo stato di "pronto", gli elementi da revisionare richiedono una decisione umana e gli avvisi mantengono il contesto senza modificare silenziosamente il requisito.
La copertura viene calcolata in base agli esiti dei requisiti.
Ogni requisito viene classificato come pronto, mancante, problematico o da revisionare. La percentuale di completezza è data dal rapporto tra le varianti richieste abbinate e il totale delle varianti richieste; il numero totale di problemi rimane visibile anziché essere nascosto all'interno di tale percentuale.
Lo stesso risultato versionato alimenta la vista della copertura, l'elenco delle correzioni, la revisione degli abbinamenti, la mappa di ridenominazione suggerita, il manifest, l'esportazione CSV/JSON e la ricevuta di stampa.
La V1 rimane deliberatamente circoscritta.
VariantGate non utilizza LLM per gli abbinamenti, non esamina i codec video, non sostituisce un DAM, non verifica le policy delle piattaforme pubblicitarie né carica asset. L'ambito di audit supportato è definito dalla memoria del browser e dai limiti del piano configurato.
Perché un approccio deterministico?Le correzioni alla consegna richiedono prove riproducibili. A parità di input e versione del motore, si ottiene lo stesso risultato.