Dashboard

Browse docs

Dashboard

Tap to expand

Contribute

DashboardUpdated 2026-03-18

Memories Workflow

Inspect stored memory in the dashboard, filter by type, and validate whether RetainDB is storing the user or session context you expect.

The Memories page is the quickest way to inspect what RetainDB has actually stored for a project.

Use /dashboard/dev/memories when you want to validate memory content directly instead of inferring it from a later search result.

What you can do on this page

  • choose a project
  • search stored memory by content
  • filter by memory type
  • add a memory manually
  • delete a memory
  • inspect importance and recent update time

The current UI supports the canonical memory types:

  • factual
  • episodic
  • semantic
  • procedural

When to use this page

Use it for questions like:

  • did the memory actually get written?
  • did it land in the expected project?
  • what type did it get stored as?
  • why is retrieval empty when I thought the data existed?

A good debugging loop

  1. Select the target project.
  2. Search for a distinctive phrase from the memory content.
  3. Narrow by memory type only if you already know what you are looking for.
  4. Check importance and timestamps.
  5. Compare what you see here against the retrieval result you expected.

Manual add is useful for one thing

The “Add Memory” flow is helpful when you want a clean, controlled test case.

It is a good way to prove:

  • the project is correct
  • the write path works
  • retrieval problems are not caused by connector ingestion or session extraction complexity

For production ingestion patterns, you will usually use the API, SDK, or session ingest flow instead.

Common mistakes

Debugging the wrong scope

The Memories page is project-scoped. If your app wrote to a different project, the page will look empty even though the write succeeded somewhere else.

Filtering too aggressively

If you do not know the memory type yet, search first and filter second.

Treating memory type as the main problem

Most first-run issues are scope or identity mismatches, not “RetainDB chose the wrong label.”

What to look for on a healthy page

  • the memory exists in the expected project
  • the content is recognizable
  • update time aligns with your test
  • high-importance items stand out as expected

Next step

If you want to see the retrieval side of the same data, go to memory search. If you want to compare memory against the originating session, use conversations workflow.

Was this page helpful?

Your feedback helps us prioritize docs improvements weekly.