Trace e audit come prova, non come burocrazia

In breve. Una trace è una prova quando un altro giro la può chiudere, una macchina la può leggere, nessuno la può riscrivere e il suo perimetro è dichiarato. Tutto il resto è burocrazia: carta che nessuno rilegge. Le quattro proprietà sotto vengono da run veri — i primi quattro problemi chiusi di notte e i cinque confini del run di oggi. Questo articolo fa parte dell'hub reliability. Pubblicato il 6 ottobre 2026.

Il momento in cui ho cambiato idea

La sera del primo giro completo della fabbrica che ripara di notte ho guardato i receipt di ogni passaggio e ho pensato che sembrava burocrazia. Poi ho contato: quattro problemi chiusi su un progetto vero, PR dalla numero 4 alla 7, dall'inizio alla fine, senza che toccassi niente. La burocrazia aveva lavorato mentre dormivo.

Da allora mi sono dato una regola per distinguere le due cose, e quattro proprietà per applicarla. Una trace è una prova se supera tutte e quattro; se ne manca una, è carta.

1. Chiudibile da un altro

La prova regina: un giro diverso da quello che ha scritto la trace la deve poter chiudere. Nel run di oggi è successo cinque volte allo stesso modo — remediation e merge registrati, receipt di deploy irregistrabile per checkout di sola lettura, blocco scritto con SHA, PR e istruzioni di ripresa esatte. Il giro che avrà lo SHA sotto mano chiuderà leggendo il blocco, non chiedendo a me.

Il precedente che mi ha insegnato il formato: un deploy bloccato al mattino è stato registrato dal giro dopo, che ha letto le istruzioni nel blocco e ha ripreso da lì — blocker, poi retry, poi deploy, tre receipt in sequenza. Se la tua trace non contiene abbastanza da far ripartire uno sconosciuto, non è una prova: è un promemoria per chi c'era.

2. Machine-readable

La seconda proprietà l'ho imparata dal governor che lesse male un blocco globale: scope e verdetto sono diventati campi che una macchina sa leggere, perché una decisione lasciata all'interpretazione del lettore viene interpretata male nel punto peggiore. Vale per ogni trace: tipo di receipt in forma chiusa, chiavi univoche, timestamp con offset esplicito — niente prosa dove serve un valore.

Il corollario che applico sempre: un rifiuto scrive niente. Quando un cancello dice no, non lascia mezza riga nel registro — così il tentativo dopo riparte pulito, con la stessa chiave, senza relitti da interpretare. L'ho visto funzionare oggi: remediation rifiutata senza PR, PR aperta, stessa chiave accettata.

3. Append-only

Niente si riscrive: una decisione si scioglie con una risoluzione, non si corregge; un'indagine inconclusiva si chiude con un piano datato, non si cancella. Il registro cresce solo in avanti, e la storia di un confine si legge come sequenza — decisione, risoluzione, cura, merge, blocco, ripresa — mai come stato finale.

È la proprietà che rende inutile la fiducia nella memoria di chi ha eseguito. Il loop in cinque fasi la dice così: chi impara non ricorda, scrive test. Io aggiungo: chi esegue non racconta, lascia receipt.

4. Con perimetro dichiarato

La quarta viene dal verifier che bocciò i test verdi: il verdetto finale disse PASS solo per il tentativo contenuto. Non certificava tutto, certificava il perimetro provato — ambiente, revisione caricata, criteri misurati. Una prova senza perimetro dichiarato è un racconto, anche coi numeri grossi.

Applicata alle mie trace di oggi: ogni blocco dice cosa è verificato (produzione 200, byte identici alla build locale) e cosa manca (il receipt di deploy, che richiede lo SHA sotto mano). Il lettore sa esattamente dove finisce il certo e dove comincia l'attesa.

L'audit nel prodotto, non solo nella factory

Le stesse quattro proprietà vivono dentro Accordo, dal lato prodotto: policy deterministiche versionate nel repository, umano nominato che approva, audit registrato dove il cliente lo possiede — più un tool MCP, crm_get_trace, che legge la traccia di una decisione. La factory tiene le prove del come lavora; il prodotto tiene le prove di cosa ha deciso. Stessa disciplina, due schieramenti.

Fatti e limiti, separati

Fatti, con provenance:

• Quattro problemi chiusi di notte, PR #4–#7, receipt per passaggio (articolo fabbrica del 3 ottobre 2026).
• Scope e verdetto machine-readable dopo il blocco globale letto male (PR #296, via articolo governor del 5 ottobre 2026).
• Verdetto PASS solo per il tentativo contenuto (PR #323, via articolo verifier del 5 ottobre 2026).
• Deploy bloccato ripreso dal giro dopo via istruzioni nel blocco: blocker, retry, deploy in sequenza (ledger, 6 ottobre 2026).
• Run del 6 ottobre 2026: 5 confini con remediation+merge+blocco, deploy verificati byte-identici (31214, 30446, 28760), rifiuti che non scrivono.

Limiti:

• Esperienza da un framework solo più il dominio contenuti: il formato delle prove, non una statistica sui formati.
• I 5 deploy di oggi attendono ancora verdetto indipendente: verificati da me, non certificati.
• Una trace prova il passaggio, non la bontà della decisione: il perché resta negli articoli, non nel registro.

Domande frequenti

Quanto costa scrivere tutte queste trace?

Meno che ricordarsele: i receipt li coniano i cancelli, non io a mano — ogni passaggio che passa il gate lascia la sua riga da solo. Il costo è nel disegno dei gate, non nella scrittura.

E se nessuno le legge mai?

Allora sono burocrazia, e il test è la ripresa: se un giro mai partito prima può chiudere il lavoro leggendo solo le trace, sono prove. Altrimenti sono promemoria, e vanno riscritte come istruzioni.

Audit nel prodotto o nella factory?

Entrambi, con ruoli diversi: la factory prova come ha lavorato, il prodotto prova cosa ha deciso. In Accordo l'audit vive nel repository del cliente; qui, nel diario dei receipt.