← Documentation index Architecture guide › Synt

Metnos

Synt: filling a gap without blindly activating code

Reuse what already exists; if that is not enough, build and test an isolated candidate.

Synt is the part of Metnos that tackles a missing capability. It can find a combination of already-admitted executors or generate a new candidate. In neither case does a model response immediately become an active power: composition and generation follow separate paths, with different controls and responsibilities.

Two different paths
Before generating
Composing existing executors
Generating a candidate
Checks and real tests
Quarantine and promotion
Language and records
Guarantees and current limits

1. Two different paths

Path	When it is useful	What it produces
Composition	The capability already exists but is spread across several executors.	A short chain of active, signed executors. No new code is created.
Generation	A capability representable by the standard is genuinely missing.	An executor candidate with a manifest, code, and tests, still excluded from the operating catalog.

Synt does not enlarge a user's permissions or bypass the catalog. A new executor must use canonical verbs and objects, declare its arguments, capabilities, and any undo operation, pass tests, and obey its execution profile. A signature protects the artifact's integrity; it does not authorize use by itself.

2. Before generating

The multistage path begins with the internal request_new_executor request, which carries an expected name and the intent to cover. Before calling any model, the runtime checks whether the gap is real:

if the name already exists in the catalog, it returns the current executor;
if an equivalent canonical producer exists, it redirects to that producer;
if an imported skill already covers the verb and object, it redirects to that capability;
if the request belongs to a native binding such as remote files, SSH, or an authenticated site, it points to the appropriate integrated executor;
if a proposed or synthesized candidate already exists, it does not create a duplicate.

These checks use the catalog, vocabulary, and binding registry. They do not depend on special sentences added for one case. If they find an existing capability, Synt returns the name to use and generates nothing.

3. Composing existing executors

When the runtime observes an incomplete relationship between known tasks, it can search the mnestoma for a chain of at most five steps. The search uses active executors only. If it finds a path, it suggests the first executor to the engine and lets the turn continue under ordinary controls.

This reactive composition is not a pretend first stage of request_new_executor. It is a separate path based on a relationship already recorded in the mnestoma. Multistage generation begins after the admission checks described above.

4. Generating a candidate

Generation separates decisions about the contract from the writing of code. The first five stages produce the artifact; a sixth compares it with its description:

Step	Logical workload	Binding output
1. Name and class	`middle`	`action_object[_qualifier]`, criticality, undoability, and target kind.
2. Operational signature	`middle`	Argument schema, declared capabilities, and a reverse pattern when required.
3. Birth tests	`middle`	At least three cases with input and an observable expected outcome.
4. Description	`creative`	Manifest head, affinity terms, and usage boundaries.
5. Code	`wise`	`invoke`, `main`, and any reverse operation, built against the earlier contract.
6. Consistency	`wise`	A comparison between described behavior and generated code.

These names identify logical workloads, not models embedded in the code. Provider, model, and generation policy come from the central tier configuration. Each step receives the request and validated results only, so the code cannot silently redefine the name, arguments, or undo semantics.

5. Checks and real tests

Per-stage validation. Name shape, vocabulary, types, undoability, tests, and description are checked before proceeding.
Structural lint. Between code generation and semantic verification, a deterministic check prevents the manifest from citing nonexistent arguments, runtime-resolved fields, or an incompatible output shape.
Semantic verification. A separate judge compares description and code. Its verdict is probabilistic; code applies the decision to reject an explicit mismatch.
Generated contract. Manifest format, standard, lifecycle, and execution policy must match the runtime-owned template.
Compilation and real tests. The implementation must first be valid Python. After installation, the test runner executes the declared cases; any failure removes the quarantined copy.

A mismatch, an untyped payload, or unavailability of the semantic judge rejects the candidate. Environment variables cannot disable the linter or the judge. An infrastructure failure is recorded as unavailability; it is never converted into certification of semantic consistency.

6. Quarantine and promotion

When all steps and tests succeed, the runtime saves the candidate in the user executor store, sets its lifecycle to synthesized, and signs the manifest. The loader can inspect it, but the planner and composer still cannot select it.

Each day the promoter examines up to five candidates, oldest first. Its evaluator is deterministic: it checks the name, overlap with existing capabilities, tests, undo consistency, error classes, result stability, usage frequency, and estimated benefit.

Verdict	Effect
`accept`	Automatic promotion after a fresh admission check, with a rollback archive and normally a 72-hour grace period.
`gray`	`review_needed` state; no automatic activation.
`reject`	Archived with a rationale; the candidate does not enter the active catalog.

A rollback archive is created before promotion. If administrator Telegram notifications are configured, a digest offers confirmation and rollback during grace; when the period expires, the promotion is finalized. Automatic error monitoring always observes signals, but actually performs a rollback only when METNOS_PROMOTER_KILLSWITCH_ENFORCE=1 is enabled.

This lifecycle belongs to the promoter, not the unified change-intent lifecycle. A synthesized candidate is not duplicated as a false proposal that requires approval in a second store.

7. Language and records

Prompts are loaded in the language of the turn. The candidate description and its argument descriptions begin in that language; the normal manifest alignment process can add other versions. Canonical names, schema fields, and identifiers remain stable.

The affinity field is still one flat list of keywords, often mixing Italian and English. It is therefore not fully compliant with the i18n architecture. A general redesign is registered at maximum priority and requires analysis, comparison of alternatives, an approved specification, and only then development.

Proposals, step results, rejection reasons, evaluations, promotions, and rollbacks remain in local stores. Prompts do not receive clear-text credentials. Generated code remains subject to allowed Python modules, its sandbox profile, and the limits of the Executor Standard.

8. Guarantees and current limits

Name, description, test, and code generation are probabilistic. The controls reduce risk but do not constitute a formal proof.
Tests cover only their declared cases. Grace, telemetry, and rollback exist for failures that appear in real use.
An accept verdict currently causes automatic promotion. The score is an operating policy, not proof that the new capability is useful in the abstract.
The gray path is recorded as requiring review, but does not yet have a complete dedicated web surface.
Error-based automatic rollback is disabled by default. Without enforcement, monitoring only reports that it would have withdrawn the candidate.
Synt must not duplicate work already handled by a learned sequence, a skill, or an integration.

Code references:

runtime/synth_request.py: initial admission and candidate persistence;
runtime/synt_multistage.py: staged generation, lint, and semantic verification;
runtime/generated_executor_contract.py: generated-manifest envelope;
runtime/proposal_evaluator.py: deterministic evaluation;
runtime/jobs/promoter*.py: promotion, digest, grace, and rollback;
runtime/loader.py: lifecycle visibility.