For example, you can ask Metnos: “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. It cannot freely choose executors and does not perform the actions requested by the user.
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.
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.
| Request | Outcome |
|---|---|
“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.
Tutor's catalog is compiled and signed inside the Metnos installation. The
compiler reads the local docs/ directory directly; it never
downloads pages from metnos.com, which is only a publication destination. The
catalog includes:
It does not include personal files, messages, calendars, conversations, execution logs, internal roadmaps, or development notes. Public, indexable roadmaps are documentation like any other page on the site. 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 argument entries refine its parameters and limits. When both are relevant, the complete contract comes first and argument entries provide supporting detail. This precedence comes from source type, not from a list of questions or exceptions written for a particular domain.
To compare reads and modifications, Tutor can combine an executor manifest with the public reversibility census. It must distinguish three cases: an action that can be undone, a modification with no reliable restoration, and a read or pure computation for which there is nothing to restore. It never infers an inverse operation from an executor's name.
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. A classifier may select only the identifier of an admitted view; the registry binds that view to exactly one probe and one precise data projection. The model writing the answer cannot choose the probe or 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 most relevant choice by 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 preliminary checks share a short time limit, so an operational request is not held up by Tutor. After a view is admitted, its read-only probe and the composition step may use the turn's full deadline. If the preliminary check 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 instance's current language, so the evidence language does not determine the answer language.
| Observation | Scope | Protection |
|---|---|---|
| admitted executors, lifecycle, and origin | instance administrator | no rejected paths or details |
| service health | instance administrator | no endpoints, PIDs, or unit names exposed to the model |
| scheduler health and cause | instance administrator | loop state and bounded diagnosis; no task text or run output |
| registered devices and reachability | devices owned by the user only | keys, fingerprints, and profiles remain excluded |
| scheduled tasks and recent runs | authenticated actor only | request 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.
You can ask: “Which services are running, and what are they for?”
Or: “Why is the scheduler down?”
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:
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.
For 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.
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.
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.
Any change to an admitted source alters the material fingerprint used to build the catalog. The compiler prepares a complete new version, verifies its schema, vectors, and signature, and only then replaces the current catalog in one atomic operation. Vectors for unchanged units may be reused, but a partial version 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.