Internals

Everything in the earlier architecture pages runs on one component: the engine. This page is a short, honest map of it.

One engine, several front doors

src/engine owns the deterministic core — detection, extraction, graph building, analysis, and daemon operations. The CLI, daemon, thin client, and MCP server are thin programs around it. Critically, tool calls from the MCP server route through the same daemon operation handler used by the thin client, so there is one code path for answering an operation, not several.

cgraph / graphd / cgraph-client / cgraph-mcp
                    |
             one operation handler
                    |
                 engine
        detect · extract · build · analyze

Determinism as an invariant

Extraction is deterministic: identical input trees produce identical graphs. This is not a nicety — it's what makes incremental updates and background persistence correct. If the same tree could produce different graphs, a fold-in could not be diffed against the previous state.

What's public, and what isn't

This page deliberately stops where the public README does. The engine's internal module structure, class layout, in-memory data structures, and the exact representation passed between pipeline stages are not documented publicly.

Where to go next

• Indexing Pipeline — the stages the engine runs.
• Daemon Architecture — how the engine is kept warm.