Audit e trace delle mutazioni: ogni scrittura lascia una prova

In breve. In Accordo ogni scrittura conserva validazione, audit e trace: chi ha chiesto, chi ha deciso, sotto quale versione di policy, con quale run. Si rilegge settimane dopo con il tool MCP o il comando di trace, e il pilot l'ha provato dal vivo: una decisione che attraversa coda, worker e restart resta una riga sola. Pubblicato il 9 ottobre 2026.

Cosa resta scritto a ogni mutazione

Ogni mutazione passa da un servizio o un workflow nominato — mai direttamente in tabella — e lascia la stessa firma: l'attore che ha chiesto, la decisione presa, la policy che l'ha governata con nome, versione e impronta, e il run che l'ha eseguita. I preventivi lo mostrano bene: ogni versione è immutabile, con l'evidence per componente e l'impronta della policy che ha deciso tra approvazione automatica, richiesta di approvazione o rifiuto.

Le richieste operative portano anche gli istanti — quando sono state chieste, quando sono state liquidate — e il conteggio dei tentativi. Non è decorazione: è ciò che permette di distinguere "eseguito una volta" da "richiesto tre volte, riuscito una".

Chi decide resta sempre un umano nominato: le approvazioni sopra soglia aspettano la persona, e il divieto all'agente è un test che fallisce. È il quarto elemento della tesi sull'autonomia sotto controllo: agente, policy, umano, traccia.

Dove vive, e chi lo possiede

Nel tuo repository e nel tuo database, non in un servizio terzo: l'audit sta dove il cliente lo possiede. Sul pilot gestito la stessa disciplina vale per i deploy: ogni ambiente ha ricevute di deploy con i pin esatti — web, worker, framework — validate nel codice e nei vincoli di schema, e rileggibili dal CLI operatore. E c'è una regola che non si muove: nessun secret finisce in audit, trace, backup o telemetria.

Come si rilegge settimane dopo

Due strade. Dal codice agente: il tool MCP crm_get_trace legge un run con input, output, stato ed errori per passo. Da terminale: npm run crm -- trace <runId>. L'esempio dimostrativo pubblico lo rende concreto: preventivo Q-1042 da 180.000 euro, transizione dell'agente rifiutata dalla policy, approvazione nominata, audit registrato sul run 4d2a91 — il run resta tracciato e la decisione si rilegge con la versione di policy che la governava.

La prova dal vivo: coda, worker, restart, una riga sola

Il 7 settembre 2026, nel pilot: una persona autenticata sottopone un rinnovo (richiesta 89853f45 alle 14:39:47Z), il worker lo liquida al primo tick (14:39:51, esito decision:9e6e9f94, tentativi: 1) e l'esito resta dopo il restart. Il reinvio identico restituisce lo stesso id di richiesta con stato succeeded: quattro richieste mai esistite in tutto l'ambiente, coda vuota, nessuna duplicazione. Il giorno prima, tre richieste drenate dal vivo e il restore che aveva restituito 16 tabelle identiche riga per riga. Il racconto completo è nel diario del pilot: qui conta il punto di metodo. Una decisione che attraversa coda, worker e restart e resta una riga sola è la differenza tra registrare un verdetto e saperlo custodire.

Cosa non prova

Tre limiti, gli stessi che metto accanto a ogni meccanismo. Primo: l'attore è affermato, non autenticato — il framework non autentica nessuno, e l'audit registra fedelmente la dichiarazione: utile per ricostruire cosa ha fatto un processo, inutile come prova di chi l'ha fatto. Secondo: i nomi dell'esempio pubblico sono dimostrativi, i meccanismi no. Terzo: una trace prova il passaggio, non la bontà della decisione — il perché resta negli articoli. Sul lato factory applico la stessa disciplina alle trace dei run: la factory prova come ha lavorato, il prodotto prova cosa ha deciso.

Fatti e limiti, separati

Fatti: ogni scrittura conserva validazione, audit e trace; versioni di preventivo immutabili con impronta di policy; tool crm_get_trace e comando crm trace; ricevute di deploy con pin di web, worker e framework; richiesta 89853f45 (14:39:47Z, liquidata 14:39:51, tentativi 1); reinvio con stesso id, quattro richieste totali, coda vuota; tre drenaggi live-proof; restore 16 tabelle su 16; run dimostrativo 4d2a91; nessun secret in audit e trace.

Limiti: attore affermato finché il deploy non fornisce autenticazione; nomi dimostrativi nell'esempio pubblico; pilot su operazione delimitata, non su tutti i casi d'uso; la trace prova il passaggio, non la bontà della decisione.

Domande frequenti

Cosa registra esattamente una mutazione?

Chi ha chiesto, cosa, quando, sotto quale policy (nome, versione, impronta), con quale run e con quanti tentativi. Tutto ciò che serve per rileggerla settimane dopo: il verdetto insieme alla regola che lo governava e al percorso che l'ha eseguito.

Come rileggo una decisione di settimane fa?

Con il run: crm_get_trace via MCP o crm trace da terminale mostrano input, output, stato ed errori per passo, con la versione di policy che governava allora — le decisioni vecchie restano legate alla regola vecchia.

L'audit prova chi ha deciso?

No: prova cosa è stato chiesto e deciso, non l'identità di chi ha cliccato — l'attore è affermato finché il deploy non fornisce autenticazione. La policy fissa chi può decidere, l'audit fissa cosa è stato deciso.