1. Scopo e metodo

Questa pagina fornisce un metodo stabile per valutare una capacità di Metnos. Non racconta l'ordine in cui i componenti sono stati progettati e non sostituisce i loro contratti tecnici.

La domanda di partenza non è «la funzione è interessante?», ma «produce un risultato utile, con fonti e limiti comprensibili, nel contesto dell'utente corretto?». La valutazione combina comportamento osservabile, prove, tracciabilità e qualità dell'interazione. Una descrizione convincente o una risposta ben formulata non costituiscono da sole una prova.

2. Quattro qualità da non confondere

Le quattro qualità possono divergere. Un flusso può essere autonomo ma inutile, intelligente ma non autorizzato, oppure utile proprio perché si ferma e chiede conferma.

3. Le prospettive di valutazione

4. Come formulare un giudizio

Un giudizio utile dichiara la decisione, l'evidenza e la conseguenza. Le categorie seguenti servono a evitare formule vaghe come «da migliorare».

Ogni esito deve citare una prova controllabile: risultato di una verifica, voce del registro, sorgente originaria, stato persistito o comportamento riproducibile entro condizioni dichiarate. La prosa generata da un LLM non diventa evidenza solo perché è stata salvata.

5. Sette condizioni non negoziabili

1. Identità e autorizzazione. Ogni richiesta, sessione, credenziale e dato appartiene a un utente autenticato. Un guest o un altro utente non può interrogare il profilo, le fonti o i servizi del titolare.
2. Contratti degli executor. Argomenti, tipi, effetti, errori e reversibilità devono essere dichiarati e validati prima dell'esecuzione.
3. Separazione fra contenuto e controllo. Web, documenti, risultati degli strumenti e testo dei modelli non possono modificare policy, privilegi o istruzioni di sistema.
4. Consenso comprensibile. L'approvazione mostra azione, destinatario, account, dispositivo e conseguenze rilevanti; non nasconde effetti dietro etichette tecniche.
5. Tracciabilità e recupero. Piano servito, approvazioni, esiti ed errori devono essere correlabili senza esporre segreti e senza duplicare effetti dopo una ripartenza.
6. Fonti personali originarie. Preferenze e osservazioni citano il turno o il dato autorizzato da cui derivano. Una sintesi LLM non può citare un'altra sintesi LLM come prova.
7. Valutazione rappresentativa. Le prove coprono lingue, canali, utenti, errori e capacità effettive, non soltanto il percorso ideale di un singolo programmatore.

6. Tensioni che non scompaiono

Personalizzazione e instradamento riproducibile

Un profilo può migliorare tono, esempi e forma della risposta finale, ma non deve essere iniettato nel pianificatore soggetto a cache condivise. Se non entra nella chiave della cache viene ignorato quando la cache trova una corrispondenza; se vi entra, trasforma una cache di piani condivisi in una cache per utente e riduce il tasso di riuso, compromettendo la riproducibilità. Le alternative corrette sono applicarlo alla generazione finale oppure riscrivere esplicitamente la richiesta prima della cache, con una firma coerente.

Autonomia e controllo

Ridurre le conferme rende il flusso più rapido, ma aumenta il rischio di effetti inattesi. La soluzione non è un livello globale di «fiducia»: l'autorità va delimitata per tipo di operazione, fonte, durata, account e utente.

Utilità e riservatezza

Più fonti possono migliorare la risposta e allo stesso tempo creare un dossier personale eccessivo. Le directory sensibili, i dati sanitari o finanziari e i segreti richiedono esclusione predefinita o consenso specifico; la semplice possibilità tecnica di leggerli non autorizza la loro trasformazione in profilo.

Fluidità e trasparenza

Una risposta naturale non deve nascondere quale servizio è stato usato, quale dato è stato trovato o quale operazione è fallita. La trasparenza va resa leggibile, non eliminata.

7. Autonomia e proattività sono proprietà del mandato

Metnos non è autonomo o proattivo in senso assoluto. Lo è rispetto a uno specifico incarico: «ogni lunedì controlla il calendario», «se arriva un messaggio da questo mittente avvisami», «continua finché hai trovato tre fonti ufficiali». Il mandato definisce:

• utente e canale di consegna;
• evento o frequenza di attivazione;
• fonti consultabili e account utilizzabili;
• operazioni consentite e punti di approvazione;
• limite di costo, numero di tentativi e scadenza;
• modalità di revoca e comportamento in caso di errore.

Fuori da questi confini Metnos deve fermarsi, chiedere un nuovo mandato o presentare una proposta. Non può ampliare l'incarico facendo leva su una preferenza presunta.

7-bis. La lente proattiva

Prima di introdurre una nuova condizione di avvio o una nuova proposta automatica, verificare in ordine:

1. Segnale: quale evento osservabile la attiva?
2. Pertinenza: perché il segnale riguarda proprio quell'utente e quel mandato?
3. Fonte: l'accesso alla fonte è autorizzato e necessario?
4. Azione: il sistema propone, notifica o esegue?
5. Consenso: dove si colloca l'approvazione?
6. Limite: quando scade o viene sospesa?
7. Riconciliazione: come vengono gestiti dati nuovi che contraddicono osservazioni precedenti?
8. Verifica: quale evento o prova dimostra che il comportamento è corretto?

Se una domanda non ha risposta, la capacità non è pronta per essere presentata come disponibile.

8. Uso pratico del giudizio

Per una modifica o una nuova capacità, il risultato della revisione dovrebbe essere leggibile in questa forma:

Le specifiche correnti da consultare sono motore dell'agente, executor, approvazioni, osservabilità, utenti e sessioni, telos e vaglio.

Metnos — Prospettive e giudizio
Criteri correnti per valutare capacità, limiti e qualità dell'interazione.