Il motore prova prima i piani riutilizzabili, poi costruisce un nuovo framework quando serve. La proposta del modello rimane probabilistica; firma della cache, validazione, guardie e semantica degli executor sono applicate dal codice. Non esiste quindi una promessa di «un'unica chiamata al modello» per ogni turno: il numero dipende dal percorso, dalla validazione e dall'eventuale recupero.
Il motore deve trasformare una richiesta naturale in una sequenza finita di capacità ammesse. Deve conciliare due esigenze:
Chiedi a Metnos con una richiesta come quella di questo esempio: «Trova i PDF modificati questa settimana in Progetti, calcola l'hash SHA-256 di ciascuno e crea un foglio con nome, data e hash.» La prima esecuzione può richiedere un nuovo framework; una richiesta ripetuta riusa il precedente solo se il piano resta cacheabile e le firme del mondo operativo coincidono.
L'ingresso contiene richiesta, intenti ordinati, catalogo visibile, lingua, utente, canale, destinazione e stato già prodotto dal turno. L'uscita contiene:
Il catalogo viene passato dal chiamante e costituisce il mondo dell'esecuzione. Un executor non presente o non ammesso non può essere reso disponibile dal testo del prompt.
| Livello | Stato | Responsabilità |
|---|---|---|
| L0 — fastpath | Persistente | Associa una query a un framework già riuscito ed efficace. |
| L1 — autopath | Persistente | Associa cluster semantici e intenti a un framework generalizzabile. |
| L2 — validatore | Per turno | Controlla nomi, schemi, campi obbligatori e riferimenti prima dell'esecuzione. |
| L3 — motore completo | Per turno | Propone, finalizza, esegue, classifica gli errori e conclude. |
L2 non viene interrogato come livello separato: interviene fra la nuova proposta e l'esecuzione. Piani L0 e L1 attraversano comunque la finalizzazione corrente, che applica guardie, ordine, regole di presentazione e richieste di consenso.
Il formato canonico è indipendente dal proponente:
{
"steps": [
{"tool": "find_files", "args": {"base_path": "Progetti", "pattern": "*.pdf"}},
{"tool": "compute_signatures", "args": {"from_step": 1}},
{"tool": "create_files_spreadsheet", "args": {"from_step": 2}},
{"tool": "final_answer", "args": {}}
],
"fillers": {},
"final_message": ""
}from_step e i placeholder ${stepN.field} collegano i
dati senza chiedere al modello di ricopiarli. Il runtime può inserire valori
interni con ${RUNTIME:key}. I campi di configurazione marcati
runtime_resolved, come account o client predefinito, non vengono
scelti dal proponente: li risolve il contesto dell'utente.
L0 nasce automaticamente dopo un turno riuscito, efficace e cacheabile. Non richiede un pulsante di approvazione. La ricerca ha due forme:
Sono esclusi i piani dipendenti dal contesto del turno, come dialoghi, consenso, annullamento e sessioni web autenticate. Sono esclusi anche valori temporali assoluti che diventerebbero obsoleti. Prima della riesecuzione, le firme degli executor e delle famiglie di candidati devono coincidere; per una mutazione, i valori discriminanti devono essere fondati nella richiesta corrente.
L1 conserva osservazioni di framework memorizzabili insieme a intenti, gruppi, tempi e riscontri. Un riscontro positivo può promuovere il framework a campione attivo. Per sequenze lunghe e ripetute il runtime può creare un campione shadow: viene servito con le stesse guardie, ma resta esplicitamente distinto da un piano confermato dall'utente.
La corrispondenza semantica rispetta il confine dell'oggetto canonico e una soglia di pertinenza. Anche L1 rifiuta framework legati a valori specifici della query e controlla le firme del catalogo al momento del riuso. Riscontri negativi ripetuti possono retrocedere il campione e creare un'anti-autopath temporanea; un riscontro positivo successivo può rimuovere l'esclusione corrispondente.
Il validatore è attivo per impostazione predefinita e non usa un modello. Controlla:
requires_one_of;from_step rivolti soltanto a passi precedenti;Se trova un errore, il proponente può essere invocato una volta con l'impronta del framework esclusa. Il nuovo candidato attraversa nuovamente le guardie deterministiche.
Il proponente è intercambiabile tramite configurazione. Le varianti supportate
condividono lo stesso contratto Proposer; possono generare un solo
candidato o più alternative e ordinarle. La grammatica, quando abilitata, limita la
forma dell'output, ma non rende deterministica la scelta semantica del modello.
L'esecutore risolve riferimenti, valori di riempimento e dati del runtime, controlla le condizioni di ogni passo e invoca la capacità. Passi indipendenti vengono eseguiti in parallelo soltanto quando il contratto e il controllo preliminare lo consentono. Gli effetti esterni restano variabili: rete, filesystem, fornitori e contenuti possono cambiare fra due esecuzioni.
Il recupero distingue errori strutturali da errori operativi. Può cambiare piano per strumento, argomenti o input mancanti; non finge di riparare una rete assente. Se un passo ha già prodotto una modifica, non ripete l'intera sequenza e restituisce un esito parziale dichiarato come tale.
Il riscontro valuta l'esito di un turno, non addestra direttamente il modello. L0 può eliminare la scorciatoia della query bocciata; L1 aggiorna osservazione, campione e anti-autopath. Le righe inutilizzate, retrocesse, scadute o riferite a executor non più presenti vengono eliminate dai processi di manutenzione.
Questa memoria conserva decisioni operative e osservazioni strutturate. Non è un profilo biografico dell'utente e non deve diventare una fonte di preferenze aperte inserite nel pianificatore.
Non occorre conoscere L0, L1 o i nomi degli executor. L'utente descrive il risultato desiderato in linguaggio naturale. Per esempio:
Chiedi a Metnos con una richiesta come quella di questo esempio: «Confronta i file delle cartelle Preventivi e Contratti e mostrami quelli che hanno lo stesso contenuto ma un nome diverso.»
Per ispezionare o svuotare le cache serve invece la chat web: apri Impostazioni e scegli Praxis. Se la domanda parte da Telegram, Metnos deve spiegare questo percorso e specificare che la console non si trova nel client Telegram.
La pagina /admin/praxis mostra gli strati persistenti: fastpath L0,
autopath L1 attive o retrocesse, osservazioni e anti-autopath. Consente di eliminare
una riga L0 o svuotare L0, L1 o entrambe. Lo svuotamento è amministrativo e non
annullabile: rimuove capitale operativo appreso e può rallentare le richieste finché
le cache non vengono ricostruite.
Le cache sono operative a livello dell'istanza e non contengono credenziali. Al riuso, account, lingua, consenso, destinazione e autorizzazioni vengono risolti di nuovo nel contesto dell'utente corrente.
Riferimenti nel codice:
runtime/engine/dispatch.py: cascata e sequenza comune di finalizzazione;runtime/engine/fastpath.py: L0;runtime/engine/autopath.py: L1, riscontri e anti-autopath;runtime/engine/validator.py: L2;runtime/engine/proposer*.py, executor.py, recovery*.py e terminator*.py: L3;runtime/engine/cache_validity.py: validità del mondo operativo;runtime/http_routes_admin.py e runtime/templates/praxis.html: console.