A telos is a broad end declared by the user in workspace/TELOS.md. Metnos treats it as a graded signal: it may prefer a strategy or rank a proposal, but it cannot derive new permissions from it, override policy, or arbitrarily block an explicit request.

1. What TELOS.md contains

The loader recognizes between three and seven sections. The descriptive text may be written in any language, while 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.

The file is reloaded when it changes. If it is missing or has no valid sections, the runtime proceeds without the teleological signal. Parsing is deterministic; no language model invents or edits the declared ends.

2. Where telos takes effect

Telos has two separate uses:

1. Planning context. The runtime can render the current ends into planner context. Its instructions define them as soft signals: they help choose among alternatives with comparable outcomes and do not replace policy, capabilities, or the user's request.
2. Optional proposal generation. An offline job can examine the catalog, usage patterns, and declared ends to formulate possible improvements. Its result is a proposal, not an already-authorized action.

Neither path gives authority to the text in TELOS.md. A direct request remains subject to normal execution rules, while a spontaneous proposal must pass through its review lifecycle.

3. How a proposal is created

The telos_introspect_nightly job is disabled by default. It runs only when the operator enables METNOS_TELOS_NIGHTLY=1. In that mode it applies ten registered lenses to the current telos entries:

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

The lenses use a local model for their generative work. Deterministic rules wrap that probabilistic step: lens selection, anti-paternalism checks, name validation, proposal limits, target–lens deduplication, and local persistence.

Raw proposals are recorded in ~/.local/share/metnos/telos_proposals.jsonl. The store clusters proposals that target the same outcome and measures convergence across distinct lenses. Only cluster heads with an actionable naming result are converted into a change_intent.

4. Scoring and controls

For each proposal, the teleological judge estimates a fit value for every telos. A language model produces that estimate; code applies weights, thresholds, composition, and ordering. The resulting score supports triage but is not objective proof that the proposal is good.

5. Decision and lifecycle

The telos adapter translates a cluster head into a supported kind, such as creating an executor, extending one parametrically, or running a controlled pipeline. The materializer stores it in the unified repository as proposed.

The user reviews it at /admin/changes and can accept, reject, or stage it. Only an accepted proposal reaches the applier. After application, the change is observed and can be finalized or rolled back according to its kind. The change lifecycle page describes the complete flow.

6. Practical example

Ask Metnos with a request like this example: “Which system changes are waiting for my decision?”

Metnos can explain that proposals are administered in the web chat. If the question starts on Telegram, open the web chat, go to the administration area, and choose Changes; the technical route is /admin/changes. A telos proposal remains separate from the preferences written in TELOS.md: accepting it authorizes that change, not every future action that may look consistent with the same end.

7. Current limits and references

• The disturbance cost supported by the alignment formula is passed as 0 by the current introspection flow: there is no operational interruption budget yet.
• The system does not infer new telos entries or permissions from user silence.
• Model-generated prose and scores are not deterministic evidence; a decision must remain traceable to local data and the original proposal.
• The nightly job remains optional and disabled by default.

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