← Documentation index Architecture guide › Tutor

The integrated Tutor

verified knowledge, current state, and private learning

Ask Metnos with a request like this example: “What does the file Metnos_Extended_Perspectives_v1.html contain?”

Tutor answers questions about Metnos before the operational planner is involved. It composes the answer from admitted sources and may add current observations, but it owns no tools and performs no actions.

question → explanation/action distinction → authorized sources → optional current observation → answer

1. How it recognizes a product question

The first step distinguishes an explanation, a real observation, a state-changing action, a mixed request, or an intent that is not clear enough. An explanation may enter Tutor. An observation enters only when one registered view covers all the requested data; otherwise it continues through the normal Metnos engine.

Grammar alone is not enough. “Show me the Services page” asks for an explanation of an interface surface; “show me the files in my folder” asks for real data. The target of the request, not the verb by itself, determines the route.

The signal for a documentation source

When a question contains the exact name, relative path, or canonical URL of a page in the public inventory, the runtime recognizes that source identity before classification. This is not a similarity search: it is a case-insensitive match against the published catalog.

RequestOutcome
“What does Metnos_Extended_Perspectives_v1.html contain?”Tutor binds retrieval to that document and summarizes its contents.
“Summarize docs/en/Metnos_QuickTour.html.”The path identifies a published source; the answer cites sections from that page only.
“Delete Metnos_Extended_Perspectives_v1.html.”The name is recognized, but the intent is operational, so Tutor does not take the request from the engine.
“What does private_notes.html contain?”The name is not part of the published documentation and remains a normal file request.

If translations share the same filename, the current language resolves the match. If the identity remains ambiguous, the check stops without guessing. An explicit path outside the publication, such as /tmp/name.html or C:\Users\...\name.html, remains a user path and is not reduced to its basename. The word “file” by itself is not a documentation signal.

2. Which sources support an answer

Tutor's catalog is compiled and signed locally. It includes:

It does not include personal files, messages, calendars, conversations, execution logs, roadmaps, or internal development notes. Authorization is applied before text reaches the model. A source that is not visible to the person asking cannot contribute to the answer.

Long documents are split into sections. Semantic matching selects the relevant sections; when a document identity has been recognized, similarity only ranks sections within that same source. The model composes the final prose, but it cannot introduce capabilities, permissions, or facts that the sources do not attest.

Manifests also have structure. The complete executor contract describes the operation, while individual arguments refine its parameters and limits. If a generic field is close to the request but a complete contract lies in the same relevance band, that contract becomes the primary source. Its argument descriptions remain supporting evidence. This rule follows source hierarchy; it does not contain lists of requests, special words, or domain-specific exceptions.

3. When current state is needed

Some questions ask not only what a page is meant to show, but what it is showing now. A signed source may then refer to a registered, read-only runtime probe. The model does not choose the probe and cannot invent its arguments.

Topical proximity is not enough. The runtime first proposes a view, then independently verifies that this view alone covers every requested fact, and finally compares it semantically with all other visible views. It must be the primary match with a sufficient margin. If any check fails, Tutor steps aside and the request reaches the ordinary read executor. For example, “Check whether the Metnos mailbox has mail” uses the mailbox; it is not answered with service status.

The checks that grant Tutor authority share a short admission window. Once a view has been admitted, its read-only probe and composition use the full turn deadline. If Tutor's optional pre-gate is busy, or the view or composer does not produce a valid result, the request continues through the ordinary engine: optional help does not become an HTTP error and does not take the turn away from the planner.

For a newly added language, a view may temporarily use its English contract as fallback evidence. The composer still receives the user's current language, so the evidence language does not determine the answer language.

ObservationScopeProtection
admitted executors, lifecycle, and origininstance administratorno rejected paths or details
service healthinstance administratorno endpoints, PIDs, or unit names exposed to the model
scheduler health and causeinstance administratorloop state and bounded diagnosis; no task text or run output
registered devices and reachabilitydevices owned by the user onlykeys, fingerprints, and profiles remain excluded
scheduled tasks and recent runsauthenticated actor onlyrequest text and run output remain excluded

Every observation states its time, expiry, source version, and a status among ok, partial, stale, and unavailable. Size, wait time, and retention are bounded. Expired or incomplete data is reported as such and never silently presented as healthy.

Scheduler v2 lives inside the HTTP process; it is not a separate systemd service. Its probe observes the loop directly and distinguishes running, degraded, failed, and stopped. One failed job does not make the scheduler inactive, just as a period with no executions does not prove that the engine is down. If a question starts from an incorrect failure premise, Tutor corrects it; it states a cause only when the current observation attests that cause.

Ask Metnos with a request like this example: “Which services are running, and what are they for?”

Ask Metnos with a request like this example: “Why is the scheduler down?”

4. Explanation and action in one request

A request may contain an informational part and an operational part: “Explain the Services page, then find README.md.” If the two clauses can be separated without rewriting them, Tutor:

  1. answers the informational part;
  2. retains the action clause exactly as the user wrote it;
  3. asks whether to hand it to the ordinary Metnos engine;
  4. hands it over only after confirmation.

The confirmation is bound to the user, conversation, catalog version, and an expiry time. It can be used once. If system knowledge changes, data no longer match, or the confirmation has already been consumed, no operation starts. After confirmation, the same controls as any new turn still apply: planning, Vaglio, autonomy, consent, and executors.

An existing dialog is never replaced. If clause separation is not safe, Metnos asks the user to state the explanation and action separately.

Ask Metnos with a request like this example: “How do I archive email? Also archive yesterday's messages.”

Tutor explains the operation attested by the move_messages manifest, retains “Also archive yesterday's messages” without rewriting it, and asks for consent. Only after confirmation does the clause reach the ordinary engine, where context, planning, autonomy, and consent checks still apply. The answer remains limited to procedures attested by its sources.

5. How user feedback is used

The feedback controls in the chat can improve retrieval for that same person. Positive feedback associates the request representation with the primary source that was actually served. Negative feedback removes any such association and records a typed gap.

This learning has narrow boundaries:

Gaps are grouped by cause and semantic neighborhood without reconstructing the original wording. A counterfactual check verifies that retained associations still point to present, unchanged sources. Tutor never publishes new documentation by itself and never turns its own generated prose into evidence.

6. Language and channel

Retrieval prefers the current language for each concept and falls back to English when a translation is missing. Response language is explicit; it is not chosen by the language of a source or of the model instruction.

The same questions may be asked in the web chat or through Telegram. When an answer names a Settings page, that path belongs to the instance's web chat. Telegram can show its instructions and link, but it does not embed the administrative interface.

7. Updates and failure behavior

Any admitted-source change alters the input stamp. The compiler builds a complete candidate, verifies its schema, vectors, and signature, and atomically replaces the current catalog. Vectors for unchanged units may be reused, but a partial catalog is never admitted.

If retrieval finds no admissible source at all, Tutor does not answer and leaves the request to the ordinary engine. The only thing established in that case is that a classifier read the question as explanatory, and closing the turn on that reading alone would hide what the engine can do behind a guess. If sources are present but insufficient to compose an answer, Tutor reports a knowledge gap: that is a hole in the corpus, not a misread question. If the catalog, representation, or composition subsystem fails, it reports technical unavailability. In none of these cases is an informational question accidentally turned into an action.

8. Technical references