How the Domain Analyzer Extracts Business Logic from Code in Understand-Anything

The Domain Analyzer uses an LLM-driven agent to transform raw source code or structural knowledge graphs into a hierarchical business domain graph, identifying domains, flows, and implementation steps without traditional static parsing.

The Domain Analyzer in the Egonex-AI/Understand-Anything repository is a specialized component that bridges the gap between technical implementation and business concepts. Instead of relying on conventional code parsers, it leverages large language models to reason about business intent hidden in source context, converting that understanding into a well-typed JSON graph ready for visualization and further analysis.

Two Input Modes for Domain Extraction

The analyzer operates in two distinct modes depending on available data, defined in agents/domain-analyzer.md and implemented in packages/core/src/analyzer/llm-analyzer.ts.

Mode A: Pre-processed Domain Context

When no prior analysis exists, the system generates a lightweight context file. The Python script at skills/understand-domain/extract-domain-context.py scans the codebase to produce domain-context.json, capturing the file tree, entry points, imports/exports, and short code snippets. The Domain Analyzer receives this structured context and prompts the LLM to identify business domains, the flows inside each domain, and the concrete steps that implement those flows.

Mode B: Existing Knowledge Graph

If a structural analysis has already been performed, the analyzer reads knowledge-graph.json directly. The LLM ingests node summaries, tags, and relationships from the existing graph and extracts higher-level business concepts without re-parsing source files. This mode is faster and preserves cross-references established during the initial structural analysis.

The Three-Level Business Hierarchy

Regardless of input mode, extraction follows a strict three-level hierarchy enforced by the output schema:

1. Business Domain – High-level business areas (e.g., Order Management, User Authentication).
2. Business Flow – Processes within a domain (e.g., Create Order, Reset Password).
3. Business Step – Concrete actions implementing a flow (e.g., Validate Input, Check Inventory).

The LLM prompt defined in agents/domain-analyzer.md instructs the model to categorize every discovered concept into this hierarchy, ensuring consistent granularity across the entire codebase.

Output Schema and Validation

The Domain Analyzer produces JSON conforming to a strict schema defined in packages/core/src/schema.ts. This validation layer guarantees:

• Kebab-case IDs following the pattern domain:order-management, flow:create-order, or step:create-order:validate-input.
• Mandatory metadata including summary, tags, and complexity fields for every node.
• Typed relationships using specific edge types: contains_flow (domain to flow), flow_step (flow to step), and cross_domain (inter-domain dependencies).
• Monotonically increasing weights on edges to preserve step ordering within flows.
• Optional domainMeta objects capturing entities, business rules, and entry points (e.g., POST /api/orders).

The schema validator also normalizes aliases (e.g., mapping business_domain to domain) to ensure downstream compatibility.

From LLM Response to Persisted Graph

After the LLM generates the domain graph structure, the core pipeline validates it against the TypeScript schema in packages/core/src/schema.ts. Once validated, the persistence layer at packages/core/src/persistence/index.ts writes the normalized graph to .understand-anything/intermediate/domain-graph.json. This file powers the dashboard's Domain view and serves as the source of truth for business-oriented queries.

{
  "nodes": [
    {
      "id": "domain:order-management",
      "type": "domain",
      "name": "Order Management",
      "summary": "Handles creation, update and cancellation of orders.",
      "tags": ["order", "ecommerce"],
      "complexity": "moderate",
      "domainMeta": {
        "entities": ["Order", "Cart", "Product"],
        "businessRules": ["order must have a valid payment", "stock must be checked"]
      }
    },
    {
      "id": "flow:create-order",
      "type": "flow",
      "name": "Create Order",
      "summary": "Creates a new order from a shopping cart.",
      "tags": ["create", "http"],
      "complexity": "simple",
      "domainMeta": {
        "entryPoint": "POST /api/orders",
        "entryType": "http"
      }
    },
    {
      "id": "step:create-order:validate-input",
      "type": "step",
      "name": "Validate Input",
      "summary": "Ensures request payload contains required fields.",
      "tags": ["validation"],
      "complexity": "simple",
      "filePath": "src/orders/create.ts",
      "lineRange": [12, 28]
    }
  ],
  "edges": [
    { "source": "domain:order-management", "target": "flow:create-order", "type": "contains_flow", "direction": "forward", "weight": 1.0 },
    { "source": "flow:create-order", "target": "step:create-order:validate-input", "type": "flow_step", "direction": "forward", "weight": 0.1 }
  ]
}

Running the Domain Analyzer

Execute the analysis commands from your project root to extract business logic:

# Generate the structural knowledge graph (required for Mode B, optional for Mode A)

/understand

# Extract business domains (automatically selects Mode A or B based on available files)

/understand-domain

The packages/core/src/__tests__/domain-types.test.ts file contains unit tests validating that domain nodes, edges, and metadata are correctly processed throughout this pipeline.

Summary

• The Domain Analyzer does not parse code directly; it relies on pre-generated context files or existing structural graphs.
• Extraction follows a three-level hierarchy: Business Domain → Business Flow → Business Step.
• Two operation modes exist: Mode A (context file from Python preprocessor) and Mode B (existing knowledge graph).
• Output is validated against packages/core/src/schema.ts and persisted to domain-graph.json.

Frequently Asked Questions

Does the Domain Analyzer parse source code directly?

No. According to the Egonex-AI/Understand-Anything source code, the analyzer relies on either a pre-generated domain-context.json file or an existing knowledge-graph.json. The LLM reasons about business intent from these structured contexts rather than parsing raw AST or source files directly.

What is the difference between a knowledge graph and a domain graph?

The knowledge graph (knowledge-graph.json) represents structural code relationships such as function calls, imports, and file dependencies. The domain graph (domain-graph.json) is a higher-level abstraction containing business domains, flows, and steps. The Domain Analyzer transforms structural knowledge into business concepts using the LLM.

How does the analyzer maintain step ordering in business flows?

The output schema enforces monotonically increasing weight values on edges of type flow_step. As the LLM identifies steps within a flow, the system assigns increasing weights to ensure the dashboard can reconstruct the correct execution sequence when visualizing business processes.

Where is the domain graph stored after extraction?

After validation in packages/core/src/schema.ts, the persistence layer at packages/core/src/persistence/index.ts writes the final graph to .understand-anything/intermediate/domain-graph.json. This location serves as the source for the dashboard's Domain view and subsequent business logic queries.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}