# Internals
> The engine at the center, and what is and isn't public about it.
[Source](https://open.nxtsoft.io/docs/cgraph/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.

_Thin front doors, one engine_

```text
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**.

Rather than reverse-engineer or invent internals, this page marks them pending.
When the engine's internals are documented against the source, this page will be
filled in with the real module map — not before.

## Where to go next

- [Indexing Pipeline](/docs/cgraph/indexing-pipeline) — the stages the engine runs.
- [Daemon Architecture](/docs/cgraph/daemon) — how the engine is kept warm.