← Documentation index Architecture guide › Mnestoma

Metnos

Mnestoma: store of operational edges
SQLite schema, queries, maintenance, and actual integrations.

Mnestoma is the local store for mnests: links between executors that together form an operational graph. Its code can save, traverse, decay, and inspect these links. The runtime does not yet record them automatically at the end of every turn, so Mnestoma must not be mistaken for an already learned personal memory.

Contents

  1. Scope and status
  2. Graph model
  3. What it does not contain
  4. Database schema
  5. Writes and queries
  6. Nightly ager
  7. Archiving and retention
  8. Names in the two languages
  9. Bootstrap and population
  10. Inspection and observability
  11. Operational boundaries

1. Scope and status

Mnestoma opens a SQLite database with WAL writes and integrity constraints between tables. Its API can record links, change their state, traverse them, find recurring proto-mnests, and read statistics and events.

The same file also contains a separate canonical_query_log table, with a best-effort recording hook from the turn runtime. Current plan reuse does not depend on that table, and the runtime does not call record_passing() to build edges. The two structures must not be confused.

2. Graph model

In the logical model, each node identifies an executor name and version; each mnest is a directed, weighted link between two nodes. A proto link instead ends at the name of a desired executor that has no concrete version yet. walk(start, max_depth) traverses the graph from an executor, excludes protos by default, and orders paths from highest to lowest average weight.

Synt's composer can use this structure to find a chain of existing executors. It does not generate L0 or L1, alter the ordinary planner ranking, or replace the signed catalog.

3. What it does not contain

It is notReason
Complete turn historyTurns have separate logs; an event may store only their identifier.
A user profileThe schema describes executors, edges, and technical telemetry, not preferences or personal facts.
A plan cacheL0 and L1 use their own stores, keys, and validity rules.
Proof of effectsAn edge exists because a caller wrote it.
An automatic synthesis systemProtos are signals; Synt, tests, and the promoter have separate responsibilities.

4. Database schema

ObjectContent
executorsName, version, state, load time, and manifest hash. The current API does not populate it automatically.
mnestsEdges, weights, uses, timestamps, states, tags, and desired signature.
eventsReinforcements, decays, and state changes, with an optional turn_id.
v_mnestomaView of active and proto edges.
canonical_query_logCanonical query, tool, observed argument shape and values, counters, and outcome. It is telemetry separate from the graph.

On open, idempotent migrations add events.turn_id and canonical_query_log.args_observed to older databases.

5. Writes and queries

The main public operations are:

6. Nightly ager

The scheduler installs the nightly_aging job at 03:30. It runs executor aging and Mnestoma.apply_ager() in sequence. The latter:

  1. decays active and proto edges with time;
  2. moves below-threshold active edges to decaying;
  3. counts decaying archive candidates;
  4. deletes below-threshold protos;
  5. counts protos that reached recurrence thresholds.

If the job is called twice with the same reference time, the second call does not apply more decay. A later call with a more recent time calculates the new interval, updates ts_last, and records the corresponding events.

7. Archiving and retention

The ager does not automatically archive decaying edges: it returns a proposed_archive count. The module has no routine that creates monthly snapshots, compresses annual copies, or includes the database in a backup. Those operations require an explicit external policy.

The only automatic graph deletion performed by the ager concerns proto-mnests with weight below 0.05. Their associated events are also removed by the foreign key's ON DELETE CASCADE.

8. The name in both languages

Mnestoma is a Metnos technical name and remains unchanged in Italian and English, as does mnest. The Python module, class, and SQLite directory also use mnestoma. For compatibility, this page retains its former /en/architecture/mnestome.html address, but the component name is no longer translated in the text.

9. Bootstrap and population

On first open, the database is created with an empty schema. No hidden edge seed is installed, and the Mnest class does not admit a seed state. Edges appear only through explicit API calls or data already present in the configured database.

A best-effort hook may try to add a row to canonical_query_log from a turn. No current subsystem relies on this table for plan reuse. In any case, one of its rows does not represent the creation of a mnest, cluster, or L0/L1 path.

10. Inspection and observability

python3 -m mnestoma provides commands for statistics, aging, top incoming and outgoing links, proto-mnests, walks, summaries, and events. The python3 -m observability render renderer can include counts, active links, protos, and recent events in a static HTML page.

These tools read store contents; they do not establish that those contents are complete. An empty Mnestoma is a legitimate outcome of the current integration.

11. Operational boundaries