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 v1.1 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 (cfr. workspace.html, da riscrivere). Formato markdown con front-matter YAML. Poche righe, scritte a mano dall'utente.

---
telos_version: 1.1
written_at: 2026-04-25T12:00:00+02:00
written_by: roberto
previous_hash: <sha256 della versione precedente, o "genesis">
signature: <HMAC-SHA256, chiave separata dalla costituzionale>
---

# I miei fini ultimi

## t.tempo — Liberare il mio tempo dalle incombenze ripetitive
peso: 0.22
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.13
soglia_attivazione: 0.40
note: preferisco piccoli riassetti incrementali ai grandi riordini.

## t.puntualita — Non farmi perdere scadenze importanti
peso: 0.18
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.18
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.09
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.08
soglia_attivazione: 0.35
note: scegli sempre l'opzione più economica che raggiunge la qualità
      necessaria.

## t.coltivazione_strumenti — Non lasciare inattuata una mia richiesta, se possibile
peso: 0.12
soglia_attivazione: 0.10
note: se ti chiedo qualcosa che il tuo pool non sa ancora fare, esaurisci
      le strategie di sintesi (comporre, generare, chiedere) prima di
      rispondere "non posso". Il fallimento è lecito; la rinuncia
      silenziosa no. Vedi cap. 5 per la clausola di stop.

Campi obbligatori per telos

4. La funzione di allineamento

Formula

Con:

• 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.

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

Se expected_alignment < θ, la proposta non viene mostrata all'utente. θ è un parametro di config.html (da riscrivere) con default 0.15. Le proposte scartate 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"}

L'utente può ispezionare questo journal per verificare che Metnos non stia sopprimendo cose buone («digest settimanale: 47 proposte scartate, ecco le 5 al margine»).

5. Il telos di non-rinuncia

t.coltivazione_strumenti è il telos più nuovo (introdotto il 25 aprile 2026) e quello che cambia di più il significato di «non si applica alle richieste esplicite». Lo facciamo vivere a parte perché meccanicamente si comporta in modo diverso dagli altri.

5.1 Il problema che risolve

Senza questo telos, il design originale aveva un buco: di fronte a una richiesta utente che il pool non sapeva soddisfare, il sistema poteva rispondere «non posso» senza tentare strategie alternative. Il fallimento era lecito, ma era una rinuncia silenziosa: niente tracciava il tentativo, niente cresceva nel pool, l'utente perdeva fiducia. La risposta corretta è un telos esplicito che spinge synt a esaurire la cascata (comporre, generare; nei tempi più lunghi: fondere, generalizzare) prima di rispondere «non posso».

5.2 Differenza con gli altri telos

5.3 La distinzione fallimento vs rinuncia

Il telos non chiede di soddisfare ogni richiesta, chiede di non rinunciare in silenzio. Sono due cose diverse.

5.4 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.5 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 v1.1 è 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 definito in rl_offline.html (da riscrivere) 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 in constitution.html (da riscrivere) 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.coltivazione_strumenti"
    phrase: str                   # "Non lasciare inattuata una mia richiesta, se possibile"
    weight_declared: float        # [0,1], somma normalizzata
    activation_threshold: float   # [0,1]
    notes: str                    # contesto per l'LLM
    is_non_retreat: bool = False  # solo t.coltivazione_strumenti

@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. Quanti telos di non-rinuncia. Oggi uno solo (t.coltivazione_strumenti). Ne servirà mai un altro? Per esempio, «non lasciare inattuata una segnalazione di sicurezza»? Aperta.
2. Stop «ricorrente». Se l'utente ferma N volte di fila lo stesso pattern, il sistema dovrebbe abbassare il peso di t.coltivazione_strumenti sotto la soglia di attivazione e di fatto disabilitare il telos? Oppure restare al rifiuto puntuale? Aperta; default conservativo: rifiuto puntuale.
3. 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.
4. 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.
5. 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. Riferimenti

Riferimenti interni

• Architettura v1.1, cap. 11 — il quadro d'insieme di telos+vaglio.
• Architettura v1.1, cap. 7 — la variante proattiva e l'esempio canonico «presidiare una casella di posta» (catena invocata dallo scheduler builtin).
• synt.html v1.1 — la cascata che il telos di non-rinuncia onora; punteggio R distinto da expected_alignment.
• executor.html v1.1 — gli artefatti che synt produce e che i telos valutano nel canale di pubblicazione.
• mnest.html v1.1 — i proto-mnest che innescano il telos di non-rinuncia.
• vaglio.html (da riscrivere) — il giudice teleologico che stima i fit.
• constitution.html (da riscrivere) — 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 v1.1 — 2026-04-25
Riscrittura. Sostituisce telos v1.0 (myclaw, neuroni, sinapsi). Senza telos, la proattività è rumore.