Compound Engineering Knowledge Graph

A compound engineering knowledge graph can be useful, but it is not a documented feature of the current Compound Engineering plugin. It is a proposed external design: connect current code structure to reviewed solution records, issues, pull requests, and design documents so an agent can retrieve a bounded evidence set for a task.

The hard part is not drawing more edges. It is defining authority, provenance, version scope, and permissions before generated relationships enter an agent's context.

Before You Build the Graph

Start with questions, not a schema. A platform team may need to answer:

A compound engineering knowledge graph earns its operational cost only when those cross-artifact questions recur and ordinary repository search no longer answers them reliably.

• Which current symbols participate in this failing request path?
• Which reviewed solution records concern the same subsystem?
• Which pull request introduced the behavior?
• Which tests and owners should be included before a change?

If ordinary repository search answers these questions reliably, a graph may add unnecessary operations. Build the layer only where repeated traversal across artifacts is a measured bottleneck.

Define the source-of-truth policy before ingestion. Code and tests verify current behavior. Reviewed specifications and decisions express intent. Solution records preserve scoped reasoning. Issues and pull requests supply history, but their comments may include superseded hypotheses. Generated links support navigation and must not silently override those sources.

Also define the version key. A relationship without a commit, branch, or release scope is unsafe in a changing repository.

Start with Knowledge Graph for AI Coding Assistants if the graph model is unfamiliar. Evaluate context overhead separately in Compound Engineering Token Usage.

Connect Code, Docs, Bugs, PRs, and Solutions

A useful initial schema is small.

An engineering knowledge graph built from this schema should remain a bounded evidence index, not a claim that every engineering artifact belongs in one database.

Node types might include Repository, Revision, File, Symbol, Test, Document, Issue, PullRequest, Solution, and Owner. Edge types might include DEFINES, CALLS, IMPLEMENTS, IMPORTS, TESTS, CHANGED_BY, DISCUSSED_IN, SOLVES, OWNS, and VALID_AT.

Every node and edge should have provenance fields:

• source system and stable source identifier;
• repository and revision;
• extraction time and method;
• confidence or resolution status where applicable;
• access scope;
• expiry or invalidation condition;
• reviewer for curated links.

The graph should distinguish extracted facts from curated assertions. A parser may extract Symbol A CALLS Symbol B from one revision. A maintainer may curate Solution 17 SOLVES retry duplication in Settlement. Those claims were produced differently and should not share an unexplained confidence score.

The current Compound Engineering workflow gives the proposed graph a useful document type: ce-compound writes a selected learning to solutions/, while refresh tooling can maintain stale or overlapping solution records. [CE-COMPOUND-20260724] [CE-REFRESH-20260724] The integration itself remains hypothetical. A connector would need to ingest those records, preserve their repository history, and keep review state visible.

Those solution records must not be conflated with Claude Code auto memory, which is a separate host-managed context layer. [ANTHROPIC-MEMORY-20260724]

Graphify can be evaluated as one possible external code-structure provider in this model. It should not be presented as an official Compound Engineering component or as a complete source of product, incident, and pull-request truth.

Model Similar Problems and Past Fixes

“Similar problem” is not a primitive fact. Two incidents may share an error string but have different causes. Two solution documents may describe the same root cause with different vocabulary. An engineering knowledge graph needs an explicit method for proposing similarity.

The phrase Compound engineering knowledge graph GitHub can imply that such a graph already exists in the official repository. It does not appear in the pinned current Compound Engineering documentation. The plugin documents planning, review, and durable solution workflows; this article's graph is an external architecture proposal. [CE-README-20260724] [CE-COMPOUND-20260724]

Use several signals rather than a single magic edge:

• shared affected symbols or subsystems;
• common error types, test failures, or stack frames;
• overlapping dependencies and change paths;
• curated labels or incident categories;
• text or code embeddings used as candidate generators.

Represent the output as POSSIBLY_SIMILAR_TO, not SAME_AS, until reviewed. Store the features and model version that produced the candidate. If the relationship comes from an embedding classifier, say so; graph topology alone does not infer semantic similarity.

Past fixes also need outcomes. Record whether a solution was accepted, reverted, superseded, or limited to a version. A pull request that mentions an issue is not automatically the correct fix, and a merged change can later be reverted. Model these events instead of flattening them into one permanent SOLVES edge.

For privacy, avoid embedding unrestricted issue text into a broadly queryable index. The permission intersection of every source should constrain the returned evidence.

Query the Graph During Agent Tasks

Graph retrieval should be a bounded step inside an agent workflow, not a request to “load the repository.” A practical query contract includes task terms, repository, target revision, maximum traversal depth, allowed node types, and an evidence budget.

For a failing checkout test, the sequence could be:

1. Resolve the failing test and symbols on the target commit.
2. Traverse one or two typed edges to callers, implementations, and affected tests.
3. Retrieve reviewed solution records linked to those components.
4. Return paths, source identifiers, indexed revision, and uncertainty.
5. Let the agent open the source and reproduce the behavior before editing.

In a proposed Graphify workflow, the code graph supplies structural candidates. Compound Engineering solution documents contribute scoped prior learning. The agent's host supplies instructions and tool execution. These are separate systems joined by an explicit retrieval contract, not a built-in vendor integration.

Good queries are falsifiable. “Show current callers of this symbol at commit X” can be checked. “Tell me everything relevant” cannot. Log which returned facts were opened, accepted, corrected, or ignored; that evidence helps tune traversal and expiry.

Do not automatically write agent conclusions back as graph truth. Send proposed curated edges through review, especially SOLVES, OWNS, and cross-artifact intent relationships.

Drift, Privacy, and Review Risks

Drift occurs in more than code. Symbols move, issue labels change, owners rotate, solution records become obsolete, and pull-request links can point to a branch that no longer reflects production. Each data source needs a freshness rule and a deletion path.

Index status should be visible in every response. If the requested commit is newer than the graph, return a qualified partial answer or require live repository inspection. Dynamic dispatch, runtime configuration, generated code, and incomplete language support should also lower confidence.

Permissions must be evaluated at query time. A user who can read repository A but not a linked incident in system B should not receive the incident title, extracted text, or a summary that reveals it. Derived embeddings and cached responses need the same retention discipline as source content.

Schema review matters because edge types shape agent behavior. Adding APPROVED_BY or redefining OWNS can change which evidence an agent trusts. Treat schema changes like API changes: document semantics, migrate old data, sample results, and assign an approver.

Measure the system with controlled tasks and correction logs. Useful signals include stale edges found, unsupported links rejected, time to verified evidence, and reviewer corrections. Do not publish a universal token-saving percentage without matched conditions.

FAQ

What sources should be excluded?

Exclude data without a legitimate access path, retention policy, or clear task value. Raw private messages, unrestricted transcript archives, secrets, and low-quality generated summaries should not enter by default. For each source, document the permitted users, expiry rule, and whether derived embeddings must be deleted with the original.

Who approves graph schema changes?

A named cross-functional owner should approve them: typically the platform team operating the graph plus representatives from security and the affected engineering domains. High-authority relationships such as ownership, approval, or solution status need stricter review than mechanically extracted imports.

How should bad links be corrected?

Preserve the original provenance, mark the link invalid for the affected revision, and record why it failed. Fix the extractor or curated assertion at its source, rebuild the relevant slice, and add a regression sample. Do not merely hide the edge in the UI while leaving agents able to retrieve it.

What are the steps in compound engineering?

The current plugin organizes work around planning, implementation support, review, and a compounding step that captures reusable learning; exact available skills should be checked in the pinned official repository. [CE-README-20260724] A code graph is not one of those documented first-party steps.

Conclusion

A credible compound engineering knowledge graph begins with narrow questions and evidence rules. Connect code, tests, documents, issues, pull requests, and solutions only when every relationship exposes provenance, revision, access scope, and status.

The graph should help an agent find evidence, not manufacture authority. Keep Compound Engineering's reviewed solution records, the agent host's instructions, and the proposed external structural layer distinct. That separation makes conflicts inspectable and corrections possible.