A telos is a broad direction chosen by the user: save time, protect privacy, avoid missing a deadline. It helps Metnos prefer one solution over another and propose worthwhile improvements. It is not a command, a permission, or a target to pursue at any cost.

1. What a telos is

Metnos uses telos entries as soft preferences. When two strategies lead to comparable results, it may choose the one that better serves the declared ends. For example, if two ways of summarizing mail are equally reliable, it may favor the faster one when the user has placed greater weight on saving time.

The boundary is simple: a telos does not authorize an executor, override Vaglio, or turn a proposal into an action. Nor should it be used to arbitrarily refuse an explicit request. Permissions, policy, and confirmation continue to take precedence.

2. The TELOS.md file

Telos entries are written in workspace/TELOS.md. The convention recommends three to seven: few enough to represent real priorities. This range is an editorial rule, not a parser limit. Each section has this form. The prose may be in any language, but the current parser expects the field names peso, soglia_attivazione, and note:

## t.time — Free my time from repetitive chores
peso: 0.25
soglia_attivazione: 0.30
note: focus on repetitive activities whose result can be checked.

Metnos reloads the file when it changes. Parsing is deterministic: no language model invents or edits the declared ends. If the file is missing or contains no valid sections, the system continues without this signal.

3. How it guides a request

The runtime places the current telos entries in the planner's context, ordered by weight. The accompanying rules repeat their limited role: use them to choose between alternatives with similar outcomes, not to alter the meaning of the request.

This use is immediate but deliberately narrow. The planner sees each original phrase and its weight; it does not infer new ends from the user's behavior or turn silence into consent.

4. The nightly laboratory

Metnos also includes an experimental job that looks for possible improvements. It is disabled by default and starts only when the operator sets METNOS_TELOS_NIGHTLY=1. When enabled, telos_introspect_nightly applies ten different ways of looking at the same problem, called lenses:

• scamper, oulipo, and inverse_rl;
• endgame_book, analogy_transfer, and boden_transformational;
• pattern_language and generative_design;
• counterfactual and constitutional.

Generation uses the creative logical workload. The actual model, provider, and endpoint come from the central tier configuration. Code—not the model—selects the lenses, limits results, checks names, rejects paternalistic wording, and removes duplicates for the same target–lens pair.

A second logical workload, middle, estimates how each proposal helps or harms every telos. Code then applies the weights and thresholds: it emphasizes the strongest contribution, considers secondary ones, and penalizes conflicting effects. This score orders human review; it does not prove that an idea is good.

Raw proposals remain in the local store at ~/.local/share/metnos/telos_proposals.jsonl. Proposals aimed at the same result are grouped so that convergence across different lenses remains visible without pretending that repetition is new evidence.

5. From suggestion to decision

Only the representative of a group with an actionable result becomes a change_intent. Depending on the case, it may propose creating an executor, extending one, or trying an existing sequence. Its initial state is always proposed: nothing has changed at this point.

The administrator finds these proposals under Changes in the web chat, at /admin/changes, and may accept, reject, or stage them. Only an accepted proposal reaches the component that applies it. It is then observed and, where the change type allows, can be finalized or rolled back. The change lifecycle page describes every state.

Accepting one proposal authorizes that precise change. It does not authorize every future action that appears consistent with the same telos.

These controls remain active throughout the process:

6. Current limits

• The alignment formula includes a cost for disturbing the user, but the current flow still passes 0: there is no operational interruption budget yet.
• Model-generated text and scores are probabilistic judgments. Local data, the original proposal, and the decision must remain available for inspection.
• The nightly laboratory is optional and stays off until an operator enables it explicitly.

Implementation references:

• runtime/telos_loader.py: parsing, normalization, and reload of TELOS.md.
• runtime/telos_lenses/ and runtime/telos_introspect.py: generation and controls.
• runtime/alignment_engine.py: fit estimation and score composition.
• runtime/telos_proposals_store.py: persistence, clustering, and convergence.
• runtime/change_intent_adapters/telos.py and runtime/change_intents.py: entry into the lifecycle.