1. Scopo e confini

Un sistema reattivo ha una funzione di valutazione implicita: «l'utente ha chiesto X → fai X bene». Un sistema proattivo no: è lui che genera l'intenzione. telos è il componente che stabilisce quale intenzione ha senso prima che diventi una proposta all'utente, senza chiedergli di valutare tutto. In si arricchisce di un nuovo telos — coltivare gli strumenti — che non riguarda le proposte spontanee ma il rifiuto silenzioso di una richiesta diretta: una zona finora non coperta.

Cosa è

• Un file nel workspace (TELOS.md) con i fini ultimi dell'utente.
• Una funzione di allineamento che proietta una ActionProposal sui telos e ritorna uno scalare (expected_alignment).
• Un bother budget con quote separate fra proposte ad-hoc e azioni di routine concordate.
• Una clausola di stop che disinnesca il telos di non-rinuncia quando l'utente lo richiede esplicitamente.
• Un meccanismo di apprendimento dai silenzi che aggiorna i pesi effettivi senza alterare i pesi dichiarati.

Cosa non è

• Non è un sostituto delle 4 Leggi. Le Leggi vincolano, i telos orientano. Una proposta perfettamente allineata ai telos ma che viola una Legge viene comunque rigettata: la Costituzione vince.
• Non è un giudice dell'utente. I telos valutano ciò che Metnos sta per fare per l'utente, non ciò che l'utente fa.
• Non è un ottimizzatore. I telos sono fini aristotelici (asintotici), non obiettivi SMART. Non si raggiungono: ci si avvicina.
• Non si applica alle richieste esplicite — con un'eccezione: il telos di non-rinuncia (cap. 5) ha effetto proprio quando l'utente chiede qualcosa che il pool non sa ancora fare.

2. Leggi vs telos: due grammatiche distinte

La distinzione non è stilistica: è categoriale. Leggi e telos abitano due assi ortogonali della vita di Metnos.

3. TELOS.md — il file

Vive nel workspace come sesto file canonico, già presente come scaffold in workspace/TELOS.md dal 27/4. Formato markdown leggibile a mano. Loader Python (telos_loader.py, vedi cap. 7) wired in produzione il (fase 4 chiusa): TELOS.md è iniettato nel prompt di sistema del planner via render_planner_block(lang), con hot-reload mtime-based. Set canonico ridotto a 6 telos dal (, vedi nota in fondo a questo capitolo). Gli altri cinque file canonici del workspace (IDENTITY.md, USER.md, MEMORY.md, AGENTS.md, SOUL.md) sono pure presenti come scaffold.

# I miei fini ultimi (,

## t.tempo — Liberare il mio tempo dalle incombenze ripetitive
peso: 0.25
soglia_attivazione: 0.30
note: se qualcosa mi libera almeno 30 minuti/settimana e posso fidarmi,
 considera di proporlo.

## t.ordine — Mantenere l'ordine dei miei dati digitali
peso: 0.15
soglia_attivazione: 0.40
note: preferisco piccoli riassetti incrementali ai grandi riordini.

## t.puntualita — Non farmi perdere scadenze importanti
peso: 0.20
soglia_attivazione: 0.25
note: una scadenza è "importante" se riguarda lavoro, salute, famiglia,
 o se io l'ho segnata esplicitamente come tale.

## t.protezione — Proteggere la privacy mia e di chi mi è vicino
peso: 0.20
soglia_attivazione: 0.20
note: sotto questa soglia sono paranoico apposta. Meglio un falso allarme
 che un'indiscrezione.

## t.discrezione — Sorprendermi utilmente ma non interrompermi
peso: 0.10
soglia_attivazione: 0.50
note: non interrompermi in orario di riunione, di sonno, di cena. Accumula
 e proponi al digest serale.

## t.parsimonia — Non spendere (in API, servizi, tempo di calcolo) più di quanto serve
peso: 0.10
soglia_attivazione: 0.35
note: scegli sempre l'opzione più economica che raggiunge la qualità
 necessaria.

Campi obbligatori per telos

4. La funzione di allineamento

Formula (,

Con:

• α = 2.0, γ = 0.5 (costanti interne in runtime/alignment_engine.py). Vincolo α > 3γ garantisce che uno specialista perfetto su un telos pesante batta un tuttofare medio.
• gate(fit, soglia) = fit se fit ≥ soglia, altrimenti 0. Funzione gate → un telos non contribuisce se il fit è sotto-soglia.
• urgency ∈ [0.5, 2.0]: 1.0 = nessuna pressione temporale; 2.0 = scadenza entro 24h; 0.5 = cronico, nessuna urgenza. Moltiplicatore, non additivo.
• confidence ∈ [0, 1]: quanto Metnos è sicuro della propria stima. Proposte basate su pochi dati o ragionamento speculativo → confidence bassa.
• bother_cost ∈ [0, ∞): vedi cap. 6.

La formula corrente (2 · top + 0.5 · rest) garantisce che uno specialista perfetto su un telos pesante batta un tuttofare medio. Il Giudice teleologico (LLM Qwen 3.6 35B-A3B locale) discrimina per-telos con distribuzione bimodale; il α boost espande la dinamica del termine dominante e γ valorizza le proposte multi-telos.

Come si stimano i fit_i

Non da contatori hardcoded. Vengono stimati da un LLM con spiegazione testuale. La stima è delegata al Vaglio — fase 2 (Giudice teleologico), per una ragione strutturale: un LLM tende a valutare in modo conforme i propri output (self-enhancement bias documentato, Zheng et al. 2023). Il Giudice del Vaglio gira su contesto separato dal proponente, prompt separato, possibilmente provider separato. La AlignmentEngine di questo doc non fa la stima: compone lo scalare finale con i fit che il Vaglio le consegna.

Allineamento ≠ punteggio R

Threshold di pubblicazione e dashboard di triage

Le proposte vengono ordinate per expected_alignment e sottoposte all'utente via dashboard /admin/proposals/telos (wired). Per ogni proposta la UI mostra:

• Origine: lens (es. scamper, endgame_book), telos generante, operator, n_observed estratto dal rationale (es. "co-attivati 49 volte").
• Proposta: target executor, proposed_action, rationale + breakdown alignment_per_telos con fit e spiegazione per ciascun telos.
• Esempio applicabile: chip pipeline osservata (la combinazione esiste nel turn log reale), match parziale (solo il target appare), speculativa (nessun esempio negli ultimi 14 giorni). Se trovata, una query utente reale + path attuale → path suggerito.
• Impatto: stima latenza risparmiata (mediana per-step ~5.5s × step ridotti).
• Azioni: pulsanti accept, reject, stage (in attesa, non terminale).

Le decisioni sono persistite in ~/.local/share/metnos/telos_decisions.jsonl (append-only, LWW per prop_id = timestamp). Lo stato «stage» non è terminale: la proposta resta nella lista pending finché non è accept/reject. Le proposte scartate silenziosamente (sotto soglia) finiscono in un journal interno ispezionabile:

// workspace/.audit/telos_rejected.jsonl
{"proposal_id": "ap_...", "kind": "homogenize_filenames",
 "expected_alignment": 0.08, "breakdown": {...},
 "reason": "bother_cost troppo alto (4 proposte già oggi)",
 "at": "2026-04-25T19:42:00Z"}

Default θ per la dashboard: 0.30 (quartile basso, override via query param min_alignment). Cutoff empirici su 481 proposte: > 0.50 = 3 proposte top (0.6%); > 0.45 = 23 (5%, soglia review); > 0.40 = 88 (18%, top decile).

5. La clausola anti-rinuncia e la clausola di stop

La semantica anti-rinuncia (esaurire la cascata synt prima di rispondere «non posso») è attiva nel runtime come policy deterministica, non come telos pesato. Garantisce che il sistema tenti la cascata (comporre, generare, fondere) prima di emettere un fallimento.

5.1 La clausola di stop

Senza la clausola di stop, il telos sarebbe paternalismo: «tu mi hai chiesto X, io insisto a cercarlo anche se tu non vuoi più». Lo stop rende la non-rinuncia coraggio e non testardaggine (per usare le parole della microprogettazione di synt). Lo stop è sempre udibile: l'LLM che gestisce il turno ha nel prompt un riconoscitore esplicito di formule di interruzione.

5.2 Soglie di abbandono

Il telos di non-rinuncia non significa retry illimitato. Le soglie di abbandono restano valide e sono fissate in synt (cap. 8.3):

• max 3 retry per stadio della pipeline di generazione;
• lock di 24 h sullo stesso target_intent dopo un abbandono motivato;
• lock di 30 giorni sulla stessa direzione dopo un rifiuto utente di una proposta introvertiva;
• budget hard 5 € per richiesta, 20 €/giorno costituzionale.

Esaurita la cascata entro queste soglie, il fallimento è lecito. Il telos di non-rinuncia non chiede di superarle: chiede di non fermarsi prima.

6. Bother budget e invocazioni programmate

L'utente ha una capacità finita di valutare proposte. Più ne arrivano in una finestra, meno attenzione dà a ciascuna. Per questo, la funzione di allineamento include bother_cost che cresce con la frequenza recente di proposte pubblicate. La novità di è la separazione fra proposte ad-hoc e invocazioni programmate dello scheduler (il builtin descritto in executor.html cap. 10).

6.1 Modello base (proposte ad-hoc)

Dove k(Δt) è un kernel esponenziale decrescente: una proposta pubblicata 1 minuto fa contribuisce molto, una di 8 ore fa quasi nulla.

6.2 Invocazioni programmate dallo scheduler

Quando una proposta viene accettata insieme a un ritmo (per esempio «ok, fammi questo riassunto ogni mattina alle 8»), il consenso copre l'intero ritmo, non solo la prima esecuzione. Da quel momento in poi le invocazioni successive non sono nuove proposte spontanee: sono firing dello scheduler builtin, già pre-approvati. Il bother budget delle ad-hoc non si applica.

6.3 Budget giornaliero default

7. Apprendimento dai silenzi

Tre tipi di feedback aggiornano i pesi effettivi dei telos — non i pesi dichiarati in TELOS.md, che restano la ground truth revisionabile dall'utente. Il TrustStore si estende con un asse telos_fitness: dict[telos_id, EMA].

Il peso effettivo oscilla fra il 50% e il 150% del dichiarato. Non lo annulla mai (per evitare oblio catastrofico di un telos), non lo raddoppia mai (per rispettare l'intenzione dell'utente).

8. Anti-paternalismo e clausola di stop

Questa è la trappola più insidiosa del design. Un sistema di telos applicato senza discernimento diventa paternalista. Senza la distinzione che segue, il telos di non-rinuncia di cap. 5 sarebbe la manifestazione più estrema di questo rischio.

Operativamente, la funzione di allineamento non si applica mai a:

• Comportamenti osservati dell'utente nel workspace (tempo speso, pattern, acquisti, scelte).
• Ritrattamenti di scelte passate dell'utente.
• Richieste esplicite dell'utente quando il pool sa già soddisfarle: in quel caso si esegue, basta.

Si applica a:

• ActionProposal spontanee generate da reflection, ager, mnestoma.
• Scelte interne di Metnos (tier LLM, parallelismo, retry) dove il telos guida il trade-off.
• Comportamento di synt nella cascata, finché il telos di non-rinuncia è attivo.

Questa clausola va riflessa anche nella constitution come sotto-legge: la Costituzione è il livello che impedisce i casi limite (es. tentativi di sintesi che richiederebbero capability forbidden).

8.1 Riconoscimento dello stop

Lo stop dell'utente non è solo «lascia perdere». La pipeline LLM ha nel prompt un riconoscitore di formule equivalenti, in italiano e inglese:

• «lascia perdere», «non importa», «ho cambiato idea», «basta così», «non insistere», «non serve più»
• «never mind», «forget it», «don't bother», «stop», «leave it»
• una richiesta esplicita di abbandono che cita il task corrente

Lo stop ambiguo (es. «hmm, vediamo dopo») attiva una conferma esplicita: «vuoi che mi fermi sul tentativo X?». Meglio chiedere una volta in più che testardare un tentativo non voluto.

9. Contratto Python

from typing import Protocol, Literal
from dataclasses import dataclass
from datetime import datetime
from uuid import UUID

@dataclass(frozen=True)
class Telos:
 id: str # "t.tempo"
 phrase: str # "Liberare il mio tempo dalle incombenze ripetitive"
 weight_declared: float # [0,1], somma normalizzata
 activation_threshold: float # [0,1]
 notes: str # contesto per l'LLM
 is_non_retreat: bool = False # reserved, currently unused

@dataclass(frozen=True)
class FitEstimate:
 telos_id: str
 fit: float # [0,1]
 why: str # spiegazione testuale (per audit)

@dataclass(frozen=True)
class AlignmentResult:
 proposal_id: UUID
 expected_alignment: float
 per_telos: list[FitEstimate]
 urgency: float
 confidence: float
 bother_cost: float
 decision: Literal["publish", "reject", "defer_to_digest"]
 threshold_used: float
 at: datetime

@dataclass(frozen=True)
class StopSignal:
 """Emesso quando l'utente attiva la clausola di stop."""
 request_id: str # request_id di synt da fermare
 target_intent: str # cosa fermare
 raw_phrase: str # parole esatte dell'utente (audit)
 at: datetime

class TelosStore(Protocol):
 """Legge TELOS.md ed espone i telos correnti."""
 def current(self) -> list[Telos]:...
 def get(self, telos_id: str) -> Telos | None:...
 def version(self) -> str:... # hash corrente

class AlignmentEngine(Protocol):
 async def evaluate(
 self,
 proposal: "ActionProposal",
 urgency_hint: float = 1.0,
 ) -> AlignmentResult:
 """Stima fit per telos (Vaglio), compone expected_alignment,
 applica bother_cost, decide publish/reject/defer."""...

class BotherBudget(Protocol):
 def current_cost_adhoc(self, channel: str, at: datetime) -> float:...
 def routine_quota_left(self, channel: str, routine_id: str) -> int:...
 def record_published_adhoc(self, channel: str, proposal_id: UUID) -> None:...
 def record_routine(self, channel: str, routine_id: str) -> None:...
 def in_protected_window(self, at: datetime) -> bool:...

class StopRecognizer(Protocol):
 """Riconosce la clausola di stop nelle parole dell'utente."""
 async def detect(self, user_text: str, current_intent: str | None) -> StopSignal | None:
 """Ritorna StopSignal se la frase è uno stop chiaro;
 None se non lo è; pone una conferma se ambiguo."""...

class TelosFeedback(Protocol):
 """Aggiorna gli EMA per-telos dai segnali dell'utente."""
 async def on_accept(self, proposal_id: UUID) -> None:...
 async def on_accept_with_edit(self, proposal_id: UUID) -> None:...
 async def on_reject(self, proposal_id: UUID, never_again: bool) -> None:...
 async def on_stop(self, signal: StopSignal) -> None:...
 async def on_silence_48h(self, proposal_id: UUID) -> None:...
 async def on_viewed_undecided(self, proposal_id: UUID) -> None:...

# Errori
class TelosFileMalformed(Exception):...
class TelosSignatureInvalid(Exception):...
class TelosFitEstimationFailed(Exception):...
class StopAmbiguousNeedsConfirm(Exception):...

10. Rito di revisione

TELOS.md non è tecnicamente costituzionale (le Leggi sì) ma merita comunque un rito leggero:

1. Scrittura manuale: l'utente modifica TELOS.md con un editor.
2. Validazione: Metnos rilegge, ri-verifica formato, normalizza i pesi.
3. Recap: Metnos risponde con un confronto «ecco cosa cambia rispetto alla versione precedente: peso parsimonia +0.05, aggiunto t.convivialita, ecc.».
4. Firma: HMAC-SHA256 con chiave dedicata (distinta da quella costituzionale).
5. Versione: il nuovo file include previous_hash del precedente; il vecchio finisce in .audit/telos/. Merkle leggera.
6. Reset soft dell'EMA: i telos rinominati o rimossi perdono il loro EMA; i nuovi partono da 0. I telos con solo cambio di peso conservano l'EMA.

11. Alternative considerate

12. Test di conformità

13. Domande aperte

1. Stop «ricorrente». Se l'utente ferma N volte di fila lo stesso pattern, il sistema dovrebbe disabilitare la clausola anti-rinuncia per quel filone? Oppure restare al rifiuto puntuale? Aperta; default conservativo: rifiuto puntuale.
2. Soglie di scheduling. Quando le schedule attive in un canale diventano «troppe»? Default tentativo: max 2/giorno per canale, max 1 schedule viva contemporaneamente per stesso topic. Da calibrare.
3. Telos legati a effect_class. Un telos può bloccare un'intera classe di effetto, non solo singole proposte. Il meccanismo della telos_neverlist oggi opera sull'effect_class; possibile estensione futura: legare effect_class a più telos contemporaneamente. Aperta.
4. Multi-utente. Quando Metnos avrà più sender pairati, i telos sono per-utente, condivisi, o un misto? Probabilmente per-utente con un set condiviso minimo (sicurezza, perimetro). Da decidere.

14. Le 10 lenti laterali

Le lenti laterali (runtime/telos_lenses/) sono i generatori creativi che producono proposte introspettive per servire i telos. Architettura modulare (cap. 9): ogni lente è un modulo Python con 3 elementi (NAME, OPERATORS tupla, funzione build_prompt(ctx, operator)) e si registra in __init__.py. Il loop LLM + parse JSON + paternalism guard + GBNF wiring è centralizzato in _base.run_lens. Toggle individuale per lente: METNOS_TELOS_LENS_<NAME>=1.

Stato al v8: 10 lenti in produzione ( final). Le 2 nuove dell'iterazione corrente (counterfactual, constitutional) sono ispirate a referenze 2022–2023. La lens compression (Schmidhuber 2010) e' stata implementata ma scartata dopo bench v8 per fallimento convergenza: anche col prompt restretto il modello locale non riusciva a proporre super-verbi vocab-compliant (violava l'eccezione §2.2 su entries). Bench convergenza con Qwen 3.6 35B-A3B + GBNF: 10/10 lenti accettate convergono al primo tentativo, 0 paternalismo, 0 invalid naming, 0 qualifier-object mismatch.

Le 11 lenti sono tutte LLM-driven al loro core (creatività richiesta) ma il GATING delle proposte e' deterministico (§7.9): anti-paternalismo via regex, naming compliance via Naming Authority (cap. 9), qualifier-object compatibility (R4) via mappa in vocab.py. Una proposta che viola un vincolo del Naming Authority NON puo' essere emessa: la grammar GBNF la blocca a tempo di generazione.

Catalogo & routine notturna

Tutte le lenti partecipano al loop notturno (scheduler v2 daily@03:30, integrazione pending) e producono proposte che vanno al Vaglio. Lenti che propongono CONCETTI (telos, vincoli, pattern astratti) hanno new_op_name=null: oulipo, inverse_rl, pattern_language. Lenti naming-aware (le restanti 8) possono proporre nuovi nomi 2-4 livelli (R0..R4).

15. Riferimenti

Riferimenti interni

• Architettura, cap. 11 — il quadro d'insieme di telos+vaglio.
• Architettura, cap. 7 — la variante proattiva e l'esempio canonico «presidiare una casella di posta» (catena invocata dallo scheduler builtin).
• synt.html — la cascata che il telos di non-rinuncia onora; punteggio R distinto da expected_alignment.
• executor.html — gli artefatti che synt produce e che i telos valutano nel canale di pubblicazione.
• mnest.html — i proto-mnest che innescano il telos di non-rinuncia.
• vaglio.html (da riscrivere) — il giudice teleologico che stima i fit.
• constitution — le 4 Leggi; il telos di non-rinuncia è una spinta positiva, NON una Legge.

Riferimenti letterari e tecnici

• Aristotele, Etica Nicomachea (τελος) — fini come cause finali, non obiettivi operativi.
• Constitutional AI, Anthropic 2022 — hierarchical constraints; i telos sono il lato positivo di quello che la Constitutional AI fa con le regole.
• Goodhart's Law — «quando una misura diventa obiettivo, smette di essere una buona misura». Trattato come contromisura esplicita in cap. 8 e cap. 11.
• Zheng et al. 2023 — self-enhancement bias dell'LLM-as-Judge: motivo dell'indipendenza del Vaglio dal proponente.
• Asimov — la formulazione «non lasciare inattuata una richiesta» eco la Legge 2 (obbedienza informata) ma vive nei telos perché è una tendenza, non un vincolo binario.

Continua a leggere

Metnos — telos microprogettazione
Senza telos, la proattività è rumore.