Skip to main content

Overview

Nectr builds a Neo4j knowledge graph that tracks code ownership, file relationships, and PR history. The graph is used to answer questions like:
  • Who are the experts on these files?
  • What past PRs touched the same code?
  • Which files are high-risk (frequent bug fixes)?
  • Which files are dead (never touched by any PR)?
The graph is built incrementally: Repository + File nodes are created when you connect a repo, and PullRequest + Developer nodes are added after each review.
The knowledge graph provides structural context (who touched what) while Mem0 provides semantic context (what patterns exist). Together they power Nectr’s contextual intelligence.

Schema

Node Types

Properties:
  • full_name (string, unique): "owner/repo"
  • scanned_at (datetime): Last time file tree was rebuilt
Created: When you connect a repo via /api/v1/repos/{owner}/{repo}/installUpdated: When you rescan via /api/v1/repos/{owner}/{repo}/rescan
Properties:
  • repo (string): "owner/repo"
  • path (string): Repo-relative path, e.g. "app/services/pr_review_service.py"
  • language (string): Inferred from extension (Python, JavaScript, TypeScript, etc.)
  • size (integer): File size in bytes
Unique constraint: (repo, path)Created: On repo connect (full recursive tree from GitHub)Updated: On rescan (stale files deleted, new files added)
Properties:
  • repo (string): "owner/repo"
  • number (integer): PR number
  • title (string): PR title
  • author (string): GitHub username
  • verdict (string): "APPROVE" | "REQUEST_CHANGES" | "NEEDS_DISCUSSION"
  • reviewed_at (datetime): When Nectr posted the review
Unique constraint: (repo, number)Created: After each PR review is posted
Properties:
  • login (string, unique): GitHub username
Created: When a PR is indexed and the author doesn’t exist yet
Properties:
  • repo (string): "owner/repo"
  • number (integer): Issue number
Unique constraint: (repo, number)Created: When a PR references an issue via Fixes #N, Closes #N, or semantic match

Edge Types

CONTAINS

(Repository)-[:CONTAINS]->(File)Links a repository to all files in its tree

TOUCHES

(PullRequest)-[:TOUCHES]->(File)Links a PR to every file it modified

AUTHORED_BY

(PullRequest)-[:AUTHORED_BY]->(Developer)Links a PR to its author

CONTRIBUTED_TO

(Developer)-[:CONTRIBUTED_TO]->(Repository)Tracks which developers have contributed to which repos

CLOSES

(PullRequest)-[:CLOSES]->(Issue)Links a PR to issues it resolves

Graph Operations

Build Repo Graph

Called when you connect a repo (and on manual rescan). Fetches the full recursive file tree from GitHub and creates Repository + File nodes + CONTAINS edges.
Performance: Processes 200 files per batch. A 5000-file repo takes ~3 seconds.
GitHub caps the recursive tree API at ~100k nodes. For monorepos, the tree may be truncated. Nectr logs a warning but continues with the partial set.

Index PR

Called after each PR review. Creates PullRequest + Developer nodes and edges (TOUCHES, AUTHORED_BY, CLOSES, CONTRIBUTED_TO).
Race condition fix: Uses MERGE for Repository node (not MATCH) so CONTRIBUTED_TO edge is never silently dropped if index_pr() runs before build_repo_graph() completes.

Query Operations

Get File Experts

Returns developers who have most frequently touched the given files.
Example result:
Returns past PRs that touched the same files (structural similarity).
Example result:

Get Linked Issues

Batch-fetch Issue nodes and which PRs closed them.
Example result:

Analytics Queries

The knowledge graph powers the Analytics dashboard with insights like:

File Hotspots

Files touched by the most PRs (high churn / high importance).

High-Risk Files

Files that repeatedly get REQUEST_CHANGES verdict (fragile, needs attention).

Dead Files

Files in the repo never touched by any reviewed PR (potentially stale/unused).

Code Ownership

For each heavily-touched file, who is the dominant contributor.

Developer Expertise

Per developer: which top-level directories they contribute to most.

Configuration

Neo4j Connection

Set these environment variables:

Graceful Degradation

If Neo4j is unavailable, Nectr silently skips graph queries and continues with Mem0 context only. PR reviews still work.

Performance

Repo Scan

5000 files: ~3 seconds20000 files: ~12 secondsBatch size: 200 files per write

Query Latency

File experts: 10-50msRelated PRs: 20-100msAnalytics (complex): 100-500ms

Constraints & Indexes

Nectr creates constraints and indexes on startup to ensure fast queries:
  • app/services/graph_builder.py — All Neo4j operations (view source)
  • app/core/neo4j_client.py — Async driver singleton (view source)
  • app/core/neo4j_schema.py — Constraints + indexes (view source)