1. Scopo e confini

Un agente reattivo ha una funzione di valutazione implicita: "l'utente ha chiesto X → fai X bene". Un agente proattivo no: è lui che genera l'intenzione. telos è il componente che stabilisce quale intenzione ha senso prima che diventi una proposta all'utente, senza chiedere all'utente di valutare tutto.

Cos'è

• 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: il costo di disturbare l'utente cresce con la frequenza recente di proposte.
• Un meccanismo di apprendimento dai silenzi (non solo dai no) che aggiorna i pesi dei telos.

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 (precedenza della Costituzione).
• Non è un giudice dell'utente. I telos valutano ciò che myc sta per fare per l'utente, non ciò che l'utente fa. Se telos dice "parsimonia", myc non commenta se l'utente compra una bottiglia costosa: commenta se myc stesso stava per spendere molto in API.
• Non è un ottimizzatore. I telos sono fini aristotelici (asintotici), non obiettivi SMART. Non si raggiungono: ci si avvicina.
• Non si applica alle richieste esplicite dell'utente. Se l'utente chiede "fai X", myc fa X (con Policy + approvazione), anche se X non aiuta nessun telos. I telos filtrano solo le proposte spontanee di myc.

2. Il concetto: leggi vs telos

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

In termini operativi:

3. TELOS.md — il file

Vive nel workspace come sesto file canonico (cfr. workspace.html, da estendere). Formato markdown con front-matter YAML. Poche righe.

---
telos_version: 1.0
written_at: 2026-04-22T18:00:00+02:00
written_by: roberto
previous_hash: genesis
signature: <HMAC-SHA256, chiave separata dalla costituzionale>
---

# I miei fini ultimi

## t.tempo — Liberare il mio tempo dalle incombenze ripetitive
peso: 0.25
soglia_attivazione: 0.3
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.4
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.2
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.5
note: non farmi notifiche 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:

• 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 — l'urgenza amplifica, non sostituisce.
• confidence ∈ [0, 1]: quanto myc è sicuro della propria stima di fit. Proposte basate su pochi dati o ragionamento speculativo → confidence bassa.
• bother_cost ∈ [0, ∞): vedi §5.

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

Il prompt del Giudice (definito in vaglio §5) è un system-block cacheabile:

Sei il valutatore di allineamento ai telos dell'utente.

TELOS DELL'UTENTE:
{body of TELOS.md, note incluse}

PROPOSTA DA VALUTARE:
{kind: "homogenize_filenames", scope: "~/Documenti/lavoro/",
 impact: "347 file, 2h risparmio stimato/mese",
 rationale: "4 convenzioni diverse rilevate nello scan",
 plan: [...],
 reversibility: "reversible"}

Per ogni telos, stima fit ∈ [0,1] e spiega in una frase perché.
Stima anche confidence ∈ [0,1] (quanto sei sicuro della tua stima,
considerando dati disponibili vs speculazione).
Rispondi in JSON:
  {"t.tempo": {"fit": 0.6, "why": "..."},
   "t.ordine": {"fit": 0.85, "why": "..."},
   ...
   "confidence": 0.7,
   "overall_why": "..."}

Il tier LLM usato è local-fast per proposte a basso costo, con escalation a frontier se la proposta è grossa (impact > 100 record o effect_class irreversibile). Coordinato con policy §6 cost tiering.

Threshold di pubblicazione

Se expected_alignment < θ, la proposta non viene mostrata all'utente. θ è un parametro di config con default 0.15.

Le proposte scartate finiscono in un journal interno:

// 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-22T19:42:00Z"}

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

5. Bother budget — il costo di disturbare

L'utente ha una capacità finita di valutare proposte. Più proposte gli arrivano in una finestra, meno attenzione dà a ciascuna. Dopo N proposte ignorate, inizia a ignorare il canale.

Per questo, la funzione di allineamento include bother_cost che cresce con la frequenza recente di proposte pubblicate.

Modello

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

Budget giornaliero default

6. 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). Il TrustStore definito in rl_offline si estende con un asse telos_fitness: dict[telos_id, EMA].

Peso effettivo vs peso dichiarato

Il peso effettivo oscilla tra 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).

7. Anti-paternalismo: myc si giudica, non giudica

Questa è la trappola più insidiosa del design. Un sistema di telos applicato senza discernimento diventa paternalista: "il tuo telos è parsimonia, quindi ti dico che stai spendendo troppo". Non è quello che vogliamo.

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

• Azioni richieste esplicitamente dall'utente (anche se costose o disordinate).
• Comportamenti osservati dell'utente nel workspace (tempo speso, pattern, acquisti).
• Ritrattamenti di scelte passate dell'utente.

Si applica solo a:

• ActionProposal che myc genera spontaneamente (reflection, indexer, neuroni).
• Scelte interne di myc (tier, parallelismo, retry) dove il telos guida il trade-off.

Questa clausola va riflessa anche in constitution.html come sotto-legge (vedi Prospettive estese §4).

8. 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 da incombenze ripetitive"
    weight_declared: float        # [0,1], somma normalizzata
    activation_threshold: float   # [0,1]
    notes: str                    # contesto per l'LLM

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

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

class TelosStore(Protocol):
    """Legge TELOS.md e 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 (LLM), compone expected_alignment,
        applica bother_cost dal BotherBudget, decide publish/reject/defer.
        """
        ...

class BotherBudget(Protocol):
    def current_cost(self, channel: str, at: datetime) -> float: ...
    def record_published(self, channel: str, proposal_id: UUID) -> None: ...
    def in_protected_window(self, at: datetime) -> bool: ...

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_silence_48h(self, proposal_id: UUID) -> None: ...
    async def on_viewed_undecided(self, proposal_id: UUID) -> None: ...

Errori sollevabili

9. 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: myc rilegge, ri-verifica formato, normalizza i pesi.
3. Recap: myc 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.

10. Alternative considerate

11. Test di conformità

12. Provenienza e riferimenti

Riferimenti interni

• Prospettive estese §2F — introduzione al concetto, visione.
• memory §6 — reflection come produttrice di ActionProposal, da estendere.
• rl_offline — TrustStore da estendere con asse telos_fitness.
• constitution — clausola anti-paternalismo da aggiungere, distinzione Leggi/Telos da formalizzare.
• workspace — TELOS.md come sesto file del manifest.
• policy §6 — cost tiering per l'LLM che stima i fit.
• review di coerenza — a regime andrà rivista per includere telos come componente attraversato.

Riferimenti letterari

• 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 §7 e §10.
• Ikigai (生きがい) — il concetto giapponese di "ragione d'essere" fornisce un'intuizione del peso dei fini ultimi nella vita quotidiana, non solo professionale.

Continua a leggere

myclaw — telos v1.0 — 22 aprile 2026
Fondante per le famiglie proattive. Senza telos, la proattività è rumore.