---
description: Inspect memories in the read-only local graph, use HTTP for corrections, and check agents and protection.
---

# Inspect your memory

Open the Ormah app or [http://localhost:8787/](http://localhost:8787/) to see the local graph. The graph and node detail panel are read-only: they have no memory editor or delete button. The visual interface lives at the root URL. `/ui/graph` and `/ui/search` are JSON API routes, not separate pages.

## Find a saved memory

Use search for a distinctive phrase such as “Checkout retries”. Select the result or graph node to inspect its title, content, type, tier, space, tags and connections. Compare the node ID with the successful tool result from Quickstart.

A search result proves the indexed node is available. It does not prove a coding agent received it automatically. Follow the separate [delivery check](/docs/getting-started/quickstart#verify-automatic-delivery) for that.

## Correct content and scope

Inspect the node first with `recall_node` or the graph. To change its content, use `POST /agent/update/{node_id}`. Replace `NODE_ID` with the full ID returned by the memory tool; the graph label shows only a shortened ID. This command changes the selected node's content, so use your synthetic test node:

```bash
curl -fsS -X POST http://127.0.0.1:8787/agent/update/NODE_ID \
  -H 'Content-Type: application/json' \
  -d '{"content":"Synthetic correction: checkout retries reuse the original idempotency key."}'
```

Inspect the returned text, then call `recall_node` or reopen the graph to verify the stored content. The update endpoint can set a named space, but `space: null` leaves the current space unchanged; see [correcting stored scope](/docs/use-memory/project-and-global#save-a-global-memory-reliably).

A project preference such as “This project uses pnpm for package management” should have type `preference` and that project's space. Global memory has no named space. Check the stored value; some adapters replace an omitted/null creation scope with their detected project. [Project and global memory](/docs/use-memory/project-and-global).

## Understand the graph

Nodes are memories and edges are typed relationships. The Self node anchors user identity. A memory's **type** says what it is, such as a fact, decision or preference. Its **tier** says how long Ormah keeps it in play.

Think of core as what a long-time colleague knows about you without being reminded: your name, that you always use pnpm, that nobody commits straight to main. Working memory is the current project's notes. Archival is the filing cabinet.

| | Core | Working | Archival |
| --- | --- | --- | --- |
| Holds | Lasting facts and rules about you and how you work, plus the Self node | Everything in active use: decisions, project details, recent findings | Memories that have gone unused |
| Example | “Always use pnpm in this repository” | “Checkout retries reuse the original idempotency key” | A workaround for a bug fixed months ago |
| Permanence | Not archived by decay; stays core until its tier is changed | Moves to archival when its retrievability falls | Kept in the store, not deleted; confirmed use can return it to working |
| Relevance | Delivered only when relevant to the prompt, with a modest ranking lift | Delivered when relevant | Not delivered automatically; retrieve it deliberately |
| How it gets this tier | Only by choice: an agent or you set `tier` to `core` when saving or in a later update. Ormah does not promote memories to core automatically. | Default for every new memory | Automatically, through [decay](/docs/how-ormah-works/background-jobs#decay-and-confirmed-use) |

Core is **not** sent with every prompt, even though the `remember` tool describes it as “always loaded”: it means always kept, not always injected. Keep core small; a rule that only matters for one task belongs in working memory.

The tier is separate from the type: a `decision` can be working or core. See [Tiers and identity](/docs/how-ormah-works/data-model#tiers-and-identity) for the lifecycle details.

Search, filters and connections provide different ways to inspect the same source-backed store. Review proposed merges/conflicts in the review interface before accepting a change you don't understand. [Self-healing memory](/docs/how-ormah-works/background-jobs) explains where they come from.

## Remove a test or outdated fact

First retrieve the full node ID and confirm it is the synthetic memory you intend to remove. Delete it through HTTP:

```bash
curl -fsS -X DELETE http://127.0.0.1:8787/agent/recall/NODE_ID
```

Replace `NODE_ID` with that actual ID. Read the result; then `GET /agent/recall/NODE_ID` should return HTTP 404. The local source is soft-deleted into `deleted/`; this is not secure erasure and does not remove it from snapshots. Neither the graph UI nor the standard MCP/CLI tool set provides a delete control/command.

If information has become stale but its history is useful, use `mark_outdated` through the agent tools instead. Deletion and demotion are different operations.

Take a [snapshot](/docs/use-memory/backup-and-recovery) before large cleanup. Deleting locally does not erase content already passed to an external agent/provider.

## Agents and protection

The **Agents** panel shows detected clients and connection controls. To connect one:

- Connect the client from the panel.
- Restart or reload the client.
- Test a real tool call.

Wiring status is configuration evidence, not a transcript of a successful hook.

The admin interface includes local backup controls. The **Protection** flow includes cloud account/backup/recovery status. Some sensitive actions, particularly saving/opening the recovery kit, depend on the native desktop bridge and are not equivalent to browser controls. Follow the [recovery guide](/docs/use-memory/backup-and-recovery) before replacing memory.