-
Notifications
You must be signed in to change notification settings - Fork 3
Data model
🌐 English · 한국어
A conceptual reference for what MWeft stores and how the pieces relate. This describes the public model you interact with through the MCP tools and the Manager — it is not a schema dump. For the ideas behind it, read Concepts.
| Object | What it is | Notes |
|---|---|---|
| Entity | An object that appears in your data — a person, file, place, or concept. | Has a name, a type, and belongs to a domain. Carries an embedding vector. |
| Event | A document or conversation turn, treated as a thing that happened. The core unit; it binds the entities that take part in it. | Has an LLM‑generated summary and an embedding vector; carries timestamps. |
| Group / Tag | A label for organising memory by topic. | A tag name is unique and is cross‑cutting (can apply across domains). Tags can be hierarchical (a tag may have a parent tag). |
| Domain | A top‑level partition of a database. | Keeps unrelated content separate so it never mixes. |
An event's summary is written by an LLM — treat it as a gloss, not as the verbatim source text.
Entities and events form two graphs (entity↔entity and event↔event). The relationships you will encounter:
| Relationship | Connects | Meaning |
|---|---|---|
| participates in | Entity → Event | Which objects took part in an event. |
| tagged | Event → Tag | An event is labelled with a tag. |
| follows / sequence | Event → Event | One event comes after another in some ordering (e.g. document order, a thread, an explicit sequence). |
| connection | Entity ↔ Entity | An undirected link between two entities that are related (e.g. co‑occurring or semantically close). |
Tag hierarchy (a tag's parent tag) is stored on the tag itself, so the tree of topics lives with the tags rather than as separate links.
An entity is never linked directly to a tag or group. Its membership is derived two hops away, through the events it participates in:
Entity ──participates in──▶ Event ──tagged──▶ Tag
So an entity belongs to a topic only because of an event that actually references it. Practical consequences:
- Deleting an entity severs its event links and changes the graph — delete only what you have judged unnecessary.
- For duplicates, merge instead of deleting. A merge can be partly undone (the name can be restored), but the links lost in the merge cannot.
In addition to tags you define, MWeft can discover topic clusters by running community detection over the graph. These auto‑tags are not authored by hand; they summarise how your memory actually clusters — useful for getting a map of the whole store (cluster count, sizes, representative members). You can ask the AI to summarize them.
Both entities and events carry embedding vectors, so retrieval is comparison‑based rather than keyword‑only:
- find events with a similar context,
- find entities that are semantically close,
- surface related‑but‑contrasting results, not just near‑duplicates.
The default embedding model is BGE‑M3 (1024‑dim), run locally via ONNX with no API key. Other providers (OpenAI, local PyTorch) are configurable — see install.md.
| Backend | Use it when |
|---|---|
| SQLite | Single user. A local file; plenty for personal use. Concurrent multi‑user writes are not supported. |
| PostgreSQL | Multiple users, or cloud‑hosted. Required for concurrent access. |
For MWeft, network egress/ingress matters more than raw database size when using an external database — check traffic limits.
Memory is portable. You can export a domain to a single archive and import it elsewhere — including moving between SQLite and PostgreSQL. Restore makes a target database match an archive exactly (a full replace, guarded by a typed confirmation), which is the path for backups and SQLite ↔ PostgreSQL migration.
- Concepts — the ideas behind the model
- install.md — backends and embedding options
- prompt_guide.md — how an AI searches and saves