A mnest represents a directed, weighted relation from a source
executor to a destination executor. Its store, queries, and ager are implemented.
The current runtime, however, does not automatically call
record_passing() at the end of turns: a record in the store is data
inserted by an explicit caller, not proof that the product learns every observed
passing.
The Mnest type and its operations live in
runtime/mnestoma.py. They store and query links between executor
names and versions; they are not personal memory and do not imply automatic
learning.
| 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. |
A mnest has a src_executor → dst_executor direction,
versions, use count, weight, first and last update times, and state. The structure
can represent the operational fact that a caller recorded a passing 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 consists of two
edges; multi-edge traversal is performed by walk().
The record does not contain the transferred output and does not verify by itself
that the transfer occurred. Provenance depends on the caller of
record_passing(). An optional turn_id in the event can
lead back to the originating turn, but only if that reference was supplied and the
corresponding log still exists.
A mnest must therefore not be presented as self-sufficient evidence, a biographical memory, or a user preference. It is structured telemetry about a relation between capabilities.
| 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() opens a transaction. If it finds the same
active edge, it applies accrued decay, adds reinforcement,
increments uses, and records an event. Otherwise it creates a new
edge with weight 0.30 and an initial event.
With dst_exists=False, the same API creates or reinforces a
proto-mnest. The call is atomic for the searched pair, but a
Mnestoma object owns a process-local connection and does not declare
its instance thread-safe.
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 contains canonical_query_log, populated by some
turns as normalization telemetry. That table is not a mnest and does not show that
the edge graph was updated. The module does not implement monthly snapshots or
automatic compression.
Ask Metnos with a request like this example: “Explain whether the mnestome is populated automatically by my turns and 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.