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

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 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 at lines 101-110. Here, the NodeType class extends StrEnum to provide type-safe string constants that the parser assigns to every extracted symbol.

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 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 module leverages these types for targeted queries. For example, you can filter the function registry to retrieve only class definitions or interface implementations.

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:

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 and serves as the central authority for symbol classification.
• codebase_rag/schema_builder.py consumes these types during graph construction, while 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 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 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.

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