/memory-gap-analysis) replays the questions your workspace was actually asked and scores each one by how well memory answered it. Low scores are your gaps — the page exists to point at the knowledge worth adding next.
Its header states that plainly: Every question you asked, scored by how well memory answered it. Low scores are your gaps — add the missing knowledge to fix them. Two actions sit beside it: Add memory, which opens Datasets, and Run analysis.
Open it from the Overview’s Memory Coverage panel — clicking a dataset row there opens this page already scoped to that dataset.
Memory Coverage is a Cognee Cloud feature. In the local, open-source UI the route renders a notice instead of the analysis — see Local UI.
How coverage is measured
A coverage run is not a synthetic benchmark — it is built from the questions your workspace was really asked. A run does four things:1
Collect
It gathers the recall traffic against the selected dataset — every question your agents and your own searches put to it.
2
Dedupe
Near-identical questions are clustered into one entry. The cluster’s size becomes that question’s recall count: observed demand, not a forecast. Asking the same thing forty times makes it one question with a count of forty, so a much-asked gap cannot hide behind a long tail of one-offs.
3
Replay
Each deduped question is put back through recall against the graph as it stands now. That is the point of replaying rather than re-reading the original answers: the score describes the memory you have today, including everything ingested since the question was first asked.
4
Judge
An LLM judge scores each replayed answer from 0 to 5 — 0–1 nothing usable was retrieved, 2–3 partially answered, 4–5 answered. A question whose replay or judge call fails reaches no verdict and is left out of every average rather than counted as a zero.
Running an analysis
Run analysis replays every question the selected dataset was asked and scores the answers with an LLM judge. A run covers the whole corpus, so it takes a few minutes; the button reads Starting… and then Running… while it works. Everything on the page stays fully readable and interactive during a run — you can filter, search, and export the previous run while the new one computes. A status line says so out loud: Run in progress. Replaying every question takes a few minutes. Everything below is the previous run until it finishes. The page polls the run every four seconds until it settles.The score
A full-width meter carries the score for the selected dataset, out of 5.0, with the number riding the fill edge in its band colour:
The number is an unweighted mean of the topic averages, and each topic average is the mean of that topic’s measured questions. Topics therefore count equally: a topic holding four questions moves the score as much as one holding forty. That is deliberate — it keeps a single busy subject area from burying a small one that answers nothing.
This page counts Other as a topic, so questions that matched no topic weigh on the score like any other bucket. The Real recall figure on the Overview panel is the workspace roll-up and excludes Other, then averages across datasets that have a score. The two numbers can differ for the same dataset, and neither is wrong — they answer different questions.
0.0: Scoring… while pending or running, No questions yet for a completed run that replayed nothing, Run failed, or No verdict reached when questions were replayed but none reached a verdict — an outage in the judge or the pod rather than a dataset that answers badly.
Sample size
Directly under the meter, a line says what the score actually covers — Covers 38 of 50 questions. A score of 4.6 over five measured questions of fifty is not the claim that 4.6 over fifty would be, so the count is always stated. When a fifth or more of the corpus reached no verdict the line turns amber and adds why it matters: 12 reached no verdict, so this score does not describe the rest of the dataset. Questions whose replay or judge call failed are excluded from the average rather than averaged in as zero.Datasets
A dataset switcher sits under the score. A coverage run is always scoped to one dataset, so switching datasets shows that dataset’s latest run. Each chip carries the dataset name and its own coverage score in the band colour — a neutral — when it has none, and ! when that dataset’s coverage could not be loaded, so one unreachable dataset never makes the others look unscored. Hovering a chip adds a note about its run: Loading…, Not scored yet, Couldn’t load this dataset’s coverage, a sample caveat such as Coverage 4.6 of 5, or — when 20% or more of the dataset’s questions match no topic — 43% of questions match no topic, a signal that the topics need work, since a large Other bucket makes the per-topic scores less useful. The sample caveat outranks the topic warning: a score that does not describe the corpus is the more important thing to say first.Questions
The questions panel holds the run’s replayed questions, and its frame is labelled with the current topic (or Questions when no topic is selected).- Topic chips filter the questions by topic and show how many questions the topic holds —
12, or5/12when only some of them were scored, with the number turning amber once a fifth or more went unscored. They do not show a score. Topics belong to you and persist across runs; each run assigns its questions to them, and anything that matches none confidently lands in Other. - View toggle switches between a card grid and a dense list; the list is the default.
- Export writes the questions currently in view to CSV, with the columns Question, Coverage, Relevance, Topic, First asked, Reference, and Replayed answer — so the answer memory actually gave, and the source it drew on, come out with the score even though the cards do not show them.
- Search questions is stemmed and prefix-tolerant, and searches four fields: the question text, the replayed answer, the topic label, and the reference.
- Sort offers Score (worst first — your gaps) and Recalls (most-asked first).
- A Recall readout on the right of the toolbar totals the recalls behind whatever is currently filtered, and is relabelled Topic Recall while a topic chip is selected.
0.0, which would read as memory answered nothing.
Which run you are looking at
A footnote under the questions panel identifies the run on screen — Run id, Status, and Created date — alongside the band legend (Gap 0–1.9, Partial 2.0–3.9, Covered 4.0–5.0). It is the quickest way to check whether the figures above came from a finished run.Deleting a topic
A topic chip can be deleted. The confirm dialog is explicit that nothing is lost: the questions move back to Other, and the next run may group them again.Empty and error states
Each state names a different fact, because the next step differs:Coverage runs appear in Activity as
recall operations named coverage_run: replaying a question reads from memory and writes nothing.