Accordo sul campo: il pilot Arvo senza cosmetici

In breve. Il pilot gestito di Accordo su Arvo ha una milestone validata dal vivo il 7 settembre 2026 e 23 casi d'uso business classificati — uno validato end-to-end, nove parziali, sette non applicabili, sei differiti. Questo è il diario senza cosmetici: cosa è girato davvero, cosa è dichiarato ma non live, e le regole che vietano di confondere le due cose. Pubblicato il 6 ottobre 2026.

Il giorno in cui il giro ha funzionato dal vivo

Il 7 settembre 2026 una persona si è autenticata sul pilot, ha sottoposto una decisione di rinnovo, il worker ha liquidato e l'esito è rimasto lì dopo un riavvio. Dietro quel giro c'erano suite locali verdi su entrambi i repository — 356 su 356 da una parte, 235 su 235 dall'altra — più il drenaggio dal vivo del giorno prima e un backup con restore che ha restituito 16 tabelle identiche riga per riga.

Due difetti sono emersi solo dal vivo e sono stati chiusi lì: un URL che perdeva un parametro nel passaggio di mano e l'adattatore HTTP che lasciava cadere la query string. Li cito perché sono la parte più istruttiva: il pilot è servito anche a trovare ciò che i test locali non potevano vedere.

La milestone M1 è segnata validata con questi confini scritti: prova l'operazione delimitata del pilot, non tutti i casi d'uso e non un servizio gestito pubblico. Validata significa eseguita dal vivo con evidence datata, non mergiata.

Uno su ventitré, e perché è una buona notizia

La classificazione dei 23 casi d'uso business dice: 1 validato end-to-end, 9 parzialmente supportati, 7 non applicabili, 6 differiti con dipendenza. Il risultato è controllato meccanicamente da un test: 23 righe, identificativi distinti, ogni riga positiva cita evidence eseguibile, ogni parziale nomina la parte mancante, ogni differita nomina la dipendenza.

La riga validata è il controllo rinnovi: click umano di conferma, drenaggio del worker alla prima scrittura, esito confermato persistito, reinvio idempotente. Promossa per esecuzione, non per ottimismo — e il documento dice esplicitamente che l'infrastruttura da sola non promuove niente.

Perché è una buona notizia? Perché la milestone è segnata classificata, non validata, e la differenza è dichiarata: predizione, conteggi di supporto, diritto del consenso, notifiche e Interactions non si chiudono con un pilot di runtime. Un registro che dice cosa manca, riga per riga, è più utile di un semaforo verde: dice dove lavorare la prossima settimana. Ne ho scritto dal lato del metodo in Backlog Zero: la domanda giusta non è quante righe hai, ma quali sono vere.

Dichiarato ma non live: l'import dei prospect

Il caso più istruttivo è la fondazione customer-data: matrice di verifica chiusa (browser Chromium reale sul flusso principale, replay byte-identici, matrici di fault e corse), con la PR lasciata esplicitamente aperta e non mergiata. Implementata e verificata, sì; live, no. E il registro lo scrive come regola generale: una PR mergiata non si registra mai come capacità validata. Figuriamoci una aperta.

Sul lato pilot, intanto, la CI esterna era bloccata dalla fatturazione: il 9 settembre 2026 scatta una CI locale temporanea di sette giorni, e l'import CSV dell'owner è arrivato in fondo il giorno dopo: due fallimenti di upload, due cause radice del solo hosting condiviso, entrambe corrette dal vivo, e l'import riuscito end-to-end con ricevuta datata. Due artefatti diversi, due stati diversi, entrambi scritti: la fondazione resta non mergiata, l'import del pilot gira.

È l'esempio operativo della disciplina che tengo in tutto il cluster: ogni capacità porta con sé il suo stato vero, e lo stato si legge nei documenti, non si indovina dal codice.

Le decisioni datate che hanno cambiato strada

Due decisioni dell'owner, entrambe datate, hanno riorientato il lavoro.

L'8 settembre 2026 il prodotto gestito di default è diventato un'applicazione condivisa multi-tenant: una sola applicazione Accordo che serve molti workspace isolati, con capacità che cresce col carico aggregato. La proposta da 13 dollari al mese di stack dedicato per il secondo cliente non è approvata e non si deve fare provisioning. Il pilot dedicato esistente resta evidence dell'implementazione, non il modello del prodotto.

La seconda è un vincolo di prodotto nato come lezione della M1: l'app OAuth di GitHub creata a mano per il pilot Arvo è solo bootstrap dell'operatore e non deve mai diventare un passo di onboarding del cliente. Finché non esiste un broker di autenticazione gestito, qualsiasi flusso che chiede a un cliente di registrare un'app OAuth fallisce il gate. Il cliente non deve mai maneggiare un Client ID o un Secret.

Cosa resta fuori dallo scope, per iscritto

Chiudo con l'elenco che di solito manca negli annunci: marketing automation, profondità deal-desk e predizione data-science sono escluse dallo scope del pilot senza promozioni. Interactions non esiste. La console di prodotto non deve essere completa per il pilot di runtime: la sua prima accettazione significativa è Zeno, il cliente alla cieca. E il web CRM ha una baseline di prodotto deployata ma il giro completo sulla nuova UX non è ancora stato ripercorso dal vivo.

La tesi del pillar resta in piedi proprio per questi confini: autonomia sotto controllo significa anche saper dire cosa il sistema non fa ancora. Il resto del cluster — approvazioni e audit, igiene dati — racconta i pezzi che invece girano.

Domande frequenti

Il pilot è un prodotto che posso usare?

No. È un pilot gestito privato su un prodotto esistente, con una milestone di runtime validata e i casi business in classificazione. A parte sta il Cloud, che ha aperto la registrazione gratuita dei workspace per ciò che un Blueprint esprime; la postura gestita completa resta vincolata ai gate della roadmap.

Cosa significa che M2 è classificata e non validata?

Che le 23 righe sono onestamente etichettate e il risultato è verificabile da un test, ma i blocchi restano aperti: runtime di predizione, proiezione dei conteggi, decisione legale sul consenso, canale di notifica, Interactions. La validazione aspetta quelli, non un documento.

Perché pubblicare numeri così piccoli?

Perché sono veri. Una riga validata per esecuzione vale più di ventitré spuntate per ottimismo: chi legge sa esattamente cosa è stato provato, quando, e cosa manca. È lo stesso motivo per cui il registro vieta di registrare una PR mergiata come capacità.