Un termine compare in questo glossario quando è usato in più documenti del progetto e non è immediatamente ovvio. Il criterio è pragmatico: se un lettore senza contesto può inciampare sul nome, c'è una voce qui. Le definizioni sono brevi. I link portano alla fonte canonica — il documento dove il concetto è definito nella forma completa.
Il nucleo che coordina un turno. Riceve una richiesta già associata a utente, lingua, canale e conversazione; sceglie il percorso di esecuzione, valida ogni chiamata agli strumenti, applica policy e Vaglio, quindi conserva il risultato nel registro del turno. I canali si occupano dell'interfaccia; il runtime governa il lavoro.
Canonico: agent_runtime.html
La tendenza ad attribuire intenzioni, emozioni o coscienza a un sistema tecnico. Nella documentazione parole come memoria, giudice o Vaglio descrivono funzioni precise, non stati mentali: Metnos elabora richieste, chiama strumenti e registra risultati.
Approfondimento: Dialogo sui fini e i limiti
Decisione esplicita richiesta all'utente prima di un'azione che supera l'autorità già concessa. La scheda descrive azione, destinatario, effetti e scadenza; il consenso vale solo per quello specifico utente e per quella specifica operazione. Scadenza, rifiuto o dati diversi impongono una nuova richiesta.
Canonico: Esperienza di approvazione · runtime §9
Il principio per cui, nei casi di conflitto irriducibile fra libertà di Metnos e robustezza dei suoi effetti, vince la robustezza. La motivazione è economica, non ideologica: una restrizione di libertà è recuperabile in tempo lineare (Roberto approva, la soglia si aggiorna), mentre molte perdite di robustezza non lo sono affatto. La reversibilità sposta l'equilibrio rendendo annullabile ciò che altrimenti non lo sarebbe. Da non confondere con il paternalismo, che spinge la robustezza al di là di questa soglia.
Canonico: Architettura, cap. 5
Registro a sola aggiunta degli eventi che devono poter essere ricostruiti: turni, decisioni del Vaglio, importazioni di skill, operazioni pianificate e altre azioni sensibili. Le voci conservano l'identità logica dell'utente e gli identificatori necessari a risalire all'origine; non sono una trascrizione del ragionamento interno del modello.
Canonico: Osservabilità · runtime §11
Il grado di autorità concesso a un utente per una certa operazione. Il profilo utente distingue accesso in sola lettura, accesso ristretto e accesso completo; le regole operative traducono poi quel profilo, le capacità dell'executor e il contesto corrente in consenti, nega o chiedi approvazione. L'autonomia non si trasferisce fra utenti o dispositivi.
Canonico: Regole operative · Utenti, dispositivi e sessioni
Il secondo dei due livelli con cui Metnos impara a rispondere senza scomodare il modello. Mentre il fastpath (L0) ricorda una singola domanda parola per parola, l'autopath ricorda lo schema di un piano riuscito — la sequenza di passi, spogliata dei dettagli — e lo riusa per tutta una famiglia di richieste affini. Nasce da successi ripetuti su quel tipo di domanda; è dato leggibile e reversibile, non un modello addestrato. Da non confondere con la skill, che è un insieme di strumenti, non un piano.
Il costo che una proposta o una notifica impone all'attenzione dell'utente. Entra nella valutazione delle iniziative proattive insieme a utilità, urgenza e allineamento ai telos; non autorizza azioni e non sostituisce il consenso.
Canonico: Telos
Executor fornito direttamente dal runtime e firmato come parte della versione distribuita. Serve per funzioni che richiedono accesso al ciclo del servizio, all'orologio o a uno stato persistente condiviso. Non viene generato da synt e può essere attivo o disabilitato dalla configurazione. Lo scheduler è un esempio.
Canonico: executor §2 e §6
La sequenza con cui il synt affronta un bisogno operativo. Nel turno può comporre una catena di executor esistenti oppure preparare, attraverso il percorso governato, un candidato per una capacità mancante. Nell'omeostasi notturna il produttore attivo propone soltanto deduplicazioni e non genera generalizzazioni o specializzazioni. La cascata non autorizza da sola il nuovo codice e non promette che ogni richiesta sia eseguibile.
Canonico: synt §3
L'adattatore che traduce un'interfaccia esterna in richieste e risposte di Metnos. I canali disponibili sono la chat web e Telegram. Entrambi condividono runtime, identità e regole operative; ciascuno adatta al proprio mezzo le risposte progressive, gli allegati, i pulsanti, i dialoghi e le richieste di posizione.
Canonico: channel.html
Tre gradi di scostamento di un'azione rispetto alla Costituzione e ai telos, che il progetto distingue in modo rigoroso perché solo uno dei tre blocca.
Canonico: vaglio §3 · Dialogo — Giornata IV
Il nucleo di vincoli non negoziabili applicato dal Vaglio: perimetro di autorità, tutela da effetti dannosi, obbedienza entro quel perimetro e tracciabilità. Sono guardie operative, non preferenze del modello: una violazione blocca l'azione. I telos esprimono invece gli orientamenti positivi dell'utente.
Una funzione che Metnos può eseguire come passo del proprio ragionamento. È codice eseguibile, non un'analogia biologica. Un executor è codice Python firmato, con manifest, profilo di sandbox, contratto di errore. Può essere parte del seed iniziale o nato per sintesi dal synt con approvazione umana.
Canonico: Executor · Catalogo degli executor
Executor Metnos eseguito non sul server, ma su un dispositivo appaiato:
per esempio un PC Windows o un portatile Linux nella stessa rete. Non è
un secondo Metnos: il server conserva scelta dell'executor, policy, Vaglio,
firma del payload e audit; il dispositivo, tramite metnos-client,
verifica la firma, esegue nel contenimento disponibile per il proprio sistema
operativo e restituisce il risultato. La remotizzazione è ammessa solo per
executor firmati e dichiarati compatibili dal manifest.
Canonico: architecture/remote_executors.html · pairing, cap. 6 · sandbox, cap. 10
Record persistente di una richiesta: identifica utente, conversazione, canale, tempi, percorso scelto, chiamate agli executor, risultati ed esito finale. Permette di riprendere la cronologia e di collegare un'osservazione alla sua origine; non pretende di conservare o rendere verificabile il ragionamento privato del modello.
Canonico: runtime §11 · Osservabilità
Il primo dei due livelli di memoria con cui Metnos evita di pensare due volte la stessa cosa. È la corsia veloce: quando una domanda identica è già stata risolta una volta, la volta successiva la risposta viene rigiocata di slancio, senza interpellare il modello — stesso esito, latenza e costo ridotti al minimo. Conserva i dettagli concreti della richiesta. Il livello superiore è l'autopath (L1), che generalizza il piano a un'intera famiglia di richieste.
Il servizio che espone chat web, API del canale agent e pagine di amministrazione. Autentica l'utente, mantiene conversazioni e sessioni e consegna ogni turno al runtime. Telegram usa lo stesso nucleo tramite il proprio daemon di canale.
Seconda fase del Vaglio. Produce un punteggio graduato di allineamento rispetto ai telos. Il percorso predefinito usa regole locali deterministiche; un giudice basato su un modello separato è facoltativo e configurabile.
Canonico: vaglio §5
Prima fase del Vaglio. Verifica deterministica che l'azione non contraddica un articolo della Costituzione. Output binario: blocca o lascia passare. Non un LLM: regole eseguibili.
Canonico: vaglio §4
Termine greco (ὕβρις), nel mito la tracotanza di chi supera la misura che gli spetta, provocando la punizione degli dei. Nel progetto è la metafora che inquadra il rischio di un agente che sa e agisce: trasformare l'utilità in arroganza, superare i propri limiti, finire per contendere con le Leggi che il creatore ha posto. Il Vaglio è la struttura che risponde a questo rischio. Introdotto nel prologo del Dialogo — Giornata I.
L'identità utente stabile alla quale Metnos associa autorizzazioni, preferenze, lingua, sessioni e dati. I mittenti dei diversi canali vengono associati a questa identità mediante autenticazione o appaiamento. I dati e le azioni restano isolati per utente anche quando più persone usano la stessa installazione.
Canonico: Utenti, dispositivi e sessioni · Canali
L'insieme di regole e cataloghi che mantiene interfaccia, dialoghi, messaggi di servizio e prompt nella lingua risolta per l'utente e per il turno. Le stringhe dell'interfaccia provengono dal catalogo i18n; una nuova lingua entra nell'inventario attraverso i propri record e prompt, senza condizioni speciali nel codice. La lingua di un utente non modifica quella degli altri.
Canonico: Lingue e traduzioni
Vedi Costituzione.
Large Language Model. In Metnos non indica un fornitore specifico: il sistema usa modelli linguistici, ma non ne incorpora uno nel proprio contratto. L'accesso passa sempre per l'interfaccia LLM, che rende il sistema indipendente dal fornitore. Una questione ricorrente dell'architettura è stabilire quando fidarsi del modello: per questo esiste il Vaglio, che risolve il self-enhancement bias.
L'uso dei modelli linguistici passa per un'interfaccia comune, non per il client di un fornitore specifico. Lo stesso principio vale per embedding e altri servizi di intelligenza artificiale. La separazione ha tre scopi.
frontier commerciale a un modello locale, o viceversa — richiede una riga di
configurazione, senza modificare il codice di Metnos.I ruoli del modello, l'instradamento e i fornitori disponibili sono risolti dal runtime in base alle impostazioni correnti.
Canonico: runtime §4 · Guida all'architettura §8
In Metnos il termine non indica un unico archivio. Conviene distinguere:
Canonico: Runtime · Riuso dei piani · Mnestoma
Una traccia di co-attivazione fra due executor: "l'output di A è stato passato a B in questo turno". Si rinforza con l'uso e decade col disuso. Un record è evidenza soltanto del passaggio registrato; per risalire alla fonte occorre anche l'identificatore del turno. La registrazione automatica da ogni turno non è attualmente collegata al percorso ordinario.
Canonico: Mnest · Guida all'architettura, cap. 9 · Dialogo sugli executor
Il grafo emergente di tutti i mnest: insieme delle co-occorrenze fra executor che si sono effettivamente verificate. Non è progettato a tavolino, emerge dall'uso. È la memoria relazionale di Metnos, distinta dalla memoria contestuale dell'LLM e dalla memoria episodica delle conversazioni. La forma inglese è mnestome (suffisso biologico -ome, come in microbiome); la forma italiana mantiene il suffisso latino -ma.
Canonico: Mnestoma · Guida all'architettura, cap. 9
Un agente personale auto-ospitato e governato, accessibile dalla chat web e da Telegram. Comprende richieste in linguaggio naturale, costruisce un piano ed esegue le operazioni mediante executor sottoposti a contratti, policy e approvazioni. Identità, preferenze, sessioni e dati sono separati per utente. Etimologia. Il nome è greco e composto: mêtis (μῆτις), la saggezza pratica che si adatta alla situazione — l'astuzia di Ulisse, anche dea madre di Atena —, e noûs (νοῦς), l'intelletto che ragiona. Le due forme greche della mente, riunite in un nome solo. Il sistema le riunisce davvero: l'LLM è il noûs, il vaglio e il mnestoma sono la mêtis.
Per iniziare: Guida rapida · Guida all'architettura
Il contratto dichiarativo di un executor: nome canonico, descrizione, argomenti, risultato, capability, collocazione, limiti e requisiti. Il caricatore lo valida prima di esporre l'executor al pianificatore. Anche il Tutor lo usa per descrivere ciò che il sistema sa fare.
Il riconoscimento di un nuovo sender su un canale multi-utente (tipicamente Telegram): l'utente riceve un codice firmato out-of-band, lo presenta a Metnos, il legame sender↔identità viene registrato. Revoca possibile in ogni momento.
Canonico: pairing.html
Termine interno di Metnos: un insieme di executor che, a partire da una richiesta (query) dell'utente, producono un output o un'azione — il percorso che porta dalla domanda al risultato eseguendo, in sequenza, gli strumenti giusti. Si declina in due forme memorizzate, così l'assistente non deve ricostruirle ogni volta: il fastpath (L0), il path della stessa richiesta già risolta, e l'autopath (L1), il path generalizzato a un gruppo di richieste affini.
Canonico: fast_path.html
L'arbitro operativo delle azioni reattive: verifica forbidden paths, never-list per sender, rate limit, budget, green zone per autonomy, e (check 0) la Guardia costituzionale. Emette un verdetto: allow, deny, approve_required.
Canonico: policy.html
Un mnest incompleto: la traccia di un tentativo in cui Metnos avrebbe voluto passare l'output di un executor a un altro che non esiste ancora. È un desiderio non soddisfatto che resta nel mnestoma e che, se si ripete, diventa il segnale da cui il synt propone all'utente la sintesi di un nuovo executor.
Canonico: Mnest, cap. 8 · Guida all'architettura, cap. 10 · Dialogo sugli executor
Insieme di attività pianificate che esaminano dati operativi e producono proposte, manutenzione o indici. Ogni attività viene eseguita come un nuovo turno dello stesso utente e non eredita autorità da altri utenti. Le proposte non diventano azioni soltanto perché sono state formulate da un modello.
Canonico: Attività programmate · Praxis engine
Il contenitore in cui gira ogni tool con effetti sul filesystem o sul
sistema. Profili bubblewrap (bwrap) che definiscono cosa il tool può
leggere, scrivere, eseguire. Forbidden paths espliciti: un tool non vede
nemmeno .audit/.
Canonico: sandbox.html
Builtin che esegue un executor o una richiesta salvata con una cadenza definita. Le attività si possono elencare, modificare, sospendere o annullare e appartengono all'utente che le ha create. Ogni esecuzione è un nuovo turno, sottoposto a policy e credenziali correnti: la pianificazione non concede un'autorità permanente.
Canonico: executor §6
La sessione della chat web che in quel momento possiede la continuità dell'utente. Se Metnos rileva una sessione aperta su un altro dispositivo, offre tre scelte: continuare quella sessione sul dispositivo corrente, rendere attiva la sessione corrente chiudendo la precedente, oppure annullare. Il controllo e il trasferimento sono indipendenti per ogni utente.
Canonico: Utenti, dispositivi e sessioni · Chat web
Un'integrazione o un sottosistema configurabile mostrato nella chat web in Settings > Sistema > Servizi. Quella pagina è la fonte per l'elenco visibile; il Tutor può spiegarne struttura e percorso, mentre lo stato attivo viene letto dal sistema in quel momento.
Canonico: Tutor e superfici Settings · Skill e backend
La tendenza documentata di un LLM a valutare positivamente i propri risultati o stili familiari (Zheng et al. 2023). È la ragione strutturale per cui il Vaglio esiste: se l'LLM che valuta è lo stesso (o riceve il contesto) di quello che ha proposto, tifa per sé. La soluzione consiste nel separare il contesto e il prompt e, quando necessario, anche il fornitore.
Canonico: vaglio §6 · Dialogo — Giornata III
Un insieme di executor affini, raccolti come una
sola capacità: la skill della posta, per esempio, riunisce leggere, inviare e
spostare i messaggi. È l'unità con cui una capacità si attiva, si rende fidata o
si tiene a riposo. Tre fasce: nucleo (core, parte essenziale di Metnos),
distribuite con Metnos (first-party, curate dal progetto) e importate
(provenienti da terzi). Skill e backend sono indipendenti: la
skill decide se una capacità è attiva, il backend decide come
raggiunge un fornitore concreto, scelto sempre dalla configurazione e mai dal
modello. Da non confondere con l'autopath: quello è un
piano appreso, questa è una dotazione di strumenti.
Canonico: Architettura Intro §3 — skill ↔ backend
Il processo che compone executor esistenti o prepara una proposta per un nuovo executor quando una capacità manca. La cascata procede dalle strategie meno costose a quelle più impegnative; codice e manifest devono superare i controlli di ammissione e il passaggio umano previsto.
Canonico: Synt · Importazione delle skill
Un "fine ultimo" (τέλος, greco): qualcosa verso cui si tende, non un
obiettivo da raggiungere. L'utente scrive 3-7 telos in
TELOS.md (sesto file del workspace); ogni proposta proattiva
di Metnos viene valutata contro questi, da un LLM indipendente nel
Vaglio. I telos sono positivi (vs
le Leggi che sono negative), orientati
all'utilità (vs la sicurezza delle Leggi), scritti dall'utente
(vs le Leggi co-scritte con Metnos). La Costituzione non giudica,
la teleologia sì.
Canonico: telos.html · Dialogo sui fini e i limiti
Una funzione che Metnos può chiamare durante il suo ciclo di ragionamento: ricerca, lettura di file, calcolo di hash, posta, web, georeferenziazione e così via. Nel catalogo esposto al modello ogni strumento ha uno schema validato; nel runtime l'unità eseguibile e governata è l'executor.
Canonico: Catalogo degli executor · Capacità disponibili
La modalità con cui Metnos risponde a domande sul proprio uso senza eseguire l'operazione richiesta. Recupera fonti ammesse da documentazione, manifest e registri pubblicabili, le filtra per destinatario e dichiara quando una risposta non è documentata. Per le operazioni pratiche propone prima una frase naturale da rivolgere a Metnos; per una pagina dell'interfaccia indica prima il percorso nella chat web.
Canonico: Tutor
Abbreviazione informale del registro del turno o, quando specificato, di un registro di audit.
Un marker che avvolge qualsiasi contenuto proveniente da fuori Metnos
(output di web_fetch, testo di mail, allegati). Il prompt istruisce l'LLM
a trattare quanto è dentro <untrusted>…</untrusted>
come dato, non come istruzione. Mitigazione principale
contro il prompt injection indiretto. Usato coerentemente ovunque.
Canonico: runtime §10 · Policy
Il componente di valutazione indipendente. In italiano vagliare significa separare col setaccio: un gesto meccanico, non antropomorfico. Due fasi: Guardia costituzionale (binaria, deterministica: blocco o silenzio) e Giudice teleologico (gradiente, LLM indipendente). La frase-cardine del design: "La Costituzione non giudica, la teleologia sì". Il Vaglio è la struttura che la rende operativa.
Canonico: vaglio.html · Dialogo — Giornate III-IV
L'area dati locale usata dai sottosistemi che condividono stato operativo, per esempio telos, mnestoma e scheduler. I dati dell'installazione possono risiedere in più directory fisiche; accesso, viste e operazioni restano comunque vincolati all'identità dell'utente corrente.
Canonico: Memoria · Isolamento per utente