# Difference Between Structural Graph View and Domain Knowledge View in the Egonex Dashboard

> Understand the Egonex dashboard's structural graph view for code architecture and the domain knowledge view for semantic relationships. Learn the key differences to navigate your data efficiently.

- Repository: [Egonex/Understand-Anything](https://github.com/Egonex-AI/Understand-Anything)
- Tags: deep-dive
- Published: 2026-06-21

---

**The structural graph view maps code architecture using ELK layered layouts to navigate files, modules, and dependencies, while the domain knowledge view employs force-directed layouts to visualize semantic relationships between extracted entities like articles, claims, and topics.**

The Egonex dashboard in the Egonex-AI/Understand-Anything repository provides two distinct visualization modes that share a single React Flow canvas. Understanding the difference between structural graph view and domain knowledge view helps developers choose the right analytical lens for exploring large codebases, whether tracing architectural dependencies or interrogating the domain meaning extracted by static analysis.

## Structural Graph View: Code Architecture Visualization

The structural graph view renders the physical and logical organization of your codebase. It answers the question: *How is the code structured?*

### Layout Algorithm and Performance Optimization

The view implements a two-stage **ELK** (Eclipse Layout Kernel) layered layout strategy defined in [`src/utils/elk-layout.ts`](https://github.com/Egonex-AI/Understand-Anything/blob/main/src/utils/elk-layout.ts). The `applyElkLayout` function first computes a *stage‑1* layout for container nodes, then executes a *stage‑2* lazy layout when users expand containers. This approach avoids recomputing the entire graph on every interaction.

Performance optimizations target large codebases through:
- **Container aggregation** that groups files into collapsible folders
- **Memoized layer statistics** to prevent redundant calculations
- **Asynchronous ELK calls** that keep the UI responsive during layout computation

### Node Types and Graph Construction

The main component [`src/components/GraphView.tsx`](https://github.com/Egonex-AI/Understand-Anything/blob/main/src/components/GraphView.tsx) consumes the `useOverviewGraph` hook (lines 31‑70) for high‑level layer clusters and `useLayerDetailGraph` (lines 96‑200 and 672‑885) for drilled‑in views. The structural view recognizes four primary node types:

- **`layer‑cluster`** – Rectangular clusters representing architectural layers
- **`container`** – Collapsible folder‑like groups of related files
- **`custom`** – Individual code artifacts (files, classes, functions)
- **`portal`** – Gateway nodes linking to other layers

Interactivity centers on architectural navigation: users can `drillIntoLayer`, expand or collapse containers, and highlight search results or diff changes without triggering full relayouts.

## Domain Knowledge View: Semantic Relationship Mapping

The domain knowledge view visualizes the *meaning* extracted from code rather than its file structure. It answers the question: *What does this code represent?*

### Force-Directed Layout and Stability

Implemented in [`src/components/KnowledgeGraphView.tsx`](https://github.com/Egonex-AI/Understand-Anything/blob/main/src/components/KnowledgeGraphView.tsx), this view uses `applyForceLayout` from [`src/utils/layout.ts`](https://github.com/Egonex-AI/Understand-Anything/blob/main/src/utils/layout.ts) (lines 51‑88) to compute a stable force‑based placement. Unlike the structural view, the layout runs only once per graph or filter change, not on selection or search operations, ensuring stable visual exploration of semantic webs.

Node dimensions derive from connectivity metrics via `getNodeDimensions`, sizing nodes proportionally to their edge counts to emphasize highly connected domain concepts.

### Knowledge Nodes and Edge Taxonomy

The domain view filters the shared `KnowledgeGraph` data structure to display only knowledge node types: `article`, `entity`, `topic`, `claim`, and `source`. These render as `custom` nodes with color coding based on semantic type.

Edge styling conveys logical relationships through the `EDGE_STYLES` map (lines 24‑34), visually distinguishing:
- **`cites`** – Typically rendered as dashed lines indicating source attribution
- **`contradicts`** – Styling that emphasizes opposing claims
- **`related`** – Standard associations between entities

## Key Technical Differences

While both views consume the same `KnowledgeGraph` type from `@understand-anything/core/types`, they diverge in implementation strategy:

- **Layout Philosophy**: The structural view uses **hierarchical ELK** layouts optimized for top‑down code organization, while the knowledge view uses **force‑directed** physics simulations that naturally cluster semantically related entities without imposed hierarchy.

- **Data Filtering**: The structural view filters for code artifacts (`type: "file" | "class" | "function"`), whereas the knowledge view filters for semantic nodes (`article`, `entity`, `topic`, `claim`, `source`).

- **Performance Strategy**: Structural optimization focuses on *container aggregation* and *async layout stages* to handle thousands of code files. Knowledge view optimization emphasizes *layout stability*, freezing positions after initial calculation to prevent jarring movements during analysis.

- **Interaction Model**: Structural interactivity supports architectural drilling (`drillIntoLayer`) and container expansion, while knowledge interactivity focuses on selecting entities to trace claim‑source relationships and contradictions.

## How View Switching Works in the Codebase

The dashboard toggles between visualizations using a `navigationLevel` state stored in the central Zustand store (`useDashboardStore`). The root [`src/App.tsx`](https://github.com/Egonex-AI/Understand-Anything/blob/main/src/App.tsx) mounts the appropriate component based on this flag:

```tsx
// src/App.tsx (excerpt)
const navigationLevel = useDashboardStore(s => s.navigationLevel);

return (
  <ReactFlowProvider>
    {navigationLevel === "graph" 
      ? <GraphView /> 
      : <KnowledgeGraphView />}
  </ReactFlowProvider>
);

```

To implement a toggle button in your own extensions:

```tsx
import { useDashboardStore } from '../store';

function ViewToggle() {
  const navigationLevel = useDashboardStore(s => s.navigationLevel);
  const setNavigationLevel = useDashboardStore(s => s.setNavigationLevel);

  return (
    <button
      onClick={() =>
        setNavigationLevel(navigationLevel === 'graph' ? 'knowledge' : 'graph')
      }
    >
      {navigationLevel === 'graph' ? 'Show Knowledge' : 'Show Structure'}
    </button>
  );
}

```

The `setNavigationLevel` action updates the store flag that [`App.tsx`](https://github.com/Egonex-AI/Understand-Anything/blob/main/App.tsx) reads to remount the canvas with the appropriate visualization engine.

## Summary

- **Structural Graph View** ([`GraphView.tsx`](https://github.com/Egonex-AI/Understand-Anything/blob/main/GraphView.tsx)) uses ELK layered layouts to visualize code architecture, supporting drill‑down navigation and container aggregation for large codebases.
- **Domain Knowledge View** ([`KnowledgeGraphView.tsx`](https://github.com/Egonex-AI/Understand-Anything/blob/main/KnowledgeGraphView.tsx)) uses force‑directed layouts to map semantic relationships between extracted entities, optimizing for stable visualization of knowledge webs.
- Both views share the `KnowledgeGraph` data model but filter for different node type subsets and apply distinct layout algorithms.
- View switching occurs at the application root via the `navigationLevel` state, which conditionally renders the appropriate React Flow canvas.

## Frequently Asked Questions

### Can I display both views simultaneously in the Egonex dashboard?

No, the current implementation uses mutual exclusion via the `navigationLevel` state in the dashboard store. The [`App.tsx`](https://github.com/Egonex-AI/Understand-Anything/blob/main/App.tsx) component renders either `GraphView` or `KnowledgeGraphView` based on this single flag, ensuring that layout calculations and interaction handlers remain specific to the active visualization mode.

### Why does the structural view use ELK while the knowledge view uses force-directed layout?

The structural view employs ELK because code architectures naturally exhibit hierarchical layering (files within folders within modules) that layered graph algorithms optimize for clarity and edge routing. The knowledge view uses force-directed layouts because semantic relationships form non‑hierarchical networks where entity proximity and clustering convey relatedness more effectively than rigid layering.

### What underlying data structure supports both visualization modes?

Both views consume the `KnowledgeGraph` type imported from `@understand-anything/core/types`. The difference lies in filtering: the structural view processes nodes with types like `file`, `class`, and `function`, while the knowledge view filters for `article`, `entity`, `topic`, `claim`, and `source` nodes. This unified model ensures consistency while allowing domain‑specific rendering.

### How does the structural view handle performance in enterprise-scale codebases?

The structural view implements a two‑stage ELK layout strategy (`applyElkLayout` in [`src/utils/elk-layout.ts`](https://github.com/Egonex-AI/Understand-Anything/blob/main/src/utils/elk-layout.ts)) that first calculates container positions, then lazily computes detailed layouts only for expanded containers. Additional optimizations include memoized layer statistics in `useOverviewGraph`, asynchronous ELK processing to prevent UI blocking, and container aggregation that collapses thousands of files into manageable clusters.