# What Are the Node Types in the Code-Graph-RAG Knowledge Graph Schema?

> Explore the nine node types in the Code-Graph-RAG knowledge graph schema including FUNCTION, METHOD, and CLASS. Standardize code representation for any programming language.

- Repository: [Vitali Avagyan/code-graph-rag](https://github.com/vitali87/code-graph-rag)
- Tags: api-reference
- Published: 2026-09-08

---

**The Code-Graph-RAG knowledge graph schema defines nine distinct node types—FUNCTION, METHOD, CLASS, MODULE, INTERFACE, PACKAGE, ENUM, TYPE, and UNION—in the `NodeType` StrEnum located in [`codebase_rag/types_defs.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/types_defs.py) to standardize code representation across multiple programming languages.**

Code-Graph-RAG is an open-source repository that constructs knowledge graphs from diverse codebases. The system uses a unified schema to classify code symbols regardless of whether they originate from Python, TypeScript, Rust, or other supported languages. Understanding these node types is essential for querying the graph or extending the parser to support additional languages.

## The NodeType StrEnum Definition

The canonical definition of all node types resides in [`codebase_rag/types_defs.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/types_defs.py) at lines 101-110. Here, the `NodeType` class extends `StrEnum` to provide type-safe string constants that the parser assigns to every extracted symbol.

```python
from codebase_rag.types_defs import NodeType

# Each node type is a string enum value

print(NodeType.FUNCTION)  # 'FUNCTION'

print(NodeType.CLASS)     # 'CLASS'

```

These constants provide a uniform interface for the graph construction pipeline, ensuring that symbols from different languages receive consistent semantic labels.

## The Nine Node Types Explained

The schema categorizes every discovered symbol into one of the following nine types:

| Node Type | Description | Example Source Element |
|-----------|-------------|------------------------|
| **FUNCTION** | A stand-alone function that exists outside of class boundaries. | `def calculate(): ...` |
| **METHOD** | A function bound to a class or struct, including static and instance methods. | `class User: def save(self): ...` |
| **CLASS** | Object-oriented class definitions or struct declarations. | `class DataProcessor: ...` |
| **MODULE** | Namespace containers such as Python modules or TypeScript modules. | `module utils { ... }` |
| **INTERFACE** | Contracts defining behavior without implementation, such as traits or interfaces. | `interface Logger { ... }` |
| **PACKAGE** | Top-level organizational units that may contain multiple modules. | `package com.example;` |
| **ENUM** | Enumerations of named constant values. | `enum Status { ACTIVE, INACTIVE }` |
| **TYPE** | Type aliases and user-defined types that are not classes or enums. | `type ID = string;` |
| **UNION** | Union types that can represent one of several possible types. | `type Result = Success \| Failure;` |

This classification enables the system to reason about code structure uniformly, whether analyzing a Python `def` statement or a Rust `impl` block.

## How Node Types Power Graph Construction

During ingestion, the parser in [`codebase_rag/schema_builder.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/schema_builder.py) tags each symbol with its appropriate `NodeType`. This tagging process drives the construction of the knowledge graph's vertices and determines how relationships (edges) are formed between entities.

The [`codebase_rag/services/graph_service.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/services/graph_service.py) module leverages these types for targeted queries. For example, you can filter the function registry to retrieve only class definitions or interface implementations.

```python
from codebase_rag.types_defs import NodeType

def get_node_names(ingestor, node_type: NodeType) -> list[str]:
    """Return all qualified names of a given NodeType."""
    return [
        qualified_name 
        for qualified_name, typ in ingestor.function_registry.items() 
        if typ == node_type
    ]

# Retrieve specific symbol categories

class_names = get_node_names(ingestor, NodeType.CLASS)
enum_names = get_node_names(ingestor, NodeType.ENUM)
interface_names = get_node_names(ingestor, NodeType.INTERFACE)

```

## Practical Usage Examples

When extending Code-Graph-RAG or building custom analysis tools, you interact with `NodeType` constants to register or filter symbols. The following example demonstrates populating a simple registry with qualified names mapped to their node types:

```python
from codebase_rag.types_defs import NodeType

# Simulating the function registry used during indexing

registry = {}
registry["my_app.services.auth.authenticate"] = NodeType.FUNCTION
registry["my_app.models.user.User"] = NodeType.CLASS
registry["my_app.utils"] = NodeType.MODULE
registry["my_app.interfaces.database"] = NodeType.INTERFACE

```

Each key represents a fully qualified symbol path, while the value ensures the graph construction logic applies the correct semantic rules for that category of code element.

## Summary

- **Nine distinct node types**—FUNCTION, METHOD, CLASS, MODULE, INTERFACE, PACKAGE, ENUM, TYPE, and UNION—standardize code representation across languages.
- The **`NodeType` StrEnum** is defined in [`codebase_rag/types_defs.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/types_defs.py) and serves as the central authority for symbol classification.
- **[`codebase_rag/schema_builder.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/schema_builder.py)** consumes these types during graph construction, while **[`codebase_rag/services/graph_service.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/services/graph_service.py)** enables type-specific querying.
- These classifications support **cross-language analysis** including Python, TypeScript, Rust, Scala, and Java.

## Frequently Asked Questions

### Where are the node types defined in the Code-Graph-RAG repository?

The node types are defined in [`codebase_rag/types_defs.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/types_defs.py) as a `StrEnum` named `NodeType` at lines 101-110. This file serves as the central type definition module used throughout the ingestion and graph construction pipeline.

### What is the difference between FUNCTION and METHOD node types?

**FUNCTION** identifies stand-alone functions that exist at module or global scope, while **METHOD** specifically denotes functions that are members of a class or struct. The distinction allows the graph to differentiate between utility functions and object-oriented behavior.

### How does the system use NodeType during graph queries?

The [`codebase_rag/services/graph_service.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/services/graph_service.py) module uses `NodeType` values to filter and retrieve specific categories of symbols from the function registry. This enables precise queries such as retrieving all interfaces or enumerations without scanning unrelated nodes.

### Which programming languages does this schema support?

The schema is language-agnostic and currently supports Python, TypeScript, Rust, Scala, and Java. The nine node types abstract away language-specific syntax differences, allowing uniform graph construction regardless of the source language.