Graph Engineering Capstone

By the Syncfusion DevTutorials team · Last updated October 20, 2026

Build one of three graphs for your project: a risk-routed issue graph, a codebase migration graph, or a review-and-fix graph. Grade it on 40 tickets, keep it no bigger than needed, and export a graph pack for your tools.

Watch Your First Draft Fail

You have learned every pattern one at a time. Real projects need them together, in a graph you can hand to your coding agent tomorrow.

Here is a first draft of a risk-routed issue graph. It routes well and fixes carefully. Run it on all 40 tickets.

It merges payment and login changes with no one looking. Each capstone graph starts from a draft like this, with gaps you have already learned to close. Your job: close them, prove it on the scorecard, keep the graph small, and take it home as a graph pack.

TL;DR

• Pick one of three graphs: a risk-routed issue graph, a codebase migration graph or a review-and-fix graph.
• Fix the draft with the patterns from this course.
• It passes when it meets the scorecard on all 3 versions, is no bigger than the reference, and its export validates for every tool you picked.
• Then export it, answer the questions about your project, and try it on 2 or 3 small tickets.

A Real-World Example

Noor's team finished this course and built the migration graph for a real job: moving 140 calls to a new logging library. Their first run used the course's caps, width 8 because their API allowed 10 calls at once, depth 1, and a spend cap sized from the biggest folder.

The orchestrator found 143 call sites, not 140. The topology record showed it plainly. The run finished in an afternoon, with every change in its own pull request. Two changes touched the payment service, so the team added a gate for those two. The rest merged after the tests passed.

What You Will Learn

• How to choose the graph that fits your project
• How to finish a graph from a draft
• How to pass a scorecard on all 40 tickets and every version
• Why the graph must be no bigger than the reference
• How to export and check a graph pack, and run it for real

A Graph Pack for Your Project

Your choice from the check at the top of Lesson 1 is saved in the lab's Settings. You can change it at any time. You see all three below; you only need to pass one.

Which graph fits?

function pick(project) {
  if (project.sameChangeManyPlaces) return "codebase migration graph";
  if (project.needsSeveralChecks) return "review-and-fix graph";
  if (project.riskMix) return "risk-routed issue graph";
  return "one loop is enough";
}

console.log(pick({ riskMix: true }));
console.log(pick({ sameChangeManyPlaces: true }));
console.log(pick({ needsSeveralChecks: true, riskMix: true }));
console.log(pick({}));

Expected output:

risk-routed issue graph
codebase migration graph
review-and-fix graph
one loop is enough

The last line matters. If none of these fit, your project may not need a graph. That is a fine answer: the Loop Engineering capstone is your pack.

How the Capstone Is Graded

The check uses the same rules as every lesson, all at once.

The capstone check

function capstone(r) {
  const checks = [
    ["passes the scorecard on all 3 versions", r.versionsPassed === 3],
    ["no bigger than the reference",           r.size <= r.referenceSize],
    ["export validates for every tool",        r.exportProblems === 0],
  ];
  for (const [name, ok] of checks) console.log((ok ? "pass  " : "FAIL  ") + name);
  return checks.every(([, ok]) => ok) ? "capstone passed" : "not yet";
}

console.log(capstone({ versionsPassed: 3, size: 18, referenceSize: 18, exportProblems: 0 }));
console.log(capstone({ versionsPassed: 3, size: 20, referenceSize: 18, exportProblems: 0 }));

Expected output:

pass  passes the scorecard on all 3 versions
pass  no bigger than the reference
pass  export validates for every tool
capstone passed
pass  passes the scorecard on all 3 versions
FAIL  no bigger than the reference
pass  export validates for every tool
not yet

Build Your Graph

Open the graph file for your target, fix it (in the Graph file, the Canvas or the State tab), and press Check my graph. Each one starts from a draft with gaps.

Option 1: Risk-Routed Issue Graph

What to check:

• A kind: gate node with evidence: [careful_diff, test_result, risk_reason] sits between careful_fix and merge.
• The quick path goes straight to merge, with no gate.
• The router's when: else edge goes to the careful path.
• Keep the size: you may add exit keys to careful_fix, but do not add new nodes or edges beyond the gate.

Option 2: Codebase Migration Graph

What to check:

• The orchestrator has caps: with width at or below the API limit of 8, depth: 1 and a spend cap that covers 52 sites.
• The orchestrator has record_topology: true.
• The join has check_plan: true and reads call_sites as well as diffs.
• The graph has kill_switch: GRAPH_PAUSED at the top (the linter asks for it; the check does not).

Option 3: Review-and-Fix Graph

What to check:

• Each audit writes its own field.
• The verifier join has a timeout: and a policy:.
• The router has model: large, min_confidence and a careful when: else edge.
• The careful fixer loops against the tests, with real exits.
• A gate follows the careful fixer.

Export Your Graph Pack

When your graph passes, open the Export tab.

For an existing project, open "Answer the questions" in the Export tab. The first five are the same questions as the Loop course; the last three are about your graph:

1. Your test command. It goes into every checker and the README.
2. Where the work comes from, for example an issue label.
3. What "done" means for one item.
4. A token budget per day for the whole graph.
5. Where escalations go.
6. Which work splits into independent parts.
7. Your high-risk areas, for example billing/, auth/, migrations/. They become the router's high-risk labels and the gate rule.
8. Who approves at a gate.

The answers are written into graph.md, routing-labels.yaml, human-gates.md and the README.

Answers into the pack

const answers = { testCommand: "npm test", riskyAreas: "billing/, auth/", approver: "the on-call lead" };

const labels = answers.riskyAreas.split(",").map((x) => x.trim()).filter(Boolean);
console.log("tests: " + answers.testCommand);
console.log("high-risk labels: " + labels.join(" | "));
console.log("gate waits for: " + answers.approver);

Expected output:

tests: npm test
high-risk labels: billing/ | auth/
gate waits for: the on-call lead

Your First Real Run

The lab cannot run your real tools, and this part is not graded. The README in your pack has the checklist. In short:

First real run checklist

const checklist = [
  "run the test command by hand once",
  "create GRAPH_PAUSED, start the graph, check it stops; delete the file",
  "run the graph on 2 or 3 small tickets",
  "change a state field by hand between two nodes: the supervisor must stop the graph",
  "check that graph-state.json updates after every node",
  "read every diff on the first day",
];
checklist.forEach((item, i) => console.log("[ ] " + (i + 1) + ". " + item));

Expected output:

[ ] 1. run the test command by hand once
[ ] 2. create GRAPH_PAUSED, start the graph, check it stops; delete the file
[ ] 3. run the graph on 2 or 3 small tickets
[ ] 4. change a state field by hand between two nodes: the supervisor must stop the graph
[ ] 5. check that graph-state.json updates after every node
[ ] 6. read every diff on the first day

Keep It Healthy

After the first week, watch a few numbers per run: tokens per node, how often each exit fires, how many tickets reach a gate, and how many were later reverted. If a number moves, diff a bad run against a good one (Lesson 9). If the graph has grown, ask of every node: which number does it move?

A weekly health check

const lastWeek = { tokensPerTicket: 2400, gated: 9, reverted: 0, budgetStops: 1 };
const thisWeek = { tokensPerTicket: 3900, gated: 9, reverted: 2, budgetStops: 6 };

for (const k of Object.keys(thisWeek)) {
  const change = thisWeek[k] - lastWeek[k];
  const moved = Math.abs(change) > Math.max(1, lastWeek[k] * 0.25);
  console.log(k.padEnd(16) + String(lastWeek[k]).padStart(5) + " -> " + String(thisWeek[k]).padStart(5) + (moved ? "   look: diff a run" : ""));
}

Expected output:

tokensPerTicket  2400 ->  3900   look: diff a run
gated               9 ->     9
reverted            0 ->     2   look: diff a run
budgetStops         1 ->     6   look: diff a run

Common mistakes

Exercises

Each exercise ends with a value on the last line. Press Check to compare it with the expected answer.

What to Remember

• Pick the one graph that fits your project, or keep one loop.
• The capstone passes on the scorecard, on size, and on a clean export.
• Answer the questions so the pack fits your project.
• Run it first on 2 or 3 small tickets, with the supervisor and kill switch in place.
• Keep watching tokens per node, exits and gates, and diff runs when a number moves.

Further Reading

• How to Implement Graph Engineering, by QA Wolf: the worked architectures behind the three capstone graphs.
• Building Effective Agents, by Anthropic: start simple, add complexity only when it helps.
• Claude Code subagents, Codex subagents and Cursor subagents: the official docs for the files in your pack.

Next: Cheat Sheet, one page with every template, rule and error message from this course.