1. Scope and boundaries

This document defines what a mnest is: the trace, kept in the mnestome, of an output passing between two executors. It is the second of three canonical docs introduced by the Dialogue on executors and distributed memory. The mnest records an observed data passing between two executors, not a passive concomitance.

Boundaries

The document covers:

• the structural contract of a mnest (fields, constraints, transitions);
• when and how a mnest is born, reinforced, decays;
• the proto-mnest: how an unsatisfied desire is represented;
• persistence and snapshots.

It does not cover, and defers to other docs:

• the global structure of the mnestome and its queries (see mnestome.html);
• the synthesis that uses recurring proto-mnests (see executor.html, ch. 7);
• Vaglio criteria (see vaglio.html, in Italian and pending rewrite);
• the phenomenology of decay (see ager, future doc).

2. What a mnest is

A mnest is a node of the mnestome that records a specific fact:

A mnest is therefore a trace of observed co-activation: not an a-posteriori statistical inference, not a declaration of intent, but a statement that an event actually happened, recorded by the gateway at the end of the turn.

From this all its important properties follow:

• It is directed: A → B is not the same as B → A.
• It is weighted: the more it recurs, the more the weight grows; with disuse, it decays.
• It is time-anchored: it carries the timestamp of the first and the latest use.
• It is distinct per version pair: read_files → read_files_pdf v2.0 is one mnest, read_files → read_files_pdf v3.0 is another.

3. Semantics of the mnest

The mnest records a passing of data («A's output was B's input»), generated deterministically by the gateway at turn close: either the passing happened or it did not. A strong mnest toward an executor that does not exist (proto-mnest, ch. 8) is a concrete operational gap, not an analogy.

The mnest sees data that moved, not just events that fired. A mnest graph is a graph of real flows.

4. Anatomy of a mnest

A mnest, in serialised form, contains these mandatory fields:

{
 "id": "mnest_01HW...", // ULID
 "src_executor": "read_files", // canonical name of the caller
 "src_version": "1.0.0",
 "dst_executor": "read_files_pdf", // canonical name of the callee
 "dst_version": "2.0.0",
 "weight": 0.42, // [0..1], normalised
 "uses": 17, // total use counter
 "ts_first": "2026-03-12T18:04:00Z",
 "ts_last": "2026-04-23T09:21:00Z",
 "decay_lambda": 0.018, // /day, see ch. 6
 "tags": ["invoice", "pdf"], // optional
 "state": "active" // active | proto | decaying | superseded
}

Three invariants always hold:

• (src_executor, src_version, dst_executor, dst_version) is the key: at most one active mnest per tuple.
• weight is always in [0, 1], computed as an exponential function of recent uses (see formula in ch. 6).
• ts_last >= ts_first; uses >= 1.

Tags, briefly

Tags are an optional addition that does not influence weight computation, but help the ager and the synt identify clusters of mnests living in the same application domain (e.g. «invoice», «photo», «work email»). Tags propagate from the turn context to the newborn mnest; the user can re-tag or clear them during review.

5. Automatic generation

A mnest is not declared, it is observed. The operational rule, applied by the gateway at the close of every turn:

1. For every call pair A → B within the turn where A's output was passed as B's input:
   1. look up an active mnest with key (A, ver_A, B, ver_B);
   2. if it exists, increment uses, update ts_last, recompute the weight;
   3. if not, create one with uses=1, initial weight, state="active".
2. If the turn included a request to pass to an executor that does not exist, record a proto-mnest instead (ch. 8).
3. If the turn had a long chain (A → B → C), record two separate mnests: A→B and B→C. The mnestome does not represent arcs longer than one.

6. Reinforcement and decay

The weight of a mnest is updated at every event by a formula with two components:

weight(t) = clamp01( weight(t-Δt) * exp(-λ * Δt) + reinforcement(t) )

• Δt is the time (in days) since the last update.
• λ is the decay lambda, parametrisable per tag (default 0.018/day: half-life ~38 days).
• reinforcement(t) is +0.15 per use recorded in the current turn, saturated by clamp01.

The curve is inspired by the Ebbinghaus model, but the value of λ is conservative: at equal use, a mnest is never forgotten quickly. The gradualness avoids oscillations due to holiday periods, illness, distraction: when the user comes back, Metnos must remember.

Operational thresholds

7. Lifecycle states

8. The proto-mnest

The proto-mnest is a mnest in proto state: it records that, in a turn, Metnos wanted to pass the output of an executor to a second executor that does not yet exist. Its structure is almost identical to a normal mnest, with two differences:

• dst_executor is a «desired name», not a resolvable name (e.g. extract_invoice_number);
• dst_version is null;
• a field desired_signature appears with the synthesis of the expected signature: what the executor should do, what output shape, what typical errors.

{
 "id": "mnest_01HW...",
 "src_executor": "read_files",
 "src_version": "1.0.0",
 "dst_executor": "extract_invoice_number", // does not exist
 "dst_version": null,
 "desired_signature": {
 "summary": "Extract the invoice number from a PDF.",
 "inputs": ["bytes (pdf)"],
 "outputs": ["str (alphanumeric code)"],
 "errors": ["NotFound", "Unparseable"]
 },
 "weight": 0.34,
 "uses": 4,
 "state": "proto"
}

The difference from a «feature request» in the classical sense is important: the proto-mnest is not asked by the user, it is observed by the gateway. Roberto did not formulate the need: the need emerged from the fact that he would have wanted it more than once. The proto-mnest, when it recurs, is the trigger of synthesis (see executor.html ch. 7).

9. Who consults the mnests

10. Persistence and snapshots

Mnests live in workspace/.mnestome/mnest.sqlite:

• a single mnests table with the fields from ch. 4 plus indexes on (src_executor, dst_executor) and weight;
• an append-only events table with individual reinforcements, to allow reconstruction of the weight history (useful for debugging and the ager);
• a v_mnestome view that projects the current state of the graph (active + proto), for read queries.

The system takes a monthly snapshot of the SQLite file into workspace/.mnestome/snapshots/YYYY-MM.sqlite. The snapshot serves three purposes: rollback in case of corruption of the live file, historical analysis of the graph, trace for whoever wants to understand how Metnos moved over time. Snapshots older than 12 months are .zst-compressed but not deleted.

Backup

The live SQLite file is included in the nightly workspace backup under the same policies as the rest of the workspace. Losing the mnestome is not catastrophic (the system restarts empty and rebuilds from use) but it is one of the most precious data: it carries the operational history Metnos has learned to recognise.

11. Example: the invoice sequence

To pin the concepts down, here is a typical sequence of mnests that forms around the «archive a PDF invoice» flow:

1. read_files → read_files_pdf v2.0 (weight 0.85, uses 47, "invoice")
2. read_files_pdf v2.0 → invoice_classify (weight 0.78, uses 41, "invoice")
3. invoice_classify → workspace_save (weight 0.81, uses 44, "invoice")

# proto-mnest that recurs but is not yet an executor:
4. read_files_pdf v2.0 → extract_invoice_number (weight 0.34, uses 4, "invoice")

The fourth, if it keeps recurring, will lift its weight above the synthesis threshold and the synt will propose to Roberto the synthesis of the new executor extract_invoice_number. Once approved and signed, the proto-mnest will move to active with its dst_version made concrete.

12. Open questions

1. Garbage collection of the SQLite file. When is space for archived mnests reclaimed in the live file? Never (full history) or periodically (for size)? Open.
2. LLM-suggested tags. The gateway can have the LLM suggest tags during turn close. How much to trust those tags? Should the user ratify them? Open.
3. Cross-sender mnests. When Metnos has multiple paired senders in the future (guests), are mnests per-sender or global? Likely global with a sender-of-origin tag, but to be decided.
4. Differentiated decay by category. Is it useful to have different λ for side-effect-free vs side-effect-full executors? Open.

Metnos — mnest microdesign
Canonical doc.