Design Principles & Boundaries
Scopo del documento è dichiarare i principi architetturali e i confini non negoziabili del protocollo, come invarianti infrastrutturali: proprietà che il sistema deve preservare attraverso ogni implementazione e ogni revisione futura.
§ 01 · Introduzione
I principi che seguono e i confini che li accompagnano costituiscono le invarianti del protocollo. Sono enunciati esplicitamente perché ogni implementazione e ogni revisione possa esservi confrontata.
Le invarianti non sono raccomandazioni: sono proprietà strutturali. Un'implementazione che le violi non realizza AIKNOCK, anche qualora ne adotti il nome o la terminologia.
§ 02 · Design Principles
I principi che seguono definiscono il comportamento tecnico del sistema durante l'esecuzione di operazioni di intelligenza artificiale. Gli otto principi definiscono le proprietà architetturali che il protocollo deve preservare. Sono numerati per riferimento e letti come un insieme: nessun principio è dispensabile senza modificare la natura del protocollo.
L'AI è trattata come una capability critica del sistema, non come una libreria o una funzionalità applicativa. Il suo uso è soggetto alle proprietà che il sistema riserva alle risorse critiche.
Ogni invocazione dell'AI attraversa il protocollo. L'interposizione non è opzionale e non dipende dalla cooperazione del codice chiamante.
La valutazione di contesto e intento è ex-ante: precede l'invocazione del modello. Non è un controllo successivo né una verifica a campione.
La decisione è applicata da un meccanismo tecnico al livello del sistema. Le dichiarazioni di intento e le regole organizzative non sostituiscono l'enforcement.
Le evidenze sono un effetto del funzionamento del protocollo, non una funzionalità aggiuntiva. La verificabilità delle decisioni è strutturale.
La presenza tecnica di un modello non implica l'autorizzazione al suo uso. I due piani — disponibilità e autorizzazione — restano distinti per costruzione.
Quando previsto, l'intervento umano non è una procedura operativa ma un requisito imposto dal sistema. Il protocollo non procede in sua assenza.
Il protocollo non dipende da un particolare modello, runtime o fornitore commerciale. Definisce un'interfaccia di controllo dell'esecuzione a cui ogni implementazione si conforma.
§ 03 · Boundaries
Ai principi corrispondono confini espliciti. Tali confini delimitano ciò che il protocollo, per costruzione, non occupa: sono altrettanto vincolanti dei principi e contribuiscono a definirne l'identità.
Il protocollo non ispeziona, non filtra e non valuta i contenuti scambiati con i modelli. Il suo dominio è il diritto di uso, non il merito del risultato.
Le obbligazioni giuridiche restano tali. AIKNOCK non interpreta norme, non garantisce conformità, non si sovrappone alla giurisdizione competente.
Il protocollo descrive proprietà tecniche del sistema. Non definisce processi di certificazione, non rilascia attestati, non sostituisce gli organismi preposti.
La costruzione, l'addestramento, la selezione e la valutazione dei modelli sono fuori ambito. Il protocollo agisce al momento dell'uso, non a monte.
AIKNOCK non comprende cruscotti, console o esperienze d'uso. È un piano infrastrutturale: le interfacce restano responsabilità delle implementazioni.
I confini sopra elencati non sono lacune del protocollo: sono scelte architetturali intenzionali. Restringere l'ambito è condizione necessaria perché ciò che il protocollo dichiara di fare possa essere garantito con precisione.
§ 04 · Sintesi
I principi definiscono ciò che il protocollo è. I confini definiscono ciò che il protocollo non è.
Insieme costituiscono le invarianti: la condizione perché AIKNOCK resti riconoscibile attraverso ogni implementazione, ogni revisione e ogni adozione.
Una specifica che cambia identità ad ogni revisione non è uno standard. Le invarianti sono il modo in cui un protocollo aperto si rende durabile.