> ## Documentation Index > Fetch the complete documentation index at: https://docs.cognee.ai/llms.txt > Use this file to discover all available pages before exploring further. # Memory Coverage in the Cloud UI > Score every question your agents asked by how well memory answered it, and find the gaps The Memory Coverage page (route `/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](/cognee-cloud/ui/datasets), and **Run analysis**. Open it from the [Overview](/cognee-cloud/ui/dashboard)'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](/cognee-cloud/local-ui#cloud-only-pages). ## 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: It gathers the [recall](/core-concepts/main-operations/recall) traffic against the selected dataset — every question your agents and your own searches put to it. 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. 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. 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. Each run also assigns every question to a topic, so the score can be read per subject area rather than only in aggregate. ## 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: | Band | Score | Verdict | | ----- | --------- | ----------- | | Red | 0.0 – 1.9 | **Gap** | | Amber | 2.0 – 3.9 | **Partial** | | Green | 4.0 – 5.0 | **Covered** | 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](/cognee-cloud/ui/dashboard) 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. A run that produced no score says which of the several possible reasons applies, rather than showing `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`, or `5/12` when 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. Each question shows its score chip in the band colour, a lavender **recall** chip counting how often it was asked in the window (*the size of its dedup cluster, not a forecast*), and its topic. An unmeasured question shows a neutral dash with the tooltip *Not measured: this question's replay or judge call failed* — never a `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. A topic deletion is not saved yet. It applies only to the browser tab you are looking at — a reload, a workspace switch (which is a full page reload), or the next run brings the topic back. Switching datasets and back does not: the edit is held per dataset, so the deletion is still there when you return. While it holds, its questions count under **Other**, which also changes the score on this page, since **Other** counts as a topic here. ## Empty and error states Each state names a different fact, because the next step differs: | State | What you see | | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | No dataset in the workspace | *Add a dataset and ask it something — this page scores every question by how well memory answered it.* | | Dataset never scored | *{dataset} has not been scored yet. Run analysis replays every question it was asked and scores how well memory answered.* | | The fetch failed | **Couldn't load coverage for {dataset}** — *The workspace didn't answer. Nothing is lost — any run it has already scored is still there.* with **Retry**. | | A refresh failed, older run in hand | **Couldn't refresh {dataset}.** *This is the last run we have, so it may be out of date.* with **Retry** — the previous run stays on screen. | | **Run analysis** was rejected | **Couldn't start the run.** with the reason and **Try again**, above the run it failed to replace. | Coverage runs appear in [Activity](/cognee-cloud/ui/activity) as `recall` operations named `coverage_run`: replaying a question reads from memory and writes nothing.