Synt builds an executor candidate when the catalog has no suitable capability. It does not turn model prose into immediately executable code: it first rules out duplicates, separates contract from implementation, runs checks and birth tests, signs the artifact in quarantine, and hands it to a promoter with evaluation, an observation period, and rollback.
Synt receives an uncovered intent and produces a proposal conforming to the executor contract. Its result may include a canonical name, argument schema, capabilities, reversibility, tests, description, affinity, and Python code.
Synt does not enlarge a user's permissions, create verbs or objects outside the vocabulary, overwrite handcrafted executors, or make a candidate planner-visible merely because the code compiles. Policy, standard conformance, signatures, sandboxing, and consent remain separate controls.
The internal request_new_executor request must provide an expected
name and the intent to cover. Before spending generation calls, the runtime applies
admission checks:
proposed or synthesized candidate already exists,
it does not create a duplicate.These controls are driven by the catalog, vocabulary, and binding registry, not by exceptions written for one sentence.
The least invasive solution is to compose already-signed capabilities. The composer can search the mnestoma for a short chain that closes the intent and return the suggested first step to the engine. No new executor is created in this case.
When an atomic capability or promotable pipeline is genuinely missing, staged synthesis begins. The outcomes remain distinct:
| Outcome | Artifact | Visibility |
|---|---|---|
| Composition | Chain of existing executors | Usable in the turn after ordinary controls |
| Synthesis | New candidate with manifest, code, and tests | Quarantined until promotion |
| Stage | Binding output |
|---|---|
| 1. Name and class | action_object[_qualifier], criticality, reversibility, and target kind. |
| 2. Operational signature | Argument schema, declared capabilities, and a reverse pattern when required. |
| 3. Birth tests | At least three cases with input and an observable expected outcome. |
| 4. Description | Conforming manifest head, affinities, and usage boundaries. |
| 5. Code | An invoke implementation, and a reverse operation when needed, built against the earlier contract. |
Stages 1–4 use the middle LLM role; code uses
wise. These roles are configurable and may point to the same local
provider. Each stage receives only the request and validated outputs from earlier
stages, so code cannot silently redefine the contract.
An infrastructure failure in the semantic judge is recorded but does not alone reject the candidate: deterministic checks, tests, and the downstream evaluator remain mandatory. This is explicit degradation, not proof of alignment.
When all stages and birth tests succeed, the runtime writes the candidate to the
user executor store with lifecycle synthesized and signs its manifest.
The signature establishes artifact integrity; it is not activation. The loader can
inspect the candidate while the composer's catalog excludes it.
The promoter then evaluates the proposal document using deterministic signals: name conformance, overlap with existing capabilities, tests, reversibility parity, error classes, schema stability, call frequency, estimated benefit, and routing interference risk.
| Verdict | Effect |
|---|---|
accept | Fresh admission checks, active signature, rollback archive, and a grace period. |
gray | Administrative review is required; there is no implicit activation. |
reject | Archive with a reason; the candidate does not enter the active catalog. |
Ask Metnos with a request like this example: “In the CSV files under Sensors, find runs of at least five measurements that increase without a break, and create a summary for each sensor.”
Metnos first attempts a pipeline of existing capabilities: find files, read CSV, extract, and group. Only if the catalog cannot represent the required operation may it propose a new capability. The answer must distinguish three outcomes clearly: the operation completed with existing tools, a candidate was created but is not active yet, or synthesis was rejected with a reason.
The same sentence can be used in Telegram. If an administrative decision is needed, Metnos must state that management happens in the web chat and provide the current navigation path, such as Settings › Lifecycle › Changes, instead of showing only a proposal identifier.
An accepted proposal normally enters a configurable grace period. The promoter creates a rollback archive first. During grace, hard failures observed in real turns may trigger the kill switch. The administrator can also confirm or withdraw the promotion from the delivered digest. The promotion is finalized after grace expires without a negative signal.
The Synt-candidate promoter and the unified
change-intent lifecycle have distinct ownership. A
synthesized candidate is not duplicated as a false approval request in
a second store.
Stage prompts are loaded in the turn language. Descriptions and affinity can be localized; canonical names, schema fields, and identifiers remain stable. Any i18n keys introduced by generated code are registered for the normal translation pipeline rather than invented in one UI.
Proposals, stage results, rejection reasons, evaluations, promotions, and rollbacks are retained in local stores and JSONL audit logs. Prompts do not receive plaintext credentials. Generated code remains subject to allowed imports, sandbox profiles, and executor-standard limits.
Code references:
runtime/synth_request.py: initial admission and candidate persistence;runtime/synt_multistage.py: five stages, 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.