1. Purpose and method

This page provides a stable method for assessing a Metnos capability. It does not recount the order in which components were designed, and it does not replace their technical contracts.

The first question is not “is the feature interesting?” but “does it produce a useful result, with understandable sources and boundaries, in the right user's context?” Assessment combines observable behaviour, tests, traceability and interaction quality. Persuasive prose or a polished answer is not evidence by itself.

2. Four qualities that should not be confused

The four qualities can diverge. A flow may be autonomous but useless, intelligent but unauthorised, or useful precisely because it stops and asks for confirmation.

3. Assessment perspectives

4. How to state a judgement

A useful judgement states the decision, its evidence and its consequence. The following categories avoid vague conclusions such as “needs improvement”.

Every outcome must cite inspectable evidence: tests, audit events, an original source, persisted state or behaviour reproducible under stated conditions. Language-model prose does not become evidence merely because it was stored.

5. Seven non-negotiable conditions

1. Identity and authorisation. Every request, session, credential and datum belongs to an authenticated user. A guest or a different user cannot inspect the owner's profile, sources or services.
2. Executor contracts. Arguments, types, effects, errors and reversibility must be declared and validated before execution.
3. Separation of content and control. The web, documents, tool output and model text cannot modify policy, privileges or system instructions.
4. Understandable consent. Approval shows the action, recipient, account, device and relevant consequences; it does not hide effects behind technical labels.
5. Traceability and recovery. The served plan, approvals, outcomes and errors must be correlatable without exposing secrets or duplicating effects after a restart.
6. Original sources for personal data. Preferences and observations cite the authorised turn or datum from which they derive. One model-generated summary cannot cite another as proof.
7. Representative evaluation. Tests cover languages, channels, users, failures and real capabilities, not only one developer's ideal path.

6. Tensions that do not disappear

Personalisation and reproducible routing

A profile can improve tone, examples and the final answer's form, but it must not be injected into a planner governed by shared caches. If it is absent from the cache key, cache hits ignore it; if it enters the key, a shared plan cache becomes per-user and loses hit rate and reproducibility. Sound options are to apply the profile during final generation or to rewrite the request explicitly before the cache, with a coherent signature.

Autonomy and control

Reducing confirmations makes a flow faster but increases the risk of unexpected effects. A global “trust level” is not a solution: authority must be bounded by operation, source, duration, account and user.

Usefulness and privacy

More sources may improve an answer while creating an excessive personal dossier. Sensitive directories, medical or financial data and secrets require default exclusion or specific consent. Technical readability does not authorise their conversion into profile data.

Fluency and transparency

A natural answer must not hide which service was used, which datum was found or which operation failed. Transparency should be made readable, not removed.

7. Autonomy and proactivity belong to the mandate

Metnos is not autonomous or proactive in the abstract. It is so with respect to a specific assignment: “check my calendar every Monday”, “notify me if a message arrives from this sender”, or “continue until you have found three official sources”. The mandate defines:

• the user and delivery channel;
• the triggering event or recurrence;
• permitted sources and accounts;
• allowed operations and approval points;
• cost, retry and expiry limits;
• revocation and failure behaviour.

Outside those boundaries, Metnos must stop, request a new mandate or make a proposal. It cannot enlarge the assignment by relying on an inferred preference.

7-bis. The proactive lens

Before introducing a new trigger or automatic proposal, verify in order:

1. Signal: which observable event activates it?
2. Relevance: why does that signal concern this user and this mandate?
3. Source: is access to the source authorised and necessary?
4. Action: does the system propose, notify or execute?
5. Consent: where does approval occur?
6. Limit: when does it expire or pause?
7. Reconciliation: how does it handle new data that contradicts earlier observations?
8. Verification: which event or test proves the behaviour is correct?

If any question has no answer, the capability is not ready to be presented as available.

8. Using the judgement in practice

For a change or new capability, the review result should be readable in this form:

The relevant current specifications are agent runtime, executors, approval, observability, users and sessions, telos and vaglio.

Metnos — Perspectives and judgement
Current criteria for assessing capabilities, boundaries and interaction quality.