# validate_memory

> Check freshness of every record from one source against its current hash — parameters, report and errors.

On this page you will learn how to find, in one call, which records from a document went stale after it changed and which of them are in conflict.

The running example: the staging deploy procedure in `docs/deploy.md` changed. The agent computes the new hash of the file and asks MMW which facts from this document are now stale.

## Purpose

`validate_memory` compares the `source_hash` of every record with the given `source_id` against the current source hash you pass, and returns a report: how many records were checked, which are stale, which are in conflict. It only reads and changes nothing; you or the agent decide what to do with stale records.

## Parameters

| Parameter | Type | Default | Description |
| --- | --- | --- | --- |
| `workspace` | string | `"default"` | Workspace. |
| `source_id` | string | `""` | The source being checked. Effectively required: an empty value is an error. |
| `current_source_hash` | string | `""` | Fresh hash of the current source content. An empty value is an error. |
| `scope` | string or null | `null` | Filter by label. |

## Response

| Field | Description |
| --- | --- |
| `api_version` | API version (`1.0`). |
| `workspace` | Workspace. |
| `tenant_id` | Account identifier. |
| `source_id` | The source that was checked. |
| `current_source_hash` | The hash you passed. |
| `checked` | Number of active records from this source that were checked. |
| `stale_ids` | IDs of records that have a `source_hash` different from the current one. |
| `conflict_ids` | IDs of records that have versions with the same `fact_key` but different content in the workspace. |
| `stale_count` | Number of stale records. |
| `conflict_count` | Number of conflicting records. |

## Example

```json title="arguments"
{
  "workspace": "default",
  "source_id": "docs/deploy.md",
  "current_source_hash": "sha256:51d7b0e3"
}
```

```json
{
  "api_version": "1.0",
  "workspace": "default",
  "tenant_id": "t-3f9a",
  "source_id": "docs/deploy.md",
  "current_source_hash": "sha256:51d7b0e3",
  "checked": 3,
  "stale_ids": [
    "4d428a41-e7b0-4f81-a886-f40c6f6c766c",
    "9a0f3e57-1c2b-4d8e-a6f4-7b3c2d1e0f99"
  ],
  "conflict_ids": [],
  "stale_count": 2,
  "conflict_count": 0
}
```

Next, the agent can save the new fact with the current `source_hash` via [`remember`](/reference/remember/) and delete the stale records via [`forget`](/reference/forget/).

## Errors

| Text | Cause |
| --- | --- |
| `source_id and current_source_hash are required` | Empty `source_id` or `current_source_hash`. |
| `workspace '…' was deleted and cannot be reused` | The workspace was deleted. |
| `403 Forbidden: workspace access denied for project` | The workspace belongs to another project. |
| `MCP rate limit exceeded`, `project call limit exceeded` | Too many calls per minute. |
| `[MMW Notice]: …` | No subscription or suspended account. The check keeps working during the grace period. |

## Notes

- Records without a `source_hash` count in `checked` but never become stale: there is nothing to compare.
- A hash is provenance, not proof. Matching hashes do not make a record "verified": MMW has no `verified` status.
- In an organization, only records visible to you under the [visibility](/organizations/visibility/) rules are checked.
- The hash format is up to you; it only has to be computed the same way when saving and when checking.

Use `validate_memory` rather than `search` with `current_source_hash` when checking one document: `validate_memory` looks only at records with that `source_id`.

## Next steps