> ## 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. # Reading the Visualization > What each tab of a rendered graph shows, and which one to reach for Every file `visualize_graph()` writes is a self-contained HTML page that opens with a tab bar of four views — **Graph**, **Schema**, **Memory**, and **Semantic** — all computed from the same graph payload. No server, no rebuild: switching tabs re-reads data the page already carries. This page explains what each view shows and when to reach for it. To generate a file in the first place, start with [Graph Visualization](/guides/graph-visualization). ## The tab bar | Tab | What it shows | Reach for it when | | ------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Graph** | Nodes and edges laid out by structure, with layout, label, and color controls | You want to explore the graph itself — follow relationships, find a node, spot a cluster | | **Schema** | A by-type summary: instance counts per semantic type and how types connect | You want to know what *kinds* of things are in memory, not which individual ones | | **Memory** | A deterministic map of how the memory was built, plus the run timeline | You want to audit the pipeline — which document produced which chunks and entities | | **Semantic** | Nodes placed by the 2-D projection of their embeddings | You want meaning-space neighborhoods rather than edge-based structure | Everything below describes the rendered artifact. The graph's *content* — which nodes and edges make it into the file at all — is controlled when you render it; see [bounded subgraphs](/guides/graph-visualization#advanced-usage). ## Graph — classic topology The default view: nodes and edges laid out by structure. Drag nodes, zoom/pan, and hover edges for details. A control bar at the bottom groups three sets of toggles, each with an explanatory tooltip on hover, plus zoom out / zoom in / **Fit to view** buttons. ### Layout modes The three layout buttons change only where nodes are drawn — never which nodes or edges are in the render. | Mode | How it positions nodes | Use it when | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Story** (default) | Fixed pipeline columns — Documents → Chunks → Entities → Types → Summaries (plus Context, Schema, and Other when present), each column labeled with its node count. Nodes are pinned on both axes in a readable grid. | You want to read how raw data became memory, stage by stage, or you need a stable layout that renders the same way every time (screenshots, comparing two runs). | | **Flow** | Columns follow processing order, pulling nodes horizontally. Nothing is pinned — vertical position is only weakly anchored, so link forces let nodes settle next to whatever they connect to. | You want to keep the left-to-right pipeline reading order while letting related nodes drift together vertically. | | **Force** | No columns. A physics simulation pulls connected nodes together: semantic edges pull tighter than structural ones (containment, `is_a`, summarization), and high-degree hubs repel more strongly so they stop occluding their neighbors. | You want to spot clusters, hubs, and unexpected connections rather than follow the pipeline. Drag nodes to pull a cluster apart and explore it. | Story mode needs at least two pipeline stages in the render to draw its columns; on a graph with only one stage it falls back to Flow's column layout. ### Label budget The label budget controls how many node labels are drawn at once — on a dense graph, labeling everything is unreadable. * **Key** (default) — landmark nodes plus high-importance entities. * **All** — every node. * **Off** — labels hidden; hover a node to peek at its label. ### Node labels Node labels are always human-readable — raw UUID- or content-hash-shaped values are never used as a display name. When a node has no readable `name`, the label falls back through its `title`, `text`, `summary`, `description`, or `content`. If none of those is usable it shows an explicit placeholder in the form `Unnamed (id8)` — for example `Unnamed Entity (a1b2c3d4)`, where `id8` is the first eight characters of the node id. Nodes that only have a placeholder name are never chosen as **Key**-mode label landmarks. ### Color by, legend, and stats Nodes can be recolored by **Type** (default), **Node set**, or **User**. A **Color by** mode is disabled, with an explanatory tooltip, when the graph carries no provenance for it — **Node set** shows *"No node sets in this graph"* and **User** shows *"No user provenance in this graph"* — rather than coloring every node the same "Unknown" gray. For the same reason the stats line counts only provenance that is present, so a graph with no node sets reports `0 node sets` instead of counting the absence as one. In **Type** mode the legend swatches are sampled from the colors actually drawn on the nodes, so the legend can never disagree with the canvas. The legend lists at most the eight largest groups. Coloring by **Node set** is the fastest way to see how a [node-set grouping](/guides/nodeset-grouping) actually partitioned your graph. ### Searching the graph Type in the search box to highlight nodes whose name or type match. A live counter beside the box shows how many nodes matched (e.g. `18 matches`). Press **Enter** to jump to the best match and pan/zoom to it; each subsequent **Enter** cycles forward through the matches (the counter updates to `1 / 18`, `2 / 18`, …), and **Shift+Enter** cycles backward. Press **Escape** to clear the search and its highlights. ## Schema — types at a glance A by-type summary of the rendered graph: instance counts per semantic type and the relationship distribution between types, computed at render time. **Type boxes and instance mini-cards.** Each semantic type (e.g. *Person*, *Broker*, *Tool*) is shown as a box with its instance count, a few representative instance mini-cards, and the relationships connecting it to other types. When a type has more instances than fit, a **`+ N more`** toggle expands the full instance list, switching to **Show less** to collapse it again. **Bounded Entity column.** Every distinct semantic entity type the LLM extracts becomes its own card, so on large graphs that column could grow without bound. Once a graph has more than **12** semantic entity types, the 11 most-populated keep their own cards and the remaining long tail collapses into a single **`Other entities`** rollup card. The rollup leads with the number of rolled-up types and its largest members (e.g. `8 rolled up: Animal (5), Vehicle (3), …`) and otherwise behaves like a normal type box — its instance count, drill-down, and relationship edges aggregate every rolled-up type. Graphs at or below 12 entity types are shown unchanged, with no rollup card. **Instance inspector.** Click a type box to open the inspector side panel for that type, or an instance mini-card to drill into a single instance. The inspector then shows a breadcrumb (`‹ Type`) back to the type-level view and a close (`×`) control to dismiss the panel. **Click-to-spotlight.** Clicking a type box, edge card, or operation chip spotlights the related elements on the canvas. The schema canvas supports pan/drag and mouse-wheel zoom, and the spotlight overlay tracks elements as you move around. **Operations-impact overlay.** A rail of operation chips — `cognify`, `memify (triplets)`, `improve (self-improve)`, `feedback weighting`, `forget`, and others — maps cognee operations onto the schema types they touch. Clicking a chip highlights the affected types, color-coded by effect: * **produces** — the operation creates instances of this type (`cognify` produces `TextDocument`, `DocumentChunk`, `Entity`, `EntityType`, and `TextSummary`). * **enriches** — it augments existing instances (`memify (triplets)` enriches `Entity`). * **modifies** — it changes a property on existing instances (feedback and frequency weighting update `feedback_weight` / `frequency_weight`). * **removes** — it deletes instances of this type (`forget`). The same projection is available as a standalone data API with its own HTTP endpoint — useful for driving dashboards without rendering HTML. See [Schema Inventory](/guides/schema-inventory). ## Memory — pipeline structure A deterministic map of how the memory was built: documents, their chunks, and the entities extracted from them, plus the run timeline. Every list is ordered by keys intrinsic to the data, so the layout is reproducible and append-stable as the graph grows. Not to be confused with [Memory Provenance](/guides/memory-provenance), which is a separate projection of the relational database — tenants, users, agents, datasets, files — rendered to its own HTML file rather than a tab in this one. ## Semantic — layout by meaning Instead of laying nodes out by their edges, the Semantic tab places each node at the 2‑D projection of its embedding, so semantically similar nodes sit together and clusters of related entities become visible at a glance. It reuses the vectors Cognee already stored during `cognify()` — nothing is re‑embedded at render time on the default LanceDB backend, and only 2‑D positions and precomputed neighbor lists are sent to the browser. Click **Semantic** in the tab bar, or append `#semantic` to the file URL to deep‑link straight to it. In the tab you can: * **Cluster / Type** — toggle recoloring nodes by semantic cluster or by ontology type. * **Hover** a node to light up its nearest neighbors and list its relations. * **Legend** entries filter to a single cluster or type; scroll or use the on‑screen controls to zoom. * **Semantic ⇄ Structural** — toggle between the pinned meaning‑space layout and a bounded force layout over the graph topology. * **Recall overlay** — light up the nodes a past recall query retrieved. **Choosing the projection.** By default the layout uses **PCA** (pure‑numpy, sign‑stabilized), which is deterministic — the same graph always renders the same layout. To use **UMAP** instead, install it and opt in with an environment variable: ```bash theme={null} pip install umap-learn export SEMANTIC_MAP_PROJECTION=umap ``` UMAP is an optional dependency and a lazy import — when `umap-learn` is not installed, the layout silently falls back to PCA. The Semantic tab is best‑effort: if embeddings can't be fetched or the projection fails, the tab shows a friendly empty state and the classic render is never affected. Nodes that have no stored vector are placed at the centroid of their positioned neighbors. **Behavior on large graphs.** The semantic layout and clustering are bounded to **2000 nodes** (`SEMANTIC_NODE_CAP`). Graphs above that are reduced with a deterministic seeded sample, so results are approximate at scale but stable across runs. When sampling kicks in, a warning is logged. When vectors are fetched, an info‑level log reports the join hit‑rate, e.g. `resolved 128/150 node embeddings across 4 collection(s)`. If nothing resolves (a blank Semantic map), a warning names the missing collections and unmapped node types — the usual cause of a blank map is an id/collection‑name mismatch rather than a silent failure. ## Light and dark theme A **Dark mode** toggle in the top-right corner switches between the light and dark themes. Toggling repaints the graph canvas immediately, and the Schema view re-renders its palette so cards, chips, and edges follow the active theme. Your choice is remembered across reloads — it is persisted in the browser's `localStorage` under the key `cognee-viz-theme` and applied before the first paint, so the visualization opens in the theme you last used, defaulting to light on first visit. Render a file, seed the view from a query, and bound large graphs. The Schema tab's projection as a standalone data API. Tenants, users, agents, datasets, and files as their own HTML file.