Graph

Graph manages tenant-scoped knowledge-graph access in a shared Neo4j store, scoping every operation to an org-verified projectId. Through GraphController and KnowledgeGraphService, it creates and deletes entities and relationships, retrieves related entities and relationship sets, finds shortest paths, searches, extracts entities from documents, detects development flow and change impact, and reports graph statistics. KgSyncController and KgSyncService handle CLI dynamic-mode bulk synchronization while rejecting invalid projects, types, paths, and missing records.

41 entities in atloria-monorepo/apps/api/src/graph. 5 other subsystems depend on it, which makes it the 12th most depended-upon part of this codebase.

What it is made of

Its 41 entities sit in 13 files under atloria-monorepo/apps/api/src/graph: 18 HTTP endpoints, 8 classes, 5 services, 5 interfaces and 5 more. graph.controller.ts holds 13 of them — more than any other file here. KnowledgeGraphService declares 9 methods, the widest surface here.

Where work enters

2 controllers publish 18 HTTP endpoints — 12 GET, 5 POST and 1 DELETE. They answer under /knowledge-graph and /projects/:projectId. GraphController carries 12 of them; the remaining 6 are split across 1 other controller. Every one of them declares a guard — JwtAuthGuard on 18 and ResourceOrgGuard on 18.

• GraphController — atloria-monorepo/apps/api/src/graph/graph.controller.ts:28
• createEntity — atloria-monorepo/apps/api/src/graph/graph.controller.ts:39
• createRelation — atloria-monorepo/apps/api/src/graph/graph.controller.ts:48
• getEntity — atloria-monorepo/apps/api/src/graph/graph.controller.ts:59
• getRelated — atloria-monorepo/apps/api/src/graph/graph.controller.ts:70
• getRelationships — atloria-monorepo/apps/api/src/graph/graph.controller.ts:97

How work moves through it

mermaid
flowchart LR
  GraphController0["GraphController"]
  EntityExtractorService10["EntityExtractorService"]
  GraphController0 --> EntityExtractorService10
  FlowDetectorService11["FlowDetectorService"]
  GraphController0 --> FlowDetectorService11
  PrismaService20["PrismaService"]
  EntityExtractorService10 --> PrismaService20
  AIService21["AIService"]
  EntityExtractorService10 --> AIService21
  AzureClaudeProvider30["AzureClaudeProvider"]
  AIService21 --> AzureClaudeProvider30
  AzureOpenAIProvider31["AzureOpenAIProvider"]
  AIService21 --> AzureOpenAIProvider31
  stop["refused"]
  AIService21 -. "NotFoundException" .-> stop

Work enters at GraphController and passes through 6 other components. Each step below is a dependency edge between two entities in this repository, followed outward in order.

1. GraphController takes the work first — atloria-monorepo/apps/api/src/graph/graph.controller.ts:28.
2. Next, GraphController calls EntityExtractorService and FlowDetectorService.
3. Then, EntityExtractorService calls PrismaService and AIService.
4. Finally, AIService calls AzureClaudeProvider and AzureOpenAIProvider.

Where the work stops

• AIService stops the work with NotFoundException when !document — “Document not found”, in 2 places.
• AIService stops the work with NotFoundException when !provider.
• AzureClaudeProvider stops the work with Error when !projectEndpoint — “Azure AI Project configuration missing. Please set AZURE_EXISTING_AIPROJECT_ENDPOINT”.

When a step fails

• EntityExtractorService handles failure in 2 places: it logs it and continues in 1, and turns it into a return value in 1.
• PrismaService handles failure in 1 place: it lets it reach the caller in all 1.
• AzureClaudeProvider handles failure in 5 places: it turns it into a return value in 2, lets it reach the caller in 2, and logs it and continues in 1.
• AzureOpenAIProvider handles failure in 4 places: it lets it reach the caller in 2, logs it and continues in 1, and turns it into a return value in 1.

How it refuses and fails

4 of its components record a refusal or a failure handler. 3 of them refuse work outright, under a condition written into the component itself. Their catch blocks handle a failure that already happened in 7 places. Of those 7, 6 log it and continue and 1 turns it into a return value.

Boundaries

5 other subsystems depend on this one — Api, Documentation, Project, Technical Docs, Workflow. Changing what it exposes changes them.

Those 5 hold 9 edges between them, unevenly: Documentation reaches in across 2 edges, while another holds one. 11 edges leave it against 9 arriving — it reads more of this repository than this repository reads of it. What they reach is narrower than the folder: 3 of its 41 members carry every inbound edge — GraphModule (5), Neo4jService (3) and KgSyncService (1). Of the 11 it sends out, 6 go to Workflow — more than to any other.

It depends on Database, Ai, Workflow, and on nothing else in this repository.

How this code is named

These conventions cover most of the codebase. Learning them is faster than reading an index — each one lets you find any member of its family without looking it up.