Invarianti di fiducia

In breve

Le invarianti di fiducia sono quattro regole editoriali: non attribuire alla fonte ciò che non afferma; distinguere fatto, inferenza e decisione; verificare l’oggetto realmente usato; datare i claim che possono cambiare. Il nome è interno alla wiki. Il valore non sta nella tassonomia, ma nel fatto che un revisore possa applicarla allo stesso modo a una specifica, a un test e a una scelta architetturale.

Tre livelli, tre prove

Livello	Forma corretta	Prova richiesta
Fatto	«La revisione dichiara X»	fonte primaria datata o osservazione riproducibile
Inferenza	«Da X e Y segue probabilmente Z»	premesse citate e passaggio logico visibile
Decisione	«Per questo progetto scegliamo W»	criterio, alternativa scartata e conseguenze

La stessa frase non può occupare comodamente tutti e tre i livelli. Se una documentazione descrive un protocollo stateless, quello è un fatto; decidere dove collocare lo stato applicativo è un’inferenza progettuale; fissare una revisione specifica nella wiki è una decisione editoriale. La voce Model Context Protocol rende esplicita questa catena invece di presentare la decisione come parte della specifica.

Esempio di catena verificabile

Fatto: il probe ha interrogato il runtime usato dal task e ha ricevuto l’effetto atteso.

Inferenza: quel canale era operativo nel momento e nel perimetro del test. Decisione: il flusso può avanzare, ma il risultato non certifica altri ambienti.

Cambiare «era operativo» in «è affidabile» romperebbe la catena: un singolo probe non misura continuità, autorizzazioni future o correttezza di ogni output. Questa è la ragione per cui Verificare il canale eseguito separa presenza, avvio ed effetto osservabile.

Checklist editoriale manuale

Prima della pubblicazione, una revisione umana controlla che ogni claim temporale abbia data e fonte, le sintesi locali siano dichiarate come tali, i link portino alla pagina canonica e le lacune non siano state colmate per plausibilità. Non è una capacità della CI: i controlli automatici verificano struttura e policy, non la forza semantica di un’argomentazione. La seconda lettura cerca soprattutto quattro difetti: fonte secondaria usata al posto della primaria, versione implicita, conclusione più forte dell’evidenza e test eseguito su un sostituto comodo.

Il manifest delle fonti registra ciò che è stato ammesso alla raccolta; non sostituisce questo gate. Una fonte adottata può essere citata male, mentre una fonte primaria può diventare obsoleta. Provenienza e qualità dell’argomentazione sono controlli complementari.

Decadimento dell’evidenza

Specifiche versionate e osservazioni locali invecchiano in modo diverso. La prima resta verificabile ma può non essere più corrente; la seconda descrive un ambiente preciso e non va universalizzata. Per questo data di revisione, versione e portata del test sono parte del contenuto, non metadati ornamentali. Correggere una conclusione quando cambia la prova rafforza la storia editoriale: non occorre nascondere che la decisione precedente aveva un altro perimetro.

Limiti

Queste regole non certificano sicurezza o completezza. Una fonte primaria può essere incompleta e due fonti ufficiali possono contraddirsi. In quel caso la wiki conserva la contraddizione, restringe il claim e indica quale controllo manca; non sceglie la versione più comoda.

Voci correlate

• Manifest unico delle fonti
• Verificare il canale eseguito
• Mirroring Tier A

Fonti

• NIST AI Risk Management Framework, riferimento primario volontario per il governo del rischio e dell’affidabilità; non definisce queste invarianti.
• W3C PROV-O, vocabolario primario per descrivere provenienza e responsabilità.
• MCP Architecture, specification 2026-07-28, esempio di fonte tecnica primaria fissata a una revisione datata.