# Core concepts

> What an MMW memory record is made of — fields, statuses, the scope label, confidence, fact_key versions, summaries and graph relations.

On this page you will learn:

1. which fields a memory record has and where they come from;
2. what the `unverified`, `stale` and `conflict` statuses mean;
3. how records relate to each other: versions of one fact, summaries and the graph.

Running example: the team agreed that **staging is deployed through the `app-staging` systemd unit**, and the rule is written down in `docs/deploy.md`.

## A memory record

A record is one fact, decision or agreement. The agent creates it with [`remember`](/reference/remember/) and finds it with [`search`](/reference/search/). This is a record as it appears in search results:

```json
{
  "id": "4d428a41-e7b0-4f81-a886-f40c6f6c766c",
  "workspace": "default",
  "scope": "shared",
  "content": "staging is deployed through the app-staging systemd unit",
  "source": "agent",
  "source_id": "docs/deploy.md",
  "source_hash": "sha256:9f2c…",
  "source_revision": "a1b2c3d",
  "fact_key": "deploy.staging.method",
  "confidence": 0.8,
  "status": "unverified",
  "derived_from": [],
  "score": 2,
  "graph_relations": [],
  "created_at": "2026-10-05T09:12:00+00:00",
  "updated_at": "2026-10-05T09:12:00+00:00"
}
```

| Field | Set by | Meaning |
| --- | --- | --- |
| `id` | server | Unique record ID. Used by `forget` and `derived_from`. |
| `workspace` | agent | Workspace — a named collection inside a project. Defaults to `default`. |
| `scope` | agent | A filter label, `shared` by default. It does not restrict access (see below). |
| `content` | agent | The record text. Secrets are replaced with placeholders before saving. |
| `source` | agent | Who saved it: `owner` by default; you will also see `agent`, `telegram` and others. |
| `source_id`, `source_hash`, `source_revision` | agent | Provenance: the document, a hash of its content, its version. See [Source and freshness](/memory/source-and-freshness/). |
| `fact_key` | agent or archivist | Topic key. Records with the same key are compared with each other. |
| `confidence` | agent, archivist | Confidence from 0 to 1, default 0.5. |
| `status` | server | `unverified`, `stale` or `conflict` — computed on every search. |
| `derived_from` | agent | IDs of the records this one summarizes. |
| `score` | server | Relevance to the query in this search. |
| `graph_relations` | archivist | Links to other records. |
| `created_at`, `updated_at` | server | Creation and last-change time (ISO 8601). |

`remember` never deletes or overwrites existing records: every call adds a new one. Only [`forget`](/reference/forget/) deletes, and softly — the record disappears from search and the graph, while the fact of deletion is kept for audit.

## Statuses

There is no `verified` status in MMW. The server records **where** a fact came from; it does not claim the fact is **true**.

| Status | When | What the agent should do |
| --- | --- | --- |
| `unverified` | The normal state of every new record, even one with a `source_hash`. | Use it, keeping the source and confidence in mind. |
| `stale` | The source changed: `search` or `validate_memory` received a `current_source_hash` different from the stored one; or the archivist marked the record as contradicted by a newer one. | Re-read the source and update the fact. |
| `conflict` | Other records in the same workspace share the `fact_key` but differ in content or source hash. | Do not pick one silently — show the disagreement to a person. |

If several statuses apply, the more alarming one wins: `conflict` over `stale`, `stale` over `unverified`. A summary takes the worst status of the records it was built from.

A hash supplied by the client is provenance, not proof, so a new record is always `unverified`. Older server versions could store `verified`; such records are shown as `unverified` in search results.

## scope is a label, not access control

`scope` (`shared` by default; `private` is common) is just a tag you can filter `search` and `validate_memory` by. A record with `scope: "private"` is visible to everyone with access to the project.

Who sees what is decided elsewhere:

- in a personal account — by the key's project (see [Workspaces and projects](/memory/workspaces-and-projects/));
- in an organization — by the record's **visibility**: author only, department, project or the whole organization (see [Visibility](/organizations/visibility/)).

## confidence

A number from 0.0 (unsure) to 1.0 (certain), default 0.5. Values outside the range are rejected. The agent sets it when saving; the archivist may **lower** an older record's confidence when a newer one refines or contradicts it.

A good habit: 0.9 and up for what was read in a document or confirmed by a person; 0.5 for the agent's own conclusions; lower for guesses.

## fact_key and fact versions

`fact_key` is a stable name for a topic, such as `deploy.staging.method`. Saving again with the same key adds a **new version**; earlier ones are kept and nothing is deleted.

```text
  fact_key = deploy.staging.method
  ───────────────────────────────────────────────────────────
  v1  "through the app-staging systemd unit"   ─┐
  v2  "through Docker Compose, staging service" ├─ both have status conflict
                                               ─┘  until the wrong one is removed with forget
```

If the versions are identical (same text and same source hash), there is no conflict. Details: [Conflicts and summaries](/memory/conflicts-and-summaries/).

If you did not set a `fact_key`, the archivist may assign a service key of the form `archivist:shelf:short-summary`.

## derived_from: summaries

When the agent condenses several records into one ("this week's deployment summary"), it passes their IDs in `derived_from` (up to 50 existing records). The summary remembers what it was built from and **inherits** the `conflict` and `stale` status of its sources, so condensing never hides unresolved contradictions.

## Graph relations

After a record is saved, the [archivist](/memory/archivist/) compares it with recent records in the same workspace and may create links. Search results show them in `graph_relations`:

```json
"graph_relations": [
  {
    "relation": "supersedes",
    "direction": "outgoing",
    "weight": 0.9,
    "target_id": "0b7e…",
    "preview": "staging is deployed manually with scp"
  }
]
```

Relation types: `relates_to`, `fixes_issue` and `supersedes`. `preview` is the first 120 characters of the linked record. Links to deleted records, or records you cannot see, are not shown.

## Where next