Build on the graph

A snapshot is a set of plain files with a documented format: the facts, the relationships between them, the findings, and a receipt recording exactly how it was built. Run enola as a subprocess and load those files wherever you need them.

Cognee builds its code-graph search this way: it pins an enola-cli release and loads the snapshot files, and that search needs no LLM key. How it finds the binary and what it writes: docs/INTEGRATING.md. If you got enola as part of Cognee, docs/COGNEE.md shows where the binary is and how to use it directly.

docs/GRAPH.md explains what the graph contains and which files are a stable contract; docs/INTEGRATING.md shows how to load it step by step.

Quickstart

1. Install enola. One prebuilt binary; no Go toolchain or C compiler needed.

curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh

This puts enola in ~/.local/bin. The same binary is on PyPI (pip install enola-cli) and RubyGems. Every install route, and how to upgrade, is in docs/CLI.md.

2. Point it at a repository you have checked out.

enola --explain /path/to/your/repo

No config file, no account, nothing written to disk. It reads the code and prints what it found. If you have nothing at hand, run it on enola itself:

git clone https://github.com/enola-labs/enola
enola --explain enola

Part of what that prints (the numbers move as the code does):

Overview
  Languages:           go, typescript, c, ruby, python
  Total facts:         10814

Architecture
  cyclic dependencies         0
  layer violations            0

Impact analysis (hotspots)
  Top hotspots (by coupling):
    module                            fan-in  fan-out crit     blast radius
    internal/facts                       253        1 high     96
    pkg/command                            1       94 high     1
    pkg/bootstrap                         15       69 high     4

How to read it:

• A fact is one thing enola recorded: "this function exists", "this function calls that one", "this route is served here". Total facts is how many it found.
• A cyclic dependency is two or more modules that each need the other, so neither can be changed or tested alone.
• A layer violation is a module reaching into a layer it is not allowed to use, under a layer order the repository declared. enola declares its own in enola-intent.yaml; 0 means nothing in the code crosses it.
• A hotspot is a module many other modules depend on. fan-in is how many modules use it; fan-out is how many it uses; blast radius is how many modules a change to it can reach. Read the first row as: internal/facts is used from 253 places, and a change to it can reach 96 modules.

If that is more vocabulary than you need, ask for the plain-language summary instead. It says what the repository is, whether its structure holds, where to start reading, what is risky to change and what is worth a look, and marks each statement with how sure enola is:

enola --explain --summary enola

3. Keep the graph and look at it. --explain only prints. To save the graph, build it with --generate. It is written under .enola/ in the repository, and that saved graph is what the local dashboard shows:

enola --generate .
enola dashboard --open

The dashboard is a local web page; nothing is sent anywhere. Dashboard guide.

Explore examples

Each example is a small repository plus a run.sh that reproduces the output shown in its README.

• The gate on five packages: a module built to a layer order, and one change that breaks it. This is the fixture the outputs in this README come from.
• Two repositories, one graph: a web service and the API it calls, with one call enola can link and one it reports as unresolved.
• Policy as code: PCI DSS and GDPR-inspired constraints on a small Go module, with three changes that violate them.
• A custom HTTP client: teaching enola an in-house client so its calls link to server routes.
• A CI workflow and a pre-commit hook ready to copy.
• Per-language configuration files for Go, TypeScript, Python, Ruby, PHP, Kotlin, Swift and C++.