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.
Proposta di azione generata spontaneamente da Metnos (dalla reflection, dall'indexer, da un neurone), in contrasto con una PlannedAction che discende da una richiesta esplicita dell'utente. Contiene il piano, l'impatto stimato, la reversibilità, una razionale testuale. Viene valutata dal Vaglio contro i telos; se supera la soglia, arriva all'utente nell'inbox proposte.
Canonico: Prospettive estese §2D · telos §4
Il "cuore pensante" di Metnos: il ciclo ReAct (thought → action → observation) che, per ogni richiesta, costruisce il prompt, invoca il modello linguistico, valida le chiamate a tool, registra tutto nella ExecutionTrace. Non conosce i canali né la domotica: riceve testo, restituisce testo, usa tool.
Canonico: agent_runtime.html
La tendenza a trattare un sistema tecnico come se avesse intenzioni, emozioni o coscienza. Il progetto usa termini evocativi (neurone, sinapsi, memoria, personalità) per brevità espositiva, ma mantiene in più punti un framing linguistico esplicito per evitare che si scivoli nell'illusione: Metnos non "sente", non "vuole", non "pensa". Esegue loop, chiama tool, registra trace. La scelta del nome Vaglio (invece di "Arbitro" o "Super-io") rientra in questa stessa cautela.
Framing canonico: constitution (sezione linguistica)
Oggetto che rappresenta una richiesta di approvazione all'utente, prima che Metnos esegua un'azione con effetto sul mondo (invio mail, scrittura file, spesa). Ha una macchina a stati (pending → granted/denied/timeout), un timeout che dipende dal canale, un'audit trail. Il Gateway è l'unico autorizzato a costruirne una.
Canonico: approval_ux.html · gateway §4.1
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
Un agente specializzato in casa per ingresso vocale e controllo domotica (wake-word, STT, TTS, MQTT verso la centralina domotica). Metnos non assorbe queste funzioni: le lascia a un assistente dedicato già presente o da costruire. Nel disegno esteso (Prospettive estese §2B) Metnos e l'assistente domotico si parleranno tramite un canale inter-agente dedicato, con divisione del lavoro netta: l'assistente domotico ha calendari, voce e domotica; Metnos ha ricerca documentale e memoria strutturata. Nei nostri doc trattiamo il pattern in astratto; nell'ambiente dell'autore esiste un progetto concreto che ricopre questo ruolo, parallelo a myclaw.
Presentazione canonica: Architettura Intro §5
Registro append-only JSONL in workspace/.audit/. Ogni trace,
ogni approvazione, ogni modifica al workspace, ogni modifica costituzionale
lascia una riga. È la Legge 3 (tracciabilità) resa operativa: una firma che
sopravvive a reboot, crash, aggiornamenti.
Canonico: observability §3
Tre livelli di libertà con cui Metnos opera, impostati per sender+canale: read_only (legge, non scrive, non spende), supervised (chiede conferma per ogni azione con effetto), full (agisce e riferisce, chiede conferma solo per cose irreversibili o costose). Default: supervised. Il livello si cambia esplicitamente.
Canonico: Architettura Intro §6 · policy §2
Il "costo di disturbare" l'utente: un contatore che cresce ogni volta che Metnos pubblica una proposta, decresce nel tempo. Se il budget è esaurito, una nuova proposta — anche se ben allineata ai telos — viene rinviata al riassunto serale o rigettata. Evita l'assedio di notifiche.
Canonico: telos §5
Terza categoria di executor, introdotta in v1.1 (25/4/2026): vive nei sorgenti di Metnos invece che nel workspace, è firmato come parte della release del progetto, non passa per la pipeline di sintesi (il synt non può mai generarne uno). Implementa servizi che hanno bisogno del clock di sistema, del loop async del gateway o di stato persistente trasversale. Lifecycle ridotto a due stati: attivo e disabilitato in config. Esempio: scheduler.
Canonico: executor §2 e §10
La sequenza di strategie con cui il synt risponde a un bisogno operativo, ordinate per costo crescente. Reattive (turno utente): comporre (catena di executor esistenti, zero LLM frontier) e generare (pipeline a sette stadi, ~1€). Introvertive (omeostasi notturna): fondere, generalizzare, specializzare. Onora il telos di non-rinuncia: synt esaurisce la cascata prima di rispondere «non posso».
Canonico: synt §3 e executor §7.1
Protocol Python che astrae come Metnos riceve input e invia output. CLI, Telegram, voce (via un assistente domotico sibling), futuro AgentChannel per dialogo inter-agente. Ogni canale ha capability (bottoni inline? streaming? markdown?) che Metnos interroga prima di produrre output.
Canonico: channel.html
Tre gradi di "non-allineamento" 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
Le quattro regole che Metnos rispetta in modo non negoziabile. In ordine
di precedenza: Legge 0 (perimetro fisico ed economico —
cosa può toccare, quanto può spendere); Legge 1
(non-nocività — non fare danno a persone, dati, processi);
Legge 2 (obbedienza informata — eseguire solo istruzioni
che hanno passato la 0 e la 1); Legge 3 (tracciabilità —
lasciare traccia auditabile di tutto). Scritte in SOUL.md,
firmate, versionate. La Costituzione non giudica, verifica: se un
articolo è violato, blocca; altrimenti tace. Vedi
telos per il suo complemento positivo.
Canonico: constitution.html
Una funzione che Metnos può eseguire come passo del proprio ragionamento. Termine introdotto dal Dialogo sugli executor e la memoria distribuita in sostituzione del precedente neurone: rispetto a quel termine, mette al centro il fatto che si tratta di codice eseguibile (non di un'analogia con i neuroni). 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: architecture/executor.html (microprogettazione v1.1, approvato 24/4/2026) · Architettura, cap. 9 · Dialogo sugli executor
Oggetto immutabile che raccoglie tutto ciò che è successo durante una richiesta: step di ragionamento, tool call, risultati, costi, timing, esito finale. Non è un log accessorio: è la fonte primaria di verità. Audit, replay, eval, fitness dei neuroni, memoria episodic: tutti consumano ExecutionTrace. Append-only durante, immutabile dopo la chiusura.
Canonico: agent_runtime §5 (schema e ciclo di vita) · types.html
Il punto di ingresso unico di Metnos: espone HTTP interno, accoglie i canali (CLI, Telegram, …), gestisce le sessioni, costruisce le ApprovalRequest, orchestra il Runtime. Processo systemd unico. Nessun canale comunica mai direttamente col runtime: passa sempre da qui.
Canonico: gateway.html
Seconda fase del Vaglio. LLM indipendente dal
proponente che stima il fit di un'azione rispetto ai telos.
Produce un punteggio graduato, non binario.
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'idea che Metnos non debba conoscere solo il sender (es.
telegram:@roberto) ma l'identità umana stabile dietro
sender multipli (voce, CLI, Telegram). È una questione trasversale alle
famiglie proattive e al multi-agente. La microprogettazione
identity.html è pianificata, non ancora scritta.
Visione: Prospettive estese §3
Parola greca che significa fama, rinomanza, memoria duratura di ciò che si è fatto. Nell'Iliade è ciò che un eroe lascia di sé. Voce storica: nelle prime fasi del progetto era stata scelta come radice del nome originario («Mykleos»), poi sostituito. La voce resta nel glossario perché il termine continua a comparire nei dialoghi e in tradizione classica; il nome del progetto oggi non deriva più da kleos, ma da mêtis + noûs.
Vedi Costituzione.
Large Language Model. Nel progetto non è un fornitore specifico: Metnos usa LLM ma non li contiene. L'accesso passa sempre per l'interfaccia LLM che rende il sistema provider-agnostic. Un tema ricorrente del design è sapere in che casi dell'LLM fidarsi: per questo esiste il Vaglio, che risolve il self-enhancement bias.
Un principio architetturale vincolante di Metnos: l'uso di qualsiasi modello linguistico passa sempre per un'interfaccia logica, mai per il client di un fornitore specifico. La stessa idea vale per servizi AI affini (STT, TTS, embedding, speaker ID). La motivazione è tripla.
Il contratto è definito con typing.Protocol: ogni servizio
ha un'interfaccia (LLMProvider, STTProvider,
TTSProvider, …), un registry, e implementazioni
intercambiabili via configurazione.
Nell'ambiente dell'autore, questo pattern è realizzato da suprastructure, un package sibling che fornisce l'interfaccia e i backend già pronti. In un ambiente diverso, l'interfaccia potrebbe essere realizzata da qualunque altro adapter o framework (LangChain, LiteLLM, un modulo custom): il contratto resta. Metnos dipende dall'interfaccia, non dall'implementazione.
Canonico: Architettura Intro §5 · agent_runtime §6
Tre-più-uno livelli che prendono il vocabolario da CoALA (Cognitive Architectures for Language Agents).
Canonico: memory.html
Una traccia di co-attivazione fra due executor: "l'output di A è stato passato a B in questo turno". Si rinforza con l'uso, decade col disuso. Termine introdotto dal Dialogo sugli executor e la memoria distribuita in sostituzione del precedente sinapsi.
Canonico: architecture/mnest.html (microprogettazione v1.1, under approval) · 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: architecture/mnestoma.html (microprogettazione v1.1, under approval) · Architettura, cap. 9
Il progetto stesso: un assistente personale che vive in casa, riceve
input da più canali (CLI, Telegram, voce), agisce al posto
dell'utente chiedendo permesso quando serve. 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.
Il dominio pubblico del progetto è metnos.com; il
processo che gira sul server di casa è ancora chiamato
myclaw (path ${METNOS_HOME}/, servizio
myclaw-gateway.service) per continuità con il repo
preesistente. Storico. Fino al 24 aprile 2026 il progetto
si chiamava «Mykleos», da kleos; il
nome è stato cambiato perché era marchio già
registrato altrove.
Ingresso: Quick tour · Architettura — Introduzione
Termine deprecato dopo il Dialogo sugli executor e la memoria distribuita: il termine canonico oggi è executor. La voce resta per traccia storica. Significato originale: un tool auto-sintetizzato da Metnos quando i tool esistenti non bastano. Il termine è metaforico (attenzione a non prenderlo come "pensiero"): un neurone è codice Python con firma HMAC, test di nascita, journal di co-attivazioni. Compete per fitness: se dà risultati scadenti su scenari ripetuti, decade e viene eventualmente rimosso.
Canonico oggi: architecture/executor.html (v1.1). Storico: neuron.html (deprecato) · Neuroni, Sinapsi e Memoria v1
Progetto open-source su GitHub (openclaw/openclaw), scritto in TypeScript su Node 24+. Ispirazione principale di Metnos per il pattern gateway-first, multi-canale, sandbox plug-in. Metnos non ne è un clone: riusa alcune idee in un linguaggio (Python) coerente col resto dello stack di casa (suprastructure come implementazione dell'interfaccia LLM, sibling agents preesistenti).
Confronto dettagliato: Architettura Intro §2
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
Un'azione che Metnos sta per eseguire su richiesta esplicita dell'utente (reattivo). Contiene tool, argomenti, effect_class, sender, trace_id. Passa per la Policy e per la fase Guardia del Vaglio; il giudice teleologico non la valuta (il Telos non giudica richieste esplicite). Distinto da ActionProposal, che nasce spontaneamente.
Canonico: types §4.1
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: architecture/mnest.html, cap. 8 (microprogettazione v1.1, under approval) · Architettura, cap. 10 · Dialogo sugli executor
Il processo ricorrente (quotidiano) con cui Metnos rilegge le proprie
ExecutionTrace recenti e propone
aggiornamenti: fatti da ricordare (FactProposal) e — versione
estesa — azioni da compiere (ActionProposal).
Le proposte richiedono approvazione umana.
Canonico: memory §6
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
Primo (e per ora unico) builtin proposto: invoca un altro executor (o catena) a un ritmo definito. Sostituisce l'idea sbagliata di «routine concordate» come categoria di design separata. Argomenti chiave: target_executor, schedule (cron-like o NL), delivery_channel, count (anche infinite), expiry, on_failure. Operazioni gemelle: list, cancel, modify. Stato persistente: workspace/.runtime/scheduler.sqlite.
Canonico: executor §10
La tendenza documentata di un LLM a valutare positivamente i propri output 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: contesto separato, prompt separato, idealmente provider separato.
Canonico: vaglio §6 · Dialogo — Giornata III
Altri agenti specializzati che possono vivere nello stesso ambiente di Metnos e condividere con esso la stessa astrazione LLM (vedi interfaccia LLM). Un agente domotico è un esempio; altri possono essere bot specializzati su domini ristretti (industriali, didattici, medicali). Metnos è pensato per convivere, non per essere unico: lo scambio avviene via canale inter-agente (Prospettive estese §2B).
Termine deprecato dopo il Dialogo sugli executor e la memoria distribuita: il termine canonico oggi è mnest; il grafo delle sinapsi corrisponde al mnestoma. La voce resta per traccia storica. Significato originale: un collegamento dichiarato o osservato fra neuroni: "quando si attiva A, tende ad attivarsi anche B". Viene rinforzato dall'uso, indebolito dal disuso (decadimento à la Ebbinghaus). Il grafo delle sinapsi è un rollup derivato dai journal dei singoli neuroni.
Canonico oggi: architecture/mnest.html (v1.1). Storico: synapse.html (deprecato)
Il processo che fa nascere e maturare il pool degli executor di Metnos. Non un agente, non un oggetto: una cascata di strategie ordinate per costo crescente (vedi cascata). Sostituisce il termine v1.0 synthesizer: più corto, più aderente al ruolo. Trigger reattivo (proto-mnest dentro il turno utente) o introvertivo (analisi notturna del mnestoma). Ogni proposta passa per il gate umano.
Canonico: synt.html (v1.1). Storico: synthesizer.html (deprecato)
Nell'ambiente dell'autore di Metnos, suprastructure è il
package sibling che realizza concretamente l'interfaccia
LLM e le altre astrazioni di servizio AI (STT, TTS, embedding, speaker
ID, model registry). Vive in /opt/suprastructure/. Ogni
servizio è un'interfaccia typing.Protocol con backend
intercambiabili via YAML (Claude, OpenAI, llama.cpp, Piper, faster-whisper,
…). Cambiare backend = una riga. Nessun consumer se ne accorge. È
condiviso con l'assistente domotico e
altri sibling agents.
In un ambiente diverso il ruolo di suprastructure può essere ricoperto da qualunque altro adapter: il contratto è l'interfaccia, non questa implementazione particolare. Metnos è stato disegnato in modo che i suoi documenti e il suo codice non dipendano da suprastructure ma dal pattern che suprastructure incarna.
Canonico: Architettura Intro §5
Termine deprecato dopo la riscrittura v1.1 (25/4/2026): il termine canonico oggi è synt. La voce resta per traccia storica. Significato originale: la pipeline a sette stadi che produceva un nuovo neurone quando un fallimento ripetuto lo giustificava (spec da fallimento → bozza → analisi statica → test → approvazione umana → firma; retry max 3). Oggi la pipeline è lo stadio di generare della più ampia cascata di synt.
Canonico oggi: synt.html (v1.1). Storico: synthesizer.html (deprecato).
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 loop di ragionamento:
fs_read, fs_write, shell_exec,
web_fetch, …. Protocol Python con schema validato,
contratto di errore, rate limit. I neuroni sono tool auto-sintetizzati; i
tool base sono quelli che Metnos trova al primo avvio.
Canonico: tool.html
Abbreviazione informale di ExecutionTrace.
Un punteggio che si accumula per-neurone (o per-coppia neurone/effect
class) basato sugli esiti storici: gap_pre − gap_post. Il TrustStore è
aggregato offline (niente apprendimento online) e letto a runtime dalla
Policy per modulare la soglia di approvazione
(trust-gating). Un neurone affidabile su azioni a basso rischio può
vedere approve_required promosso a allow.
Canonico: rl_offline.html
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: agent_runtime §3 · constitution
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
La "casa" di Metnos sul disco: ${METNOS_HOME}/workspace/.
Contiene cinque file markdown di personalità (IDENTITY, USER, MEMORY,
AGENTS, SOUL) più TELOS.md, più la cartella di audit
e gli indici di memoria episodic/semantic.
Canonico: workspace.html
Progetto open-source in Rust (zeroclaw-labs/zeroclaw). Ispirazione di Metnos per i livelli di autonomia, la sandbox a strati, il pattern trait-based. Scartato come base direttamente riusabile perché riscrive da zero il layer LLM/STT/TTS che in casa è già fornito da suprastructure.
Confronto dettagliato: Architettura Intro §2