What Helix actually connects

A codebase is not a tree of files. It is a set of things that happened: people shipped pull requests, folders absorbed the blast radius, two files refused to move independently, a comment said “fixes #40.”

Helix records those events as edges. Nothing is inferred without a label.

The original six

• BELONGS_TO: a pull request lives in a repository.
• AUTHORED: a person wrote it.
• REVIEWED: a person signed it.
• MODIFIED: the change touched a file.
• LEARNED / WATCHES / ENCODED: agent loops writing DNA back onto the graph.

Those are enough to answer “who knows checkout.ts?” They are not enough for a two-hundred-person org.

The missing layer

Organizations talk in folders. “Who owns src/?” is a staffing question. “What moves with payments?” is a risk question. “Did #41 mention #40?” is a history question.

Helix reconstructs:

• directory nodes from path prefixes
• CONTAINS: repository → folder → file
• COUPLED: files that share two or more merged PRs
• MENTIONS: #N in a title or body
• OWNS: majority author on a file, in this window
• TOUCHED: the person who keeps working in a folder

Pulse lists architecture. Ask Helix answers “Who owns src?” The API returns the same nodes an IDE can query.

graph.addEdge({ from: "pr:acme/storefront#41", to: "pr:acme/storefront#40", type: "MENTIONS" });
graph.addEdge({ from: "file:checkout.ts", to: "file:payments.ts", type: "COUPLED" });

Why this is the org map

A wiki is what you hoped was true last year. CODEOWNERS is what you assigned. The graph is what the merge history will still admit on Monday morning.

That is how a new hire finds the five folders that matter, how a staff engineer sees coupling before they “just tweak the copy,” and how a VP sees bus factor without a slide.

Software should explain itself. Relationships are how. Open Helix and click an edge until it becomes a sentence.