Discount approval: soglie in codice, decisioni con evidence

In breve. In Accordo gli sconti sono basis point interi — 1000 significa 10,00% — e la policy che li valuta è codice versionato: le soglie vivono nel config dichiarato, la valutazione è sincrona e restituisce approvazione automatica, approvazione richiesta o rifiuto, e solo un umano può decidere. La tesi che ne ricavo, ed è interpretazione mia: la soglia che conta non è il numero, è il fatto che cambiarla senza pubblicare una nuova versione ferma il boot — così nessuno sposta un confine di nascosto. Con gli esempi e i limiti scritti. Pubblicato il 6 ottobre 2026.

Le soglie vivono nel config

Le policy sono definizioni versionate code-first, con un config dichiarato in JSON: le soglie stanno lì, mai in closure. Il config fa parte dell'impronta della definizione dichiarata — cambiare una soglia senza pubblicare una nuova versione ferma il boot. È il dettaglio che rende le soglie credibili: non sono parametri da console, sono termini versionati della policy.

La valutazione riceve un contesto congelato e restituisce in modo sincrono uno di tre verdetti, con metadati limitati di motivo, chiave di approvazione e regola corrispondente: auto_approve approva senza lasciare un record di approvazione; approval_required crea esattamente un'approvazione per versione e parcheggia il preventivo in attesa; reject lo marca rifiutato con il motivo della policy. Decisione, nome e versione della policy e impronta restano scritti sulla versione del preventivo — così i preventivi storici restano spiegabili anche dopo che è uscita la v2.

Solo l'umano decide

Il confine è una riga di codice, non una convenzione: solo un attore di tipo utente può approvare o rifiutare — un agente viene rifiutato con 403 HUMAN_APPROVAL_REQUIRED. Lo stesso rifiuto vale dove girano i soldi: un agente che chiede di approvare un preventivo scontato viene rifiutato, e solo un utente umano può decidere. Non è una promessa nel README: è un test che asserisce il rifiuto, così il confine è una proprietà del sistema.

Il resto del ciclo è altrettanto meccanico: modifiche alla bozza protette da concorrenza ottimistica, una sola decisione per versione, rifiutato che torna in bozza e si risottomette come versione 2. Ogni regola è applicata dal server, non dall'interfaccia. È la stessa disciplina dell'hub sulle approvazioni commerciali: la meccanica si genera, le decisioni si scrivono — e qui si scrivono con nome, versione e impronta.

Cosa resta etichetta, non sicurezza

Il limite principale è dichiarato nella documentazione: la chiave di approvazione richiesta — per esempio sales-manager — è un'etichetta, non sicurezza applicata. L'applicazione reale dei ruoli richiede autenticazione, segregazione e controllo accessi che il framework non spedisce: nessun sistema di autenticazione è incluso, e in sviluppo locale l'attore è dichiarato, non verificato. Il confine tiene contro un agente onesto, non contro un attaccante con accesso alla rete.

È lo stesso confine che vale ovunque nel workflow CPQ: il sistema sa dire chi ha deciso cosa, ma l'identità di chi decide diventa affidabile solo con un verificatore di autenticazione fornito dall'applicazione. E la tesi completa sull'autonomia che ne deriva è nel pillar sull'autonomia sotto controllo.

Fatti e limiti, separati

Fatti: sconti in basis point interi con troncamento mai ad arrotondamento; soglie nel config dichiarato parte dell'impronta; tre verdetti con metadati limitati; decisione, policy, versione e impronta sulla versione del preventivo; rifiuto 403 all'agente asserito dai test; una decisione per versione, concorrenza ottimistica.

Limiti: chiave ruolo come etichetta, non sicurezza; nessuna autenticazione spedita, attore dichiarato in sviluppo; il confine vale contro agenti onesti, non attaccanti di rete. Una policy e tre verdetti non misurano quanto il disegno regga in produzione: misurano che il confine esiste, è testato e dichiara cosa non fa.

Domande frequenti

Come sono espressi gli sconti?

In basis point interi da 0 a 10000, dove 1000 è il 10,00%. Il calcolo tronca e non arrotonda mai per eccesso, e lo sconto di riga si applica uniformemente a ogni componente.

Cosa succede cambiando una soglia?

Si pubblica una nuova versione della policy: le soglie fanno parte dell'impronta dichiarata, e cambiarle senza nuova versione ferma il boot. I preventivi storici restano spiegabili perché portano con sé nome, versione e impronta della policy che li ha valutati.

Chi può approvare un preventivo?

Solo un attore umano: un agente viene rifiutato con 403. Ma l'etichetta del ruolo — sales manager, finance — non è applicata: la vera enforcement dei ruoli richiede autenticazione e controllo accessi che il framework non include.

Dove è scritta la policy di esempio?

Nella documentazione del repository, con il flusso completo da catalogo a decisione: la solution Commercial Operations rimanda al registro dei claim per ciò che è provato e ciò che è limite.