Graph engineering is a practice, not a visualization

Most “code graphs” are pictures of import statements. They look serious in a demo and go quiet the moment an engineer asks a staffing question.

Graph engineering is the opposite of that. It is the practice of deciding which events become nodes, which facts become edges, and which questions the resulting model is allowed to answer. Helix is built as that practice, not as a layout algorithm.

Start from questions, not from files

The useful questions are rarely “what does this file import?” They sound like:

• Who can review this change without rereading the service?
• What else always ships when checkout moves?
• Is this folder a silo or a shared surface?
• Did this pull request close a previous one, or just mention it?

Those questions have answers in merge history. They do not have answers in an AST. Graph engineering starts by writing the questions down, then choosing evidence that can survive a Monday morning without the original author in the room.

Nodes are units of talk

Organizations do not talk in hashes. They talk in pull requests, people, folders, and files. A graph that skips directories because they are “just prefixes” is skipping the unit teams use in stand-up.

Helix reconstructs:

• repositories
• pull requests
• people
• files
• directories
• DNA patterns written back by agent loops

Each node is something you can click, cite, and ask about. If a node cannot be cited, it should not exist.

Edges are claims

An edge is a sentence with a source. AUTHORED means a person opened the pull request. COUPLED means two files shared enough merged changes that treating them as independent is a bet. OWNS is majority authorship in the indexed window: not a personality score.

const edge = {
  from: "person:maya",
  to: "file:acme/storefront:src/checkout.ts",
  type: "OWNS",
  evidence: {
    source: "github",
    url: "https://github.com/acme/storefront/pull/41",
    summary: "Maya authored 4 of 5 indexed changes",
  },
};

If you cannot point at the evidence, you do not get the edge. That is the entire discipline.

Layout is the last step

Force-directed drawings are how humans glance at a system. They are not how the system is understood. Ask Helix walks the same edges the canvas draws. Pulse lists them. Helix Review writes them into a pull request comment. The picture is a view. The graph is the product.

A team that treats the canvas as the deliverable will ship a screensaver. A team that treats the graph as evidence can make a better-supported ship decision.

Helix is graph engineering for merge history: index a repository, let the loops encode DNA, and ask the questions your wiki never could. Open Helix and start from a living model, not a screenshot.