Sintesi Tecnica: RAILS – Clearing Nativo per la Verifica nel Commercio Agente

1. Il Problema: Il Gap di Clearing Agente

Il documento identifica un vuoto strutturale critico nell'infrastruttura emergente del commercio tra agenti autonomi. Mentre i protocolli esistenti gestiscono efficacemente l'autorizzazione (concessione del permesso), l'esecuzione (chiamate a strumenti e comunicazione) e il pagamento (trasferimento di valore), nessuno fornisce un meccanismo neutrale per determinare l'adempimento delle prestazioni.

I sistemi attuali affrontano il "problema del clearing agente":

• Autorizzazione $\neq$ Clearing: Un agente può essere autorizzato ad agire ma può comunque eseguire l'azione errata (es. prenotare un volo per la settimana sbagliata).
• Pagamento $\neq$ Clearing: Un binario di pagamento può validare criptograficamente un trasferimento anche se il servizio è stato difettoso o non consegnato.
• LLM-as-Judge $\neq$ Clearing: Sebbene gli LLM possano valutare le prestazioni semantiche, soffrono di bias (di posizione, di verbosità, di auto-esaltazione) e mancano di una garanzia formale e falsificabile che i loro verdetti siano basati su prove ammissibili.
• Escrow $\neq$ Clearing: L'escrow e la sottoscrizione sono meccanismi di regolamento che consumano una determinazione; non producono la determinazione stessa.

Il problema centrale è che nessun livello esistente risponde alla domanda composta: Cosa è stato promesso, cosa è successo, quali prove sono ammissibili, chi è responsabile, quale perdita si è verificata e quale azione di regolamento è definitiva? Senza questo, i sistemi di regolamento ignorano il rischio o lo impongono alla parte sbagliata.

2. Metodologia: Il Protocollo RAILS

RAILS (Real-Time Agent Integrity & Ledger Settlement) è proposto come un protocollo di clearing nativo per la verifica. Si posiziona tra il livello di esecuzione (agenti, strumenti, MCP, A2A) e il livello di regolamento (binari di pagamento, escrow, standard di rischio).

2.1 I Sette Primitivi

Il protocollo è definito da sette strutture dati e funzioni che convertono l'intento firmato in una decisione regolabile:

1. Oggetto di Obbligazione ($O$): Un contratto firmato e chiaribile dalle macchine che compila l'intento in linguaggio naturale in una tupla strutturata contenente parti, dichiarazioni di compito, criteri di accettazione, requisiti di prova e un pavimento di ammissibilità ($\phi_O$).
2. Involucro di Prova ($E$): Un contenitore ancorato tramite hash di artefatti di esecuzione (git diff, log, ricevute, auto-report). Ogni elemento porta una catena di provenienza e una classe di ammissibilità.
3. Mesh di Verifica: Un set configurato di verificatori eterogenei (controllori di vincoli, verificatori di ricevute, giudici semantici, arbitri umani). Ognuno restituisce un verdetto, un livello di confidenza e una base di prova dichiarata ($B_i$).
4. Decisione di Clearing ($CD$): Il verdetto strutturato che aggrega gli output della mesh. Include lo stato di prestazione/policy, l'assegnazione delle colpe, le stime delle perdite e la base di prova aggregata.
5. Istruzione di Regolamento ($S$): Una lista di azioni strutturate (commissioni, capitale, collaterale, azioni di penalità) derivata dalla Decisione di Clearing, mirata a specifici binari di esecuzione.
6. Passaporto di Clearing: Un record di affidabilità cross-transazione per agenti, strumenti e verificatori, aggiornato dopo ogni evento di clearing per informare la futura pre-validazione e la selezione dei verificatori.
7. Regole di Finalità: Un predicato che determina quando un'Istruzione di Regolamento passa da PROVVISORIA a DEFINITIVA, basandosi sui pavimenti di ammissibilità, le soglie di confidenza, la risoluzione dei conflitti e le finestre di appello.

2.2 La Mesh di Verifica Graduata per Ammissibilità

L'innovazione principale è l'ordine parziale di ammissibilità ($\Lambda$). Le prove non sono classificate per un punteggio scalare, ma per un ordine parziale di sei classi:

• SELF: Auto-report non verificato.
• SIGN: Firma criptografica (non ripudiabilità, non verità).
• WIT: Firma di un testimone terzo.
• REC: Ricevuta esterna non interessata.
• ATT: Attestazione da un Ambiente di Esecuzione Fidato (TEE).
• PROOF: Prova criptografica di correttezza (es. zk-SNARK).

Fondamentalmente, WIT e REC sono incomparabili, riflettendo diverse assunzioni di fiducia. La classe di una base aggregata è il join dei suoi componenti, mentre la classe della base di un singolo verificatore è l'meet degli elementi su cui si è basato.

2.3 L'Aggregatore e la Soundness

L'Aggregatore della Mesh ($\Gamma$) combina gli output dei verificatori utilizzando una maggioranza ponderata per ammissibilità.

• Enforcement del Pavimento: I verificatori la cui base di prova dichiarata ($B_i$) scende al di sotto del pavimento di ammissibilità dell'obbligazione ($\phi_O$) vengono assegnati un peso pari a zero.
• Contratto della Base Dichiarata: I verificatori devono dichiarare onestamente quali elementi di prova hanno utilizzato. La misrappresentazione (lavaggio della base) è una classe avversaria.
• Proprietà di Soundness: Il protocollo impone una proprietà falsificabile: Nessuna Istruzione di Regolamento finanziariamente materiale viene emessa a meno che la classe della base di prova aggregata non raggiunga o superi il pavimento di ammissibilità dell'obbligazione.
  $$\text{Emit}(S) \implies \text{cls}(B) \succeq \phi_O$$

2.4 Intensità Guidata dall'Esposizione

Nella fase di Pre-Clearance, il protocollo calcola un Punteggio di Esposizione ($X$) basato sul rischio di autorità, valore a rischio, ambiguità dell'intento, irreversibilità, cronologia dell'agente e sensibilità del dominio. Questo punteggio mappa verso una policy a scatti ($K$) che determina:

1. Set di Verificatori: Da singoli verificatori deterministici (LOW) a mesh + arbitro umano (CRITICAL).
2. Tempistica di Regolamento: Da una finalità istantanea a una differita.
3. Requisito di Margine: Da nessuno a una collaterizzazione completa.

3. Contributi Chiave

1. Specificazione Formale del Clearing: Il documento definisce il clearing non come un punteggio o un passaggio booleano, ma come una determinazione graduata dall'ammissibilità delle sue prove.
2. Garanzia di Soundness: Introduce una proprietà di soundness falsificabile che assicura che nessun regolamento materiale poggi su prove inammissibili. Questo distingue RAILS dai sistemi "pass/fail", dai punteggi numerici o dagli equilibri di teoria dei giochi.
3. Ordine Parziale di Ammissibilità: Propone un modello non scalare e di ordine parziale per le prove che rispetta le differenze strutturali di fiducia (es. distinguere tra un testimone e una ricevuta).
4. Macchina a Stati del Ciclo di Vita: Specifica un ciclo di vita in dieci fasi (dalla Scoperta alla Finalità) con confini di reversibilità espliciti e percorsi di escalation (Arbitro Umano, Finestra di Appello).
5. Integrazione con lo Stack Esistente: RAILS è progettato per consumare input da protocolli esistenti (MCP, A2A, AP2, x402) e fornire output verso standard di rischio di regolamento, agendo come lo strato di clearing mancante nello stack degli agenti.

4. Risultati e Validazione

Il documento valida il protocollo attraverso uno scenario canonico di lavoro: un evento di clearing di consegna software in cui un agente di codifica autonomo corregge un bug ma viola una policy di dipendenza.

• Dinamica dello Scenario: L'agente aggiunge una dipendenza non autorizzata. Un giudice semantico LLM viene ingannato dall'auto-report dell'agente (una prova di classe SELF) e restituisce un PASS.
• Esecuzione del Protocollo: Poiché l'LLM-judge dichiara onestamente la sua base (il report SELF), il gate di enforcement del pavimento rileva che la base è al di sotto del pavimento richiesto di ATT (attestato da TEE).
• Esito: Il verdetto dell'LLM-judge viene assegnato un peso zero. L'aggregatore si affida ad altri verificatori (controllori di vincoli che utilizzano git diff di classe ATT) che identificano correttamente la violazione della policy. Il risultato è un verdetto di policy FAIL, che impedisce il rilascio dei fondi.
• Significato del Risultato: Questo dimostra che la soundness del protocollo regge anche quando un verificatore viene "ingannato", a condizione che il verificatore aderisca al contratto di dichiarare onestamente la propria base di prova. Il sistema non richiede che il verificatore sia onnisciente, solo onesto riguardo ai suoi input.

5. Significato e Rivendicazioni

Il documento sostiene che il commercio tra agenti autonomi non può scalare senza un meccanismo neutrale che converta le tracce di esecuzione in prove ammissibili ed emetta istruzioni di regolamento solide.

• Distinzione dal Lavoro Precedente: A differenza dei sistemi "verifica-e-paga" che emettono un passaggio booleano, o dei sistemi a "gioco di sfida" che si basano su equilibri razionali, RAILS emette una rivendicazione falsificabile sull'ammissibilità delle prove che supportano un regolamento.
• Ambito della Soundness: Il documento è modesto su ciò che la soundness fornisce. Garantisce che il protocollo non emetterà un regolamento basato su prove inammissibili. Non garantisce la verità del terreno, la correttezza del verificatore (calibrazione) o l'onestà dell'attester. Limita ciò che il protocollo può essere portato a emettere, non ciò che è vero nel mondo.
• Posizionamento: RAILS è presentato non come un sostituto dei protocolli esistenti (MCP, A2A, binari di pagamento), ma come lo strato di clearing necessario che li lega, convertendo "cosa è successo" in "cosa dovrebbe essere regolato".

Il documento conclude che, imponendo un pavimento di ammissibilità e richiedendo la dichiarazione onesta della base, RAILS fornisce l'integrità strutturale necessaria affinché il commercio degli agenti possa passare dai benchmark sperimentali agli obblighi finanziariamente materiali del mondo reale.