Versioning e Traccia di Audit: Chi Ha Cambiato Cosa, Quando e Perché

Emergono due domande diverse una volta che un modello ha più di una persona che lo tocca. Primo: cosa è cambiato nei numeri dall’ultima volta che il board li ha visti? Secondo: chi ha cambiato le impostazioni, i ruoli e gli inviti dello workspace, e quando? Rexfin mantiene una traccia separata e costruita apposta per ciascuna domanda, perché confondere “il modello è cambiato” con “un’impostazione amministrativa è cambiata” produce un log che nessuno può davvero usare.

Versioni del modello: snapshot, catena, diff

Ogni stato significativo di un modello viene fotografato, non semplicemente salvato sopra l’ultima versione, ma catturato come versione immutabile ancorata a una catena di hash specifica per quella operazione o incarico. Ogni nuova versione si ricollega a quella precedente tramite un hash concatenato, così chiunque può verificare la sequenza indipendentemente da Rexfin stesso. Non dovete fidarvi della parola dello strumento sul fatto che la versione sei sia davvero derivata dalla versione cinque; la catena lo dimostra strutturalmente.

La parte utile non è lo snapshot, è il diff. La versione N confrontata con la versione N-1 mostra esattamente quali righe, driver o ipotesi si sono mosse, di quanto, e a chi sono attribuite. Quel diff è ciò che alimenta la riga “cosa è cambiato dall’ultimo board” nel pacchetto per il board. Non è il ricordo di qualcuno su cosa ha modificato; è un confronto calcolato tra due stati concatenati e immutabili.

La promozione da un modello in bozza a quello pubblicato che un board o un revisore vedranno segue la stessa disciplina: la promozione viene sottoposta a revisione diff prima di avvenire, la versione pubblicata risultante è ancorata alla catena come ogni altro snapshot, ed è ripristinabile se qualcosa deve essere annullato. Un modello pubblicato non è mai una sovrascrittura silenziosa della bozza; è un passaggio revisionato con una registrazione allegata.

Azioni amministrative: un log separato a livello di tenant

Accanto al versioning del modello c’è un tipo più semplice di traccia di audit: chi ha cambiato le impostazioni dello workspace stesso. Modifiche alle preferenze, impostazioni di conformità come giurisdizione o fine dell’anno fiscale, cambi di ruolo del team, e creazione o revoca di inviti vengono tutti scritti in un log di audit dello workspace nel momento stesso in cui avvengono.

Il dettaglio che rende questo affidabile e non decorativo: la riga di audit viene scritta nella stessa transazione di database della modifica stessa. Se l’aggiornamento delle impostazioni fallisce, anche la voce di audit non viene mai scritta; non c’è modo di ritrovarsi con una voce di log che descrive una modifica che in realtà non è avvenuta, o una modifica avvenuta senza alcuna registrazione. Anche il valore “prima” in ciascuna voce viene letto all’interno della stessa transazione, così non può diventare obsoleto se due persone modificano le impostazioni nello stesso momento.

Questo log vive su una pagina delle attività riservata al solo proprietario, con le modifiche più recenti per prime, proprio perché il proprietario di uno workspace possa rispondere a “chi ha aggiunto questa persona al team” o “chi ha cambiato la nostra impostazione dell’anno fiscale” senza dover chiedere in giro.

Perché tenerle separate

Un diff tra versioni del modello e un log di audit delle impostazioni rispondono a domande diverse per pubblici diversi. Un membro del board si interessa se le ipotesi dei driver sono cambiate dall’ultimo trimestre. Il proprietario di uno workspace si interessa se qualcuno che non si aspettava è stato aggiunto con accesso in modifica. Unire i due in un unico flusso seppellirebbe il segnale a livello di modello di cui un CFO ha bisogno sotto il rumore amministrativo di routine, e seppellirebbe la responsabilità amministrativa sotto dettagli del modello che nessuno fuori dal team finance vuole vedere. Mantenerle come due tracce disciplinate, entrambe immutabili ed entrambe attribuibili, fa sì che ciascuna resti utile per il pubblico che la legge davvero.

Dove si inserisce

Il versioning sostiene la riga di diff tra versioni del pacchetto per il board e dà al gate di esportazione qualcosa di concreto da verificare: un modello non può essere esportato come definitivo se la sua stessa cronologia di versioni non lo supporta. Insieme al controllo degli accessi basato sui ruoli, la traccia di audit è ciò che trasforma “pensiamo di sapere chi ha fatto questo” in “ecco la registrazione”.

Vedete l’intera catena di fiducia nel tour del prodotto Rexfin.