GEODE
Autonomous Agent Harness
Dall’osservazione all’azione successiva.
Un harness locale per agenti autonomi a cui affidare ricerca, lavoro sui file e attività pianificate.
Dai rollout alle prove
Un tasso di successo da solo non spiega un’esecuzione. Conservo l’ordine degli eventi, le chiamate a strumenti e i loro risultati, la genealogia dei nuovi tentativi e le prove di verifica indipendente, poi collego le parti che si possono pubblicare. Questi esperimenti mostrano come si sono sviluppati i contratti di registrazione e di valutazione.
Per esperimento · in ordine di data
I sei esperimenti sono disposti in ordine di data; non sono un unico processo di ottimizzazione collegato. SIL non alimenta automaticamente Crucible o Jev, e non si afferma che il prodotto GEODE abbia continuato a migliorare. Le date sono quelle degli esperimenti e degli snapshot di pubblicazione, e le frecce si usano solo per le fasi all’interno di un esperimento.
June 3, 2026 to June 4, 2026SIL · ricerca di policy esterna
Un KEEP ottenuto da un solo audit è stato ricontrollato con misure ripetute
DomandaUna mutazione di policy ha migliorato il comportamento nell’uso degli strumenti oltre il rumore dell’audit?
Esperimento esterno · fuori dal runtime di GEODE
- Baseline · K=5
- Una mutazione di policy
- Audit Petri
- Misura ripetuta
- Mantenere
- Ripristinare
- Cosa è cambiato
- In questo esperimento, al singolo audit di una mutazione si è aggiunta una misura ripetuta prima di decidere se mantenere o ripristinare. Si sono aggiunti seed bilanciati per difficoltà e una baseline K=5, e i bracci never, random e gate separano le oscillazioni senza alcuna modifica dalle modifiche accettate.
- Cosa sostiene
- Rimisurato, il candidato mantenuto dopo un solo audit è risultato peggiore della baseline (più basso è meglio), quindi la sua adozione è stata annullata. L’esperimento si è concluso senza un miglioramento solido. È un audit comportamentale Petri broken_tool_use, non una ricompensa per il completamento del task.
July 11, 2026 to July 13, 2026Crucible · kernel sperimentale esterno
Restare nella ricerca e arrivare al prodotto sono verdetti separati
DomandaLe prove per mantenere un candidato nella ricerca sono le stesse che servono per promuoverlo e rilasciarlo nel prodotto?
Kernel Crucible esterno · checkout di misura separato
- Candidato · genealogia del genitore
- Controllo del contratto congelato
- Misura appaiata
- KEEPsolo verso un verdetto sealed separato
- REJECT
- INVALIDnull, non 0%
- Cosa è cambiato
- I candidati rifiutati e invalidi sono conservati con la genealogia del genitore, e selezione train, idoneità sealed e autorità di rilascio del prodotto sono registri separati.
- Cosa sostiene
- r14 è stato KEEP in train (sei unità di task, un tentativo ciascuna, nessuna autorità di promozione), ma il suo verdetto sealed separato è stato REJECT (nessuna autorità di promozione nel prodotto né di rilascio). r35 è INVALID per copertura incompleta e contaminazione dell’infrastruttura; senza righe appaiate la sua media resta null. Non si tratta né di automodifica del runtime né di una catena di deployment SIL → Crucible.
July 21, 2026 · July 31, 2026Raffinamento · pubblicazione
I registri rimasti sono stati classificati, e solo ciò che si può condividere è diventato una release immutabile
DomandaChe cosa si può davvero ricostruire, e che cosa si può condividere in sicurezza?
- Fonte privataRegistro di sessione · prove originalirisultato native · verifier incluso
- verso Eventi normalizzatipreservare ordine · identità
- Eventi normalizzatiidentità · ordine · coppie chiamata-risultato
- verso Candidato pubblicoallowlist · oscurare · digest
- Candidato pubblicoin revisione
- verso Controlli di integrità · privacycontrollare
- Controlli di integrità · privacyappaiamento · genealogia · ambito
- verso Release immutabilesolo byte revisionati
- Repository pubblicoRelease immutabilemanifest · risultati native referenziati per digest
- verso Rilettura remotaverificare l’hash
- Rilettura remotaSHA-256 fissato
Dall’esecuzione originale si costruiscono eventi che preservano ordine e identificatori, e i contenuti sensibili del candidato pubblico vengono rimossi o sostituiti da hash. Dopo il controllo delle coppie chiamata-risultato, dell’ambito e della genealogia, i file approvati e il manifest vengono pubblicati come release immutabile e gli hash remoti vengono controllati di nuovo. - Cosa è cambiato
- L’inventory del July 21, 2026 ha classificato per fonte i registri di dialogo, strumenti, ricerca e verdetti, e i duplicati della stessa fonte non sono stati contati come esempi indipendenti. Dal July 31, 2026, geode.trajectory@1 e geode.trajectory-release@1 rendono espliciti identità, ordine degli eventi, coppie chiamata-risultato, integrità di ambito e di replay, e manifest legati al contenuto. Le copie pubbliche trasformate e gli originali mantengono digest separati.
- Cosa sostiene
- Raffinamento qui significa normalizzazione, correlazione, oscuramento esplicito, genealogia e ammissione alla pubblicazione. Non ricostruisce ragionamenti nascosti né dichiara un dataset pronto per l’addestramento. Un ambito completo non è un replay completo dei byte quando i contenuti privati sono sostituiti da digest.
- Fonte privataRegistro di sessione · prove originalirisultato native · verifier incluso
August 25, 2026Learning view
Un rollout e le sue prove sono stati legati tramite identificatori
DomandaQuale input, quale tentativo, quale sequenza di eventi e quale ricompensa vanno insieme?
geode.eval-learning-view@2 · uniti tramite ID e digest verificati, non un ordine causale
- example
- rollout
- trajectory
- reward
La ricompensa appartiene alle receipt del verifier native. Le ripetizioni per l’infrastruttura sono tentativi all’interno di un solo rollout.
- Cosa è cambiato
- Le traiettorie immutabili vengono riusate tramite join con ambito definito, e le ricompense restano etichette derivate di proprietà del valutatore. Le ripetizioni per l’infrastruttura non aggiungono rollout. Uno 0 osservato viene conservato e una ricompensa mancante è null; i tentativi invalidi o interrotti sono esclusi dalla selezione della ricompensa. La validità è una proprietà del rollout e non implica automaticamente una ricompensa null.
- Cosa sostiene
- Un’esecuzione Terminal-Bench fast-3 con Harbor 0.8.0 (tre task, 3/3) e una diagnostica Tau2 su tre domini (1/3, due zeri validi) sono legate nella stessa struttura. Sono candidati per il post-training, non dataset usati per l’addestramento né prove di pesi migliorati, e un risultato su tre task non è l’accuratezza della suite.
August 27, 2026 to September 5, 2026Harbor · Terminal-Bench 2.1
Un trial ha prodotto separatamente il risultato e il registro di replay
DomandaCome si passa dall’esecuzione reale di un task a un risultato e a un replay ispezionabile?
- Task congelato · specfissato in anticipo · cinque ripetizioni
- verso Trial isolatoistruzioni · ambiente · limiti
- Trial Harbor 0.22.0 · esecuzione realeTrial isolatoGEODE come actor
- verso Azioni e stato finaleeseguire
- Azioni e stato finalecomportamento osservato
- verso Verifier del taskcontrollare lo stato del task
- verso ATIF · proiezione in eventi pubbliciproiettare gli eventi registrati
- Verifier del task
- verso Ricompensa native · receiptricompensa
- Ricompensa native · receipt
- verso Analisi del tentativo selezionatoselezione congelata
- ATIF · proiezione in eventi pubblicipost-elaborazione · non una nuova esecuzione
- Analisi del tentativo selezionatoregola di selezione congelata
Un task e una spec congelati danno a un trial isolato istruzioni, ambiente e limiti; il verifier del task controlla lo stato lasciato da GEODE e produce la ricompensa. L’analisi usa solo il tentativo scelto da una regola congelata. Gli eventi registrati nella stessa esecuzione sono proiettati separatamente in ATIF e in eventi pubblici: è post-elaborazione, non una nuova esecuzione. - Cosa è cambiato
- La spec congelata, ogni tentativo, il risultato selezionato, il verifier del task e un replay fedele ma di portata limitata sono conservati come registri separati e collegati. Harbor 0.22.0 ha eseguito cinque ripetizioni con GPT-5.6 Sol/max, confrontando GEODE (allora un adattatore con un solo strumento terminale) con Codex.
- Cosa sostiene
- Un task comprende istruzioni, ambiente e test; un trial è un tentativo; un job raggruppa i trial. Il verifier del task decide la ricompensa, e il giudizio interno di completamento di GEODE è un feedback del runtime. Il replay pubblico è una proiezione post hoc degli eventi degli strumenti registrati, non un PTY grezzo né una nuova esecuzione, e per le celle mancanti non sono stati inventati comandi. Il confronto primario preregistrato non è stato misurabile.
- Task congelato · specfissato in anticipo · cinque ripetizioni
September 24, 2026 to September 28, 2026Jev · delega delle decisioni
Anche un candidato corretto richiede la verifica della consegna
DomandaUn giudizio delegato preserva davvero la qualità del task e la consegna finale?
- U8n · esecuzione Noul · Harbor 0.22 · Astra esegue e ripara, cambia solo il percorso di giudizioStato di decisionecontratto del task · candidato · osservazioni degli strumenti
- verso Giudizio · Noulinput del giudizio
- Giudizio · NoulAstra o Jev
- verso GEODE usa il giudizioprobabilità per condizione
- GEODE usa il giudiziosoddisfatto: consegnare; prove mancanti: trattenere
- verso Consegna finalesoddisfatto
- verso Riparazione di Astraprove mancanti · trattenere
- Consegna finale
- verso Controllo indipendente dell’esitorisultato consegnato
- Riparazione di Astracandidato successivo dopo il feedback
- verso Giudizio · Noulgiudicare di nuovo
- verso Ultimo candidato · conservatoultimo candidato conservato
- Controllo indipendente dell’esitooracle a regole · risultato consegnato
- Pannelli fissi U3solo giudizi · niente actor, strumenti né Harbor
- Diagnosi post hoc · dopo l’esecuzioneUltimo candidato · conservato
- verso Diagnosi post hoc con oraclecontrollo post hoc
- Diagnosi post hoc con oraclecorrettezza del candidato · nessun effetto sulla consegna
Nell’esecuzione reale lo stato di decisione va a un giudizio; GEODE lo usa e consegna quando le condizioni sono soddisfatte; con prove mancanti trattiene il risultato mentre Astra ripara e il giudizio viene ripetuto. Un oracle a regole indipendente verifica il risultato consegnato. A parte, dopo l’esecuzione, l’ultimo candidato conservato è stato diagnosticato con un oracle post hoc; quella diagnosi non ha alcun effetto sulla consegna. I pannelli fissi U3 sono un esperimento separato che confronta solo i giudizi, senza actor, strumenti né Harbor. - Cosa è cambiato
- Accettazione del giudizio, correttezza del candidato e consegna finale sono registrate come esiti separati, e le genealogie di preparazione, fallimento e riparazione sono conservate nella copia pubblica. Gli hash originali e quelli pubblici trasformati restano separati.
- Cosa sostiene
- Nelle 11 coppie post hoc dello studio U8n interrotto, l’ultimo candidato era corretto in entrambi i bracci, eppure la consegna è stata Astra 11/11 e Jev Noul 0/11: il giudizio di Jev Noul per mancanza di prove ha trattenuto la consegna. È un’analisi post hoc e non viene generalizzata. Ricalcolo pubblico dei valori, ispezione del replay e nuova esecuzione dal vivo sono tre operazioni diverse.
- U8n · esecuzione Noul · Harbor 0.22 · Astra esegue e ripara, cambia solo il percorso di giudizioStato di decisionecontratto del task · candidato · osservazioni degli strumenti