1. Cos'è Metnos

Metnos è un'architettura ospitata in proprio per un agente governato. Il nucleo non definisce un dominio applicativo: pianifica, applica regole, ricorda, sintetizza, isola e registra. È l'insieme degli executor ammessi a definire cosa può fare davvero una specifica istanza. Gli executor sono piccoli programmi firmati, generati o importati soltanto dentro un vocabolario chiuso e orchestrati da un pianificatore LLM che privilegia i modelli locali. I modelli del livello frontier offrono consulti opzionali, non la sede del sistema.

Il nome viene da mētis (l'intelligenza astuta) + noûs (la mente). Vive su una macchina sotto il tuo controllo fisico e legale. L'istanza di riferimento si usa da Telegram e dal browser (porta 8770), e il suo catalogo corrente copre file, posta, foto, calendari, web, GitHub e operazioni sul server. Sono usi di quel catalogo, non limiti di Metnos. Cambiando gli executor ammessi, le skill e i servizi collegati cambia il dominio operativo, senza cambiare l'architettura che lo governa.

La carta d'identità

2. Le tre scommesse

Tutto il progetto sta in tre scommesse architetturali. Sono scelte di campo, non ottimizzazioni: ciascuna rovescia un'abitudine diffusa delle piattaforme agentiche.

Il confronto, senza sconti

Dove si trova il determinismo

Metnos non presenta la prosa del modello come prova. Prefiltro, grammatica, validatore, filtro di ammissione, esecuzione e verifica delle cache sono componenti controllabili e coperti da prove. Quando una richiesta ha un piano memorizzato ancora valido, il percorso veloce lo riusa senza una nuova chiamata al modello; quando il piano deve essere generato, la proposta resta probabilistica ma confinata e osservabile (cap. 9).

3. I concetti chiave, in sette carte

Sette parole reggono tutto il documento. Definirle adesso vi risparmia mezz'ora di confusione fra trenta righe; ognuna ha il suo contratto implementativo nell'atlante dei componenti.

L'anatomia di un nome

Il vocabolario chiuso è l'idea più fertile del progetto: rende i nomi componibili (il pianificatore può prevedere come si chiama una capacità che non ha mai visto), filtrabili (il filtro preliminare ragiona su verbo e oggetto) e sintetizzabili (synt non può nominare nulla fuori dalla grammatica).

4. L'architettura a strati

Metnos è una cipolla: l'esterno parla col mondo, l'interno esegue. Ogni strato si fida solo di quello più interno e i privilegi calano scendendo verso il centro. Una richiesta — venga da un utente o da un'attività programmata — li attraversa tutti, nell'ordine.

• Canali — un canale è un adattatore: converte un'interfaccia esterna (Telegram, browser) in messaggi e risposte. Aggiungerne uno non tocca il nucleo (cap. 11).
• Motore del turno — il guscio che misura e orchestra: tempi di ogni sottofase (intent_ms, prefilter_ms, vaglio_ms, exec_ms), limiti di sicurezza e registro.
• Motore Mētis — pianifica una volta, esegue in modo deterministico, recupera con criterio e, quando non c'è via d'uscita, lo dichiara (cap. 5).
• Guardie — nessun subprocess a mano libera, mai: ogni effetto passa da regole, Vaglio e isolamento (cap. 12).
• Executor e servizi — chi agisce e contro cosa: la separazione fra skill e servizio tiene il fornitore fuori dalla testa del pianificatore; la collocazione decide poi se l'executor resta sul server o va a un dispositivo registrato (cap. 3 e 6).
• Tessuti — ciò che resta fra un turno e l'altro: memoria associativa, scorciatoie apprese, cronologia degli annullamenti e registro.

5. Anatomia di un turno con più strumenti

Questo è il capitolo da leggere se ne leggete uno solo. Seguiamo una richiesta esemplificativa — «cerca le mail spam e mettile nel cestino» — dall'ingresso alla risposta: quattro strumenti concatenati, una proposta strutturata e ogni passaggio misurato e annotato.

5.1 La cascata, passo per passo

La regola di fondo: il modello è l'ultima risorsa, non la prima. Prima si tenta la memoria senza LLM; se la richiesta è nuova, il proposer chiede al modello l'intero piano strutturato. Il numero di chiamate dipende dalla configurazione dei candidati e della grammatica; l'esecuzione del piano validato segue regole deterministiche.

1. Scorciatoie letterali. Una tabella chiusa riconosce le frasi notissime («che ora è») in microsecondi. Qui non trova corrispondenze.
2. Intento. Una chiamata al livello fast (ragionamento spento, ~0,4 s) estrae verbo canonico, oggetto e parole chiave. Le richieste composte diventano una lista ordinata di clausole, ognuna col proprio insieme ammesso.
3. Memoria dei piani. Fastpath L0 riusa un successo registrato automaticamente; Autopath L1 riusa uno scheletro generalizzato confermato da un riscontro positivo. Entrambi controllano le firme del catalogo e dell'insieme prima di usare la cache. Qui non trovano nulla: è la prima volta.
4. Prefiltro. Il catalogo si riduce all'insieme pertinente per la clausola: corrispondenza su verbo e oggetto, peso del qualificatore e, per rompere i pareggi fra executor affini, peso dell'affinità curata. Tutto è deterministico: stessa richiesta, stesso insieme, stesso ordine.
5. Proponente Mētis. Il livello wise produce l'intero piano strutturato: passi, collegamenti e messaggio finale. In base alla configurazione può generare uno o più candidati; la grammatica GBNF limita i nomi disponibili e un ordinamento deterministico sceglie il candidato da convalidare.
6. Validatore. Controlla il tipo del piano prima di eseguirlo: strumenti esistenti, argomenti ben formati e riferimenti reali. Un errore banale costa una nuova proposta, non un'esecuzione sbagliata.
7. Esecuzione. Meccanica pura: per ogni passo il motore risolve i segnaposti, passa dal Vaglio, invoca l'executor nell'ambiente isolato e accumula l'osservazione. Limiti: 12 passi per turno e lo stesso executor al massimo tre volte di seguito.
8. Chiusura. Il messaggio finale viene composto dai risultati effettivi. Se il turno è memorizzabile e riesce, L0 registra il piano; L1 conserva un'osservazione e richiede un riscontro positivo prima di promuovere lo scheletro generalizzato.

5.2 Il piano: cosa propone davvero il modello

Il Proponente non produce prosa: produce un oggetto strutturato — passi, valori da completare e messaggio finale. Questo è il piano reale della nostra richiesta:

{
  "steps": [
    {"tool": "find_messages",
     "args": {"folder": "INBOX", "query": "is:unread"}},
    {"tool": "classify_entries",
     "args": {"from_step": 1, "dimension": "spam"}},
    {"tool": "filter_entries",
     "args": {"from_step": 2, "where_field": "spam", "where_value": "spam"}},
    {"tool": "move_messages",
     "args": {"from_step": 3, "dst_folder": "${FILLER:cestino_folder}"}}
  ],
  "fillers": {
    "cestino_folder": {
      "prompt": "Come si chiama la cartella cestino per questo account?",
      "default": "Trash",
      "tier": "fast"
    }
  },
  "final_message": "Spostate ${step4.ok_count} mail nel cestino."
}

Da notare: il modello non conosce il nome della cartella cestino dell'account — e non lo inventa. Dichiara un valore da completare (${FILLER:cestino_folder}) che il motore riempirà al momento giusto con una breve chiamata economica, conservata in cache, oppure con il valore predefinito.

5.3 Il passaggio dei dati: come comunicano i passi

Risultati parziali e limiti

Se un limite tronca un risultato, per numero di elementi, byte o passi, l'executor lo dichiara nei campi truncated, used e available_total, quando il contratto li prevede, e il motore lo rende visibile nella risposta. Può proporre di ampliare il limite soltanto quando è tecnicamente possibile e non lo amplia da solo. Un risultato parziale presentato come completo è un errore.

6. Executor: vettoriali per costruzione

Ogni executor accetta una lista e ritorna una lista — anche quando la lista ha zero o un elemento. Non esiste nessun *_batch: l'executor gestisce già le operazioni per lotti. È la decisione che rende i piani corti e i risultati componibili.

Dal contratto discendono tre convenzioni che vedrete ovunque:

• entries e results — chi arricchisce o legge una lista restituisce entries (lo schema dei record si conserva e il flusso può continuare); chi trasforma restituisce results (lo schema cambia: esiti, non record).
• Robustezza al confine col linguaggio naturale — 0 come segnaposto vale «nessun limite»; per impostazione predefinita i confronti non distinguono maiuscole e minuscole; nei domini testuali aperti * e ? indicano un modello di ricerca, mentre nei domini chiusi (identificativi e ambiti) la corrispondenza è esatta. Così le inclinazioni dell'LLM non diventano fallimenti silenziosi.
• Fedeltà dei conteggi — ok_count conta gli elementi realmente processati. Mai dichiarare un esito che non corrisponde alla realtà.

Il manifest: il prompt dello strumento

Ogni executor porta con sé un manifest TOML. Non è documentazione di cortesia: è ciò che il pianificatore legge quando decide se e come usare lo strumento — scritto su misura per un LLM medio locale, non per un modello frontier. Frasi corte, esempi letterali, valori predefiniti in chiaro; la descrizione segue quattro capitoli prescrittivi:

Lo stesso manifest dichiara anche dove l'executor può girare. I campi platforms e [placement] impediscono di mandare a Windows uno strumento scritto solo per Linux, o di eseguire su un PC un executor non verificato per quel dispositivo. Quando la chat nomina un PC appaiato, il motore usa queste dichiarazioni per decidere se eseguire sul server o sul dispositivo; se il bersaglio non è raggiungibile, l'esito è esplicito e non viene scelto un ripiego silenzioso.

[description]
it = "SCOPO: cerca file per pattern in directory.
      PATTERN: find_files(base_path=\"/\", patterns=[\"*.jpg\"]).
      NON: list_dirs+filter_entries; get_files (lookup ID).
      OUT: entries=[{path,name,type,mime,kind,size,mtime}]."

Una sola politica di esecuzione

Ogni chiamata a un executor, locale o remota, attraversa lo stesso motore di esecuzione. In un punto solo il motore applica metriche, retropressione, limiti per risorsa e un tetto derivato dall'hardware. Il comportamento predefinito resta intenzionalmente seriale e il raggruppamento trasversale è spento: adottare l'infrastruttura non cambia l'ordine, gli ingressi, i risultati o le capacità degli executor esistenti.

[execution]
effect = "unknown"
parallelism_class = 0
resource_class = "default"
concurrency_key = "none"
equivalence_gate = "unverified"

La classe misura soltanto un budget: non concede autorità e non significa sola lettura. Un futuro executor che crea o modifica oggetti può essere concorrente, ma deve dichiarare una chiave d'isolamento, fornire l'identità della risorsa e superare prove di equivalenza, collisione, idempotenza e postcondizione. Se manca uno di questi riscontri, il caricatore lo riporta alla classe 0.

Anche i tre percorsi che generano executor — proposta Synt, sintesi reattiva e generazione da skill — consumano un unico contratto centrale. Il modello locale può progettare un'implementazione ricca, ma non può riscrivere identità, ciclo di vita, I/O o politica iniziale. Se parallelizza elementi indipendenti, il numero di processi di lavoro arriva dal motore e i risultati devono tornare nell'ordine di ingresso.

Autorità remota: dichiarata una volta, consumata tre volte

Il nome di un fornitore dentro un argomento è un dato, non un permesso. Per un executor conforme, l'accesso remoto esiste solo quando il manifest dichiara una capacità provider:access effettiva. Una condizione when chiusa può attivarla soltanto per il servizio selezionato. Condizioni invalide o non corrispondenti non concedono nulla.

Esecuzione sul server o su un PC registrato

La forma normale resta semplice: il piano sceglie un executor, il motore lo passa attraverso regole e Vaglio, poi lo invoca nell'ambiente isolato del server. Gli executor remoti aggiungono una sola deviazione controllata: per alcuni executor dichiarati portabili, il punto di esecuzione può essere un PC registrato nella stessa rete o in una rete privata sovrapposta.

Non è un nuovo canale e non è un servizio qualunque. Il canale resta Telegram o web; il servizio resta file, posta, calendario o altro. L'executor remoto indica il luogo in cui gira il piccolo programma firmato. Metnos mantiene sul server la scelta dell'executor, il controllo delle regole, il registro dei dispositivi, la firma del contenuto, la scadenza e il tracciamento.

La scelta non dipende dall'indirizzo IP del browser. In una UI web la macchina che apre la pagina può coincidere col server, con un altro PC della rete, o essere dietro un proxy; da Telegram non c'è proprio un browser locale. Per questo Metnos usa il nome del dispositivo appaiato e lo collega al linguaggio della richiesta: «sul portatile» indica una destinazione, «il portatile» da solo non lo è.

Il client remoto non riceve libertà generale. Interroga periodicamente il server, non espone porte; verifica la firma del server prima di eseguire; scarica solo executor firmati e compatibili; scrive il risultato nella coda locale prima di consegnarlo. Se il server non risponde, ritenta la consegna senza rieseguire il lavoro già fatto.

Il client remoto è contenuto per costruzione: su Windows il Job Object limita durata, memoria e albero dei processi; su Linux l'ambiente isolato usa bwrap quando presente. Gli executor remoti possono eseguire sul dispositivo anche operazioni che modificano i file — scrittura, spostamento e cancellazione — applicando le regole richieste: idempotenza, tracciamento e reversibilità legata al dispositivo (operazioni inverse deterministiche e copie accodate allo stesso dispositivo per l'annullamento; resta il limite noto che il ripristino da una copia binaria non è eseguibile da remoto). Gli executor le cui dipendenze non sono risolvibili sul dispositivo restano vincolati al server.

Il dettaglio operativo — appaiamento del PC, installazione dall'interfaccia, segnale periodico di presenza, coda firmata, isolamento per sistema operativo e limiti attuali — sta nel contratto executor remoti.

7. Synt: la fabbrica degli strumenti

Quando l'insieme disponibile non sa fare una cosa, il pianificatore non improvvisa codice nel mezzo del turno: passa la mano a synt, il processo che fa esistere ciò che manca. Prima prova a comporre executor esistenti; solo come eccezione documentata genera un executor nuovo — in cinque stadi, ognuno col suo contratto.

Due inneschi, una cascata

In entrambi i casi vale la stessa regola: synt propone, l'umano approva. Nessuna auto-modifica senza filtro; ogni proposta arriva con motivazione, ed è reversibile.

Il filtro di ammissione a sette livelli

Lo stesso imbuto vale per il codice sintetizzato e per le skill importate da fuori: nessun pacchetto si esegue sulla fiducia.

8. Cinque livelli, un instradamento governato

I livelli sono ruoli astratti, non modelli inchiodati: fast / middle / wise / creative sono incarichi che leghi a qualunque endpoint tu abbia, frontier è il cloud facoltativo. Più livelli possono condividere un endpoint oppure essere separati: il pianificatore vede sempre il ruolo.

Un livello non è un modello

I livelli descrivono ruoli e requisiti, non un modello specifico. Una GPU o una NPU non è obbligatoria: l'amministratore può associare un livello a un endpoint su CPU, a un modello locale già disponibile o, dove previsto, a un servizio esterno. La qualità del modello scelto incide sulla qualità della pianificazione, non sulla validità dell'installazione.

Tre controlli sulla variabilità

Un LLM a temperatura zero non rende automaticamente riproducibile una nuova pianificazione. Metnos riduce la variabilità e, soprattutto, separa la proposta probabilistica dai controlli deterministici che la precedono e la seguono:

Struttura controllata

Il Proponente richiede un oggetto strutturato, usa la grammatica quando è configurata e applica comunque un'analisi sintattica bilanciata seguita dalla validazione. Un risultato illeggibile o non conforme non viene eseguito.

9. La memoria che accelera

Metnos non addestra modelli: niente riaddestramento, niente RLHF. Tutto ciò che impara è dato ispezionabile — piani, tracce, scorciatoie — e ogni cosa imparata si può leggere, correggere, cancellare. L'effetto pratico: più lo usi, meno chiama il modello.

10. I sensi: la pipeline immagini

Per cercare nelle foto, Metnos non spedisce nulla a nessuno: tre estrattori nel processo trasformano ogni immagine in tre segnali — cosa si vede, chi c'è, dove e quando — fusi in un indice unificato interrogabile dal vocabolario normale.

La ricerca arriva dal canale come qualunque altra richiesta: il pianificatore compone find_images_indices con i criteri estratti dalla frase, e il canale mostra le anteprime inline. La costruzione dell'indice è un lavoro di fondo, incrementale e riavviabile, che si lancia con una frase («indicizza le foto in…»).

11. I canali: Telegram e web

Un canale è un adattatore: converte un'interfaccia esterna in messaggi e risposte, più una capacità opzionale — rendere bottoni per conferme e scelte. Due canali nascono con l'installazione; aggiungerne altri non tocca il nucleo.

Il Tutor: spiegare senza eseguire

Le domande esplicite su come usare Metnos vengono intercettate allo stesso confine HTTP/Telegram, prima del pianificatore e senza consumare un dialogo pendente. Il primo passaggio distingue spiegazioni, azioni, richieste miste e intenzioni ancora incerte. Un nome di pagina, un percorso relativo o un URL canonico può identificare direttamente una fonte pubblicata; negli altri casi il modello di rappresentazione configurato confronta la domanda con le unità del catalogo SQLite firmato.

Dopo il recupero, l'identità autenticata filtra le fonti. Una fonte firmata può richiamare soltanto osservazioni di sola lettura registrate e limitate: executor ammessi, servizi, dispositivi posseduti e attività programmate dell'utente. Il modello locale formula la risposta esclusivamente da queste evidenze; non riceve strumenti e usa la risorsa centrale llm in classe seriale.

Se una richiesta contiene anche un'azione separabile, il Tutor risponde alla parte informativa, conserva alla lettera la clausola operativa e chiede se consegnarla al normale motore di Metnos. La consegna è monouso, legata all'utente e alla conversazione e avviene soltanto dopo conferma. Il Tutor non esegue l'azione. I riscontri possono migliorare il recupero per quella sola persona, senza modificare il pianificatore o le cache dei piani.

Il confine del Tutor

Il runtime governa identità, livello di accesso, integrità delle fonti, registro delle osservazioni e consegna delle azioni. Classificazione semantica, recupero e composizione intervengono dove la varietà del linguaggio renderebbe fragile una tabella di frasi. Catalogo non valido, pertinenza debole o contesto insufficiente producono un esito dichiarato, mai una capacità inventata.

12. Sicurezza e reversibilità

La sicurezza non è un modulo: è una catena di guardie indipendenti, e un'azione deve passarle tutte. E siccome anche la guardia migliore sbaglia, l'ultima difesa è poter tornare indietro: annullamento verificabile, per costruzione.

Capacità amministrative e loro confine

Con il relativo insieme di executor, un'istanza Metnos può amministrare una macchina mediante interprete dei comandi, sudo, pacchetti e montaggi. Ogni azione privilegiata passa dal Vaglio e dalle autorizzazioni previste, usa i livelli di contenimento applicabili e viene registrata. La skill di sistema può essere disattivata, impedendo a Metnos di usare queste capacità sul sistema operativo.

13. Atlante dei componenti

L'architettura vista fin qui dice cosa promette il sistema. Questo atlante mostra quale componente possiede ogni promessa e dove vive il suo contratto esatto.

13.1 Dalla visione ai contratti dei componenti

L’architettura di Metnos ha due livelli di ingrandimento. Il livello alto descrive il sistema nel suo insieme: strati, organi, leggi e fini. È il percorso che avete appena seguito dal capitolo 1.

Il livello basso è l'insieme degli approfondimenti collegati qui sotto: un documento HTML per ogni componente, con schemi dei dati, firme delle funzioni, regole d'isolamento e condizioni di errore. Queste pagine spiegano l'implementazione corrente; codice, manifesti caricati e prove ne attestano il comportamento. Se una pagina diverge da quelle fonti, va corretta nello stesso intervento. Una specifica futura resta invece tale finché il codice e le prove non ne dimostrano l'attuazione.

13.2 Quattro nomi, ora come contratti implementativi

Tutto Metnos gira intorno a quattro nomi. Definirli adesso vi risparmia mezz’ora di confusione fra trenta righe.

executor

Una capacità eseguibile: un piccolo programma che fa una cosa sola e bene (leggere file, mandare una mail, calcolare un'impronta, ricavare testo da una scansione, scoprire nuovi indirizzi in un sito). Ogni executor accetta liste in ingresso e produce liste in uscita; ha un manifest che lo descrive, una firma Ed25519 che lo autentica e un profilo d'isolamento che lo confina. L'appartenenza al prodotto, l'origine e il trasporto restano assi distinti. Gli executor GitHub mantenuti da Metnos sono funzioni integrate realizzate a mano, non importati; il catalogo generato è la fonte unica per la suddivisione del codice sorgente.

mnest

Il filo che collega due executor quando sono stati attivati insieme dal pianificatore. Non è un puntatore di codice, è una traccia: nasce dal contesto, si rinforza con la ripetizione, decade se non viene riusato.

mnestoma

Il grafo emergente di tutti i mnest. È la memoria associativa del sistema: vive su SQLite, viene curata da un processo notturno (ager) e fornisce al pianificatore l’intuizione di «quale executor di solito segue quale». La controparte inglese del termine è mnestome.

motore del turno (agent_runtime)

Il componente che orchestra il turno: riceve la richiesta, estrae l'intento, tenta le memorie L0/L1 e, quando serve, chiede al motore Mētis un piano strutturato. Dopo la validazione esegue gli executor in sequenza, raccoglie le osservazioni e applica Vaglio, regole e isolamento a ogni passo.

13.3 La mappa dei componenti

I componenti documentati sono organizzati per ruolo. Lo schema sotto raggruppa i nodi principali per ruolo: il bordo nero spesso è il motore centrale, le forme verdi i «servizi» che il motore consulta, le forme azzurre i «tessuti» che memorizzano lo stato, le forme color bronzo gli organi periferici verso l’utente e verso l’ambiente. Le frecce indicano chi chiama chi.

Tre osservazioni utili per leggere lo schema.

1. Il telos è un segnale morbido: orienta i componenti in cui è collegato, senza sostituire richiesta, regole o capacità. Il file del workspace dichiara fini e pesi; non concede autorità.
2. Il vaglio è sempre prima dell’esecuzione, mai dopo. Una volta che un executor è partito non si torna indietro in modo gratuito: l’annullamento esiste, ma richiede una cronologia e copie di sicurezza.
3. L'insieme degli executor è estendibile ma governato: Synt prima tenta di comporre capacità esistenti e, quando serve davvero, può generare un nuovo executor. Nome, manifest, prove, firma e ciclo di ammissione restano obbligatori.

13.4 Una seconda richiesta guidata

Per fissare la mappa, seguiamo una richiesta semplice dall’ingresso fino alla risposta: «sposta in ~/Archivio/2026 i PDF di fatture arrivati questa settimana».

1. Canale. Telegram riceve il messaggio dell’utente. Il servizio controlla che il mittente sia stato appaiato con un livello d’autorizzazione sufficiente; in caso contrario il messaggio viene scartato senza eco. L'appaiamento significa «canale + identificativo del mittente riconosciuto»: si ottiene rispondendo a un codice Ed25519 firmato con scadenza.
2. Motore del turno — pianificazione. Il motore estrae l’intento (verbo canonico: move; oggetto: files; criterio: PDF allegati a fatture in finestra «ultima settimana»), interroga il prefilter per ridurre il catalogo agli executor pertinenti, chiede al Proponente un piano strutturato e lo valida prima di eseguire il primo passo.
3. Vaglio — guardia + giudice. Prima di lanciare l’executor il Vaglio controlla due cose: che il percorso non sia vietato, che il comando shell non sia irrecuperabile (rm -rf e simili). Per le operazioni che cadono in zona grigia, regole e giudice determinano se occorre una decisione umana. In quel caso il canale mostra una proposta localizzata che rende riconoscibili azione, obiettivo e conseguenze rilevanti.
4. Isolamento ed executor. Il motore invoca read_messages dentro bwrap con i parametri derivati dal manifest. Il risultato è una lista di entries; ogni elemento contiene il percorso del PDF e i metadati.
5. Passaggio dei dati. Il passo successivo è move_files; riceve la lista del passo precedente con from_step: N. La verità sui dati vive nello scratchpad: il pianificatore non vede l’intera lista, ne vede una vista sintetica che gli basta per decidere.
6. Mnest + mnestoma. La coppia read_messages → move_files rinforza una traccia esistente nel grafo. Se non esiste, viene creata. L’ager notturno farà manutenzione: decadimento, deduplicazioni e scarti.
7. Risposta. Il motore restituisce all’utente, via Telegram, il numero di file spostati e il primo motivo di scarto se qualcosa è stato escluso. La final_answer include il segnale di troncamento se la lista di partenza era stata limitata.

13.5 Gli approfondimenti canonici

Sotto, i documenti sono raggruppati per ruolo. Tutti hanno la controparte inglese in /en/architecture/.

13.6 Vocabolario e primitive

Il vocabolario chiuso conta 26 azioni (read, write, move, delete, create, find, list, filter, sort, group, classify, get, set, send, describe, render, extract, compress, compute, compare, change, order, share, open, login, act) e 27 oggetti (files, dirs, packages, messages, events, contacts, places, processes, urls, numbers, images, signatures, texts, proposals, persons, tasks, inputs, approval, credentials, issues, pulls, calendars, entries, lists, skills, sites, preferences). I qualifier sono divisi in quattro famiglie: formato (codifica del dato), modalità (come agisce l’executor), criterio di sicurezza e fornitore (per indicare un servizio diverso da quello predefinito, ad esempio _google_workspace). Tutto centralizzato in runtime/vocab.py.

Le liste di elementi prodotte passo per passo durante un turno si manipolano con nove funzioni disponibili al pianificatore. I cinque operatori strutturali o numerici sono filter_entries, filter_lists, sort_entries, group_entries e compute_entries. I quattro operatori semantici eseguiti nello stesso processo sono classify_entries, compare_entries, extract_entries e describe_entries. Il primo gruppo filtra una lista, combina due liste, ordina, unisce/deduplica o calcola un aggregato; il secondo classifica, confronta semanticamente, estrae dati strutturati o sintetizza. L'elenco è verificato contro il registro del runtime e i manifest firmati. Esempio reale: la domanda «c’è un appuntamento HLT che si sovrappone a uno MNM nei prossimi tre mesi?» viene risolta in sei passi: read_events → due filter_entries (uno per HLT, uno per MNM) → filter_lists(op=overlap) → risposta finale. Nell'estrazione le date escono in ISO 8601 quando giorno, mese e anno sono scritti nel testo. Molti siti l'anno lo omettono sulle righe recenti: in quel caso il valore porta l'anno corrente e un asterisco davanti (*2026-05-29), che dichiara l'anno come assunto e non letto. Il campo resta vuoto solo quando nessuna data e’ ricavabile: una data visibile non diventa mai un campo vuoto.

Il numero degli executor non è riportato a mano in questa guida: il catalogo generato viene ricostruito dai manifesti firmati e fornisce l'inventario corrente. Il Compositore applica lo stesso contratto a tutti gli executor e non sceglie in base al trasporto. I verbi produttori ortogonali sono cinque (find per pattern, get per id/stato, read per blob da sorgente, list per container, filter per riduzione).

13.7 Come leggere i contratti

Le pagine collegate da questa guida distinguono ciò che il sistema offre oggi da ciò che è ancora previsto. Per interpretarle senza equivoci:

• le funzioni dichiarate attive devono avere riscontro nel codice, nei manifesti o nelle prove automatiche; una proposta futura viene indicata come tale;
• gli inventari e i conteggi variabili provengono dalle pagine generate, non da numeri copiati nel testo;
• i nomi in carattere monospaziato sono identificatori tecnici: non vanno letti come parole dell'interfaccia;
• gli esempi in linguaggio naturale mostrano come chiedere una funzione; i riferimenti tecnici successivi spiegano invece come viene realizzata;
• i collegamenti alla guida all'interfaccia indicano dove trovare una funzione nella chat web.

14. I principi, in otto carte

Se di questo documento doveste ricordare solo otto frasi, sono queste. Tutto il resto — codice, prompt, convenzioni — discende da qui.

15. Cosa NON è Metnos

Metà del progetto sta nei no. Ogni tentazione di aggiungere un elemento di questa lista va respinta.

• Non è un'infrastruttura di estensioni senza governo. Il nucleo è indipendente dal dominio, ma ogni istanza concreta ha un insieme circoscritto di executor ammessi e regole esplicite. Un dominio nuovo si esprime tramite executor e skill governati, senza lasciare che pacchetti arbitrari ereditino i privilegi dell'agente.
• Non esegue skill di terzi così come sono. Un formato installabile senza adattamento eseguirebbe codice altrui con i tuoi privilegi. Qui ogni pacchetto attraversa il filtro di ammissione in sette livelli, oppure non viene eseguito (cap. 7).
• Non addestra modelli. Niente addestramento specialistico o RLHF. La crescita avviene mediante memoria ispezionabile e sintesi sottoposta al controllo umano (cap. 7 e 9).
• Non è un agente dipendente dal cloud. Gira a casa; frontier è un consulto esplicito, mai la sede. Nessuna apertura non scelta.
• Non è un ambiente di sviluppo né un assistente alla programmazione. Non scrive codice in altri progetti per conto tuo; al massimo li analizza con executor in sola lettura.
• Non sostituisce la domotica. A un sistema domotico può chiedere; non lo duplica.
• Non moltiplica i canali a tutti i costi. Due canali fatti bene; gli altri quando servono davvero.

16. Dove andare dopo

Ora avete entrambi i livelli: il sistema dall'alto e la mappa dei contratti dei componenti. Usate l'atlante per il dettaglio implementativo, oppure proseguite con la visita guidata, il riferimento dei domini e la guida dell'interfaccia.

Metnos — Guida all'architettura.
mētis + noûs: l'intelligenza astuta al servizio della mente — su hardware tuo.
Documentazione in italiano e inglese su metnos.com; codice su github.com/brunialti/metnos.