A mnest records that the output of one executor was passed to another. For example, it can connect a file search to the executor that reads the files found. The link has a direction, a weight, and a use count. The store and its management operations exist, but the runtime does not yet record every turn's hand-offs automatically.
The Mnest type and its operations are defined in
runtime/mnestoma.py. The module stores and queries links between
executor names and versions. These links describe an operational structure of
the installation: they are not personal memories and, by themselves, do not
show that Metnos is learning a user's habits.
| Part | Status |
|---|---|
| SQLite schema and CRUD/query API | Implemented. |
| Reinforcement, decay, and recurring-proto detection | Implemented. |
| Ager in the nightly cycle | Registered with the scheduler. |
| Automatic edge recording from every turn | Not wired into the ordinary runtime. |
| Direct use by the planner or Vaglio | Not wired. |
Every mnest runs from a source executor to a destination executor:
src_executor → dst_executor. It stores the versions involved,
use count, relation weight, first and last update times, and state. Strictly
speaking, it says only that a component recorded a hand-off from A to B.
Direction matters: A→B and B→A are different records. A new destination
version also creates a distinct relation. A chain A→B→C contains two
links; walk() can traverse more than one.
The record does not contain the transferred output and cannot verify by itself
that the transfer actually occurred. Its reliability therefore depends on the
component that calls record_passing(). An event may include a
turn_id, which helps locate the originating turn if the reference
was supplied and the corresponding log still exists.
A mnest is therefore not self-sufficient evidence, a biographical memory, or a user preference. It is structured telemetry about a relation between executors.
| Field | Contract |
|---|---|
id | mn_ prefix followed by a random token. |
src_executor, src_version | Source and version declared by the caller. |
dst_executor, dst_version | Destination; the version is null for a proto. |
weight | Real number constrained from 0 to 1. |
uses | Integer counter, at least 1. |
ts_first, ts_last | UTC timestamps; the last is not before the first. |
decay_lambda | Decay rate. |
state | active, proto,
decaying, or superseded. |
tags | Optional JSON labels; they do not alter weight. |
desired_sig | Optional desired signature used by proto-mnests. |
SQLite uniqueness includes source, versions, destination, and state. Because
SQLite treats multiple NULL values as distinct, the code uses an
explicit query to reinforce an existing proto.
record_passing() performs the update in a transaction. If it
finds the same active link, it calculates how much the weight has
decayed since the previous use, adds the new reinforcement, increments
uses, and records the event. If the link does not exist, it creates
one with weight 0.30.
With dst_exists=False, the same API creates or reinforces a
proto-mnest. The call is atomic for the pair being searched. Each
Mnestoma instance does, however, open its own SQLite connection and
must not be shared between threads.
Before each reinforcement, the previous weight is multiplied by
exp(-lambda × days); 0.15 is then added and the
result is clamped to 0–1. The default lambda is 0.018 per day.
apply_ager() decays active and proto
edges. An active edge below 0.20 becomes
decaying; a proto below 0.05 is deleted. A
decaying edge below 0.05 and inactive for at least 90
days is merely counted as an archive candidate: the ager does not delete it.
| State | Use in current code |
|---|---|
active | Concrete edge available for queries and reinforcement. |
proto | Desired destination without a concrete version. |
decaying | Edge that fell below the ager's threshold. |
superseded | Edge marked as replaced by an explicit caller. |
transition_state() accepts only these values and records an event.
A later record_passing() looks for an active edge; it
does not automatically reactivate a decaying record.
A proto-mnest stores a concrete source and the name of a still-missing
destination. desired_sig may contain the expected summary, inputs,
outputs, and errors. By default, recurring_protos() selects records
with at least three uses and a weight of at least 0.30.
promote_proto_to_active() sets the destination version, clears
the desired signature, and records the transition. It does not create, test, or
activate an executor: those responsibilities belong to Synt
and its promotion lifecycle.
active edges only;
diagnostic commands can list recurring protos.nightly_aging job calls
apply_ager() together with executor aging.The current planner does not use mnest weights to rank the catalog; the Vaglio does not read them. L0 and L1 have separate stores and signals.
The default database is
<workspace>/.mnestoma/mnest.sqlite, configurable through
METNOS_WORKSPACE or MNESTOMA_DB_PATH. The
mnests and events tables hold state and events; the
v_mnestoma view exposes active and
proto edges.
The same database also contains canonical_query_log, a separate
table originally introduced for request-normalisation telemetry. Current plan
reuse takes place in the L0 and L1 stores described in the
fastpath and autopath guide: a row in this table is
not a mnest and does not show that the link graph was updated. The module does
not create monthly snapshots or compress the database automatically.
You can ask Metnos: “Is the mnestoma populated automatically by my turns? Which components read it today?”
A correct answer must distinguish available code from integration: the store, composer, ager, and inspection tools exist; automatic edge recording from turns is not wired. It must not invent an already-learned personal graph.