Rinnovi con soglia e approvazione umana: mai un update allo storico

In breve. In Accordo la policy commerciale è codice deterministico, non giudizio di un modello: un rinnovo pari o sopra la soglia si ferma e aspetta un umano nominato — e quando si esegue, non modifica l'accordo esistente ma produce un accordo successore con il suo ordine firmato, il suo hash di documento e una riga immutabile di successione. La tesi che ne ricavo, ed è interpretazione mia: il rinnovo è il punto dove la tentazione di ritoccare lo storico è più forte, ed è esattamente lì che il sistema deve rifiutarsi — la storia dei termini non si aggiorna, si succede. Con il meccanismo e i limiti scritti. Pubblicato il 6 ottobre 2026.

La soglia che ferma

La policy è deterministica: un rinnovo pari o sopra la soglia di valore si ferma e aspetta un umano nominato. Non è il modello a decidere se il rinnovo può passare — è codice, con una soglia, e un test che lo prova. È la stessa disciplina delle approvazioni commerciali: la meccanica valuta, l'umano decide.

Il limite è dichiarato con precisione: provato per l'oggetto rinnovo integrato e la sua singola soglia di valore. Un motore di policy generale sopra oggetti custom arbitrari non esiste. Chi cerca soglie su ogni entità del suo dominio sta guardando oltre ciò che il sistema prova oggi.

Il successore, non la modifica

L'esecuzione non tocca mai lo storico: produce un accordo successore — suo ordine firmato, suo hash di documento firmato, suo termine, suo contratto, sua versione, sue righe, sua sottoscrizione e sue obbligazioni in attesa — scritto dallo stesso percorso di codice che attiva qualsiasi altro contratto, più una riga immutabile di successione che dice quale accordo sostituisce. Niente update contro righe preesistenti, da nessuna parte. Il successore non è un tipo speciale di contratto: leggerlo non richiede vocabolario nuovo — solo la lineage è nuova.

E c'è il rifiuto che conta: un accordo successore nasce solo da un ordine il cui documento firmato portava il termine commerciale. Un ordine senza quell'istantanea viene rifiutato — le sue date sarebbero metadati operativi post-firma, e niente nel repository promuove quelli a termine di rinnovo firmato. Un contratto fonte i cui termini nessuno ha classificato viene rifiutato anche lui: la risposta onesta a "era firmato?" è non si può dire, e un successore non può nascere da un non-si-può-dire.

Cosa resta alla persona

Dopo l'ordine non c'è esecuzione automatica: niente rinnovi automatici, niente esecuzione di cancellazioni, niente fatturazione, niente notifiche al cliente. Il sistema costruisce il successore e classifica le obbligazioni come esplicitamente in attesa — poi tocca alle persone. È lo stesso confine del flusso quote-to-cash: il framework congela i fatti e governa le transizioni, non manda email né addebita.

La tesi completa sul perché — agenti che propongono, policy che governa, umani che decidono — è nel pillar sull'autonomia sotto controllo. E il quadro del modello operativo che il rinnovo chiude è nell'hub revenue operations: dal lead che dice sì al contesto che arriva alla delivery, senza perdere titolarità. La solution Revenue Operations rimanda al registro dei claim per la verità di implementazione.

Fatti e limiti, separati

Fatti: rinnovo sopra soglia fermato per l'umano; accordo successore con suo ordine, hash, termine e lineage immutabile; stesso percorso di attivazione di ogni contratto; rifiuto senza termini firmati; nessuna modifica allo storico, mai.

Limiti: soglia singola sull'oggetto rinnovo integrato, nessun motore generale; termini non classificati rifiutati senza appello; nessuna automazione post-ordine. Una soglia e un successore non misurano quanto il disegno regga in produzione: misurano che il confine esiste, è testato e dichiara cosa non fa.

Domande frequenti

Chi decide un rinnovo sopra soglia?

Un umano nominato: la policy deterministica ferma il rinnovo e aspetta. Il modello non decide — valuta codice con una soglia provata dai test.

Cosa cambia nel contratto quando rinnovo?

Niente: il contratto esistente resta intatto. Nasce un accordo successore con il suo ordine firmato e una riga di successione che lo lega al precedente. La storia non si aggiorna, si succede.

Quando un rinnovo viene rifiutato?

Quando mancano i termini firmati: solo un ordine il cui documento firmato portava il termine commerciale può generare un successore. Date operative post-firma e termini non classificati non bastano — il sistema dice no.

Il rinnovo parte da solo alla scadenza?

No: non esiste rinnovo automatico, né fatturazione o notifiche automatiche. Il sistema prepara il successore e marca le obbligazioni come in attesa; l'esecuzione resta alle persone.