Idea principale

Un'ontologia di business aggiornata automaticamente a partire dal codice ha un difetto simmetrico a quello della documentazione che invecchia: se cambia sistematicamente per seguire il codice, non controlla più nulla. Quando un agente introduce un errore, un secondo agente che aggiorna l'ontologia per renderlo accettabile trasforma la deriva in regola. Il modello diventa una documentazione rigenerata di continuo.

L'eccesso opposto non è migliore: un modello che vieta qualsiasi evoluzione contraria alle sue regole attuali impedisce al prodotto di cambiare.

La via di mezzo consiste nel trattare esplicitamente ogni evoluzione del modello. Quando l'evoluzione è intenzionale e chiara, si prepara una modifica versionata dell'ontologia, eventualmente applicata in un branch di lavoro prima della convalida. Quando la modifica del codice sembra contraria all'intenzione, si corregge il codice invece del modello. Quando l'intenzione è ambigua, si chiede una decisione invece di inventare una regola.

Perché è importante

Il modello diventa un contratto evolutivo tra l'intenzione e l'implementazione, e non il riflesso dell'ultimo stato del codice. È la condizione perché faccia da rete di sicurezza: il codice non deve avere automaticamente ragione.

Questo impone uno storico. Un concetto rinominato non deve diventare due concetti indipendenti, e una regola eliminata deve restare collegata alla decisione che ne ha giustificato la scomparsa — per esempio in un piccolo registro delle decisioni ispirato agli ADR.

Sfumature e limiti

Ogni evoluzione trattata esplicitamente ha un costo in attenzione umana. Se tutte le evoluzioni passano da una decisione, il dispositivo rallenta lo sviluppo che doveva mettere in sicurezza.

Domande aperte

• Oltre quale volume di evoluzioni da convalidare i team smettono di leggere le proposte di modifica del modello e le approvano per default?