Graph Engineering
Graph engineering is the discipline of designing the structures agents work through — not the
prompts. It has two halves:
- Knowledge graphs — what agents remember. Nodes are entities and facts, edges are
relationships with time and provenance. This file's 9-stage pipeline covers it, distilled
from Southeast University's graduate KG course
(https://github.com/npubird/KnowledgeGraphCourse, Prof. Peng Wang), translated to English
and adapted for LLM-era agents.
- Task graphs — how agents work. Nodes are jobs, edges are execution dependencies:
parallel fan-out, separate verifier contexts, the stop rule, the human gate.
Read references/task-graphs.md when the request is about
orchestrating agents rather than building memory.
Core mental model: a knowledge graph is a product with a schema, not a pile of triples.
Quality comes from the pipeline order — model the domain BEFORE extracting, fuse BEFORE storing,
evaluate at every stage.
Teaching Mode
When the user wants to LEARN graph engineering (rather than build something), teach it — do
not just execute. Rules:
- Anchor every stage in the user's own domain: ask for one real project or dataset, then use
it as the running example through all stages.
- Generate visual artifacts as you teach. Concepts in this discipline are shapes; show
them. For each major concept, produce a small diagram the user can keep — mermaid diagrams
(flowchart for the pipeline and task graphs,
graph LR for example ontologies and
subgraphs) or a single self-contained HTML page when interactivity helps. At minimum:
the 9-stage pipeline, a 3-type ontology drawn from the user's domain, one extracted
subgraph (5-10 nodes) from a real sample, and the diamond pattern with the user's own jobs
as nodes.
- Teach in the pipeline's order, one stage per exchange, each ending with a small exercise
("write 3 competency questions for your project") before moving on.
- Close by assembling what was built during the lesson into a starter
ontology.yaml and a
drawn task graph for the user's first real build.
The 9-Stage Pipeline
Run stages in order. For small projects stages 4-6 collapse into one extraction pass, but never
skip stages 3 (ontology) or 8 (fusion) — they are where real-world graphs fail.
Scope & value test — Confirm a graph beats a simpler structure. A graph pays off when
queries are multi-hop ("who worked with X on projects using Y"), when entities recur across
documents, or when relationships ARE the data. If lookups are single-hop, use a table and stop.
Knowledge representation choice — Pick how facts are encoded: property graph
(Neo4j-style, pragmatic default), RDF triples (interop/standards), or plain typed edges in
JSON/SQLite (small scale). Decide now how time and provenance attach to every fact.
Ontology modeling — Define entity types, relation types (with domain/range), and
attributes BEFORE extraction. Start minimal: 5-15 entity types, 10-30 relation types.
Two rules from the course: every relation gets a precise verb name (ACQUIRED, not
RELATED_TO), and if two types are always queried together, merge them.
Details and worked examples: references/modeling.md
Entity extraction (NER) — Extract typed entities from sources. Method ladder: exact
rules/dictionaries for closed vocabularies → LLM extraction with the ontology in the prompt
for open text. Always extract with span + source pointer for provenance.
Relation extraction — Extract typed edges between recognized entities. Constrain the
LLM to the ontology's relation list with domain/range checks; reject edges whose endpoints
have incompatible types. This one validation step removes most hallucinated structure.
Event extraction — For dynamic domains (news, logs, transactions), extract events as
first-class nodes (trigger + typed arguments + time), not just static edges.
Extraction methods, prompt patterns, and failure modes for stages 4-6:
references/extraction.md
Quality gate — Before fusion, sample and score: entity precision (are extracted
entities real and correctly typed?), relation precision (does the source sentence actually
assert the edge?). Fix the prompt/rules, not the output, then re-run. Target ≥90% precision
on a 50-item sample before proceeding — recall improves with more passes; bad precision
poisons the graph permanently.
Knowledge fusion — Merge duplicates within and across sources: same real-world entity,
different surface forms ("SEU" = "Southeast University" = "东南大学"). Blocking + matching +
merge policy. Skipping this is the #1 cause of useless graphs.
Matching strategies: references/fusion-and-llm.md
Serve to LLMs (KG × LLM) — Make the graph useful to agents: GraphRAG retrieval
(subgraph → context), graph-as-memory (agent writes facts back through stages 4-8), and
LLM-as-reasoner over paths. Patterns and pitfalls:
references/fusion-and-llm.md
Working Rules
- Schema first, always. Extraction without an ontology produces a "graph" that is really a
word cloud with arrows. If the user resists schema design, build the minimal 5-type ontology
from 3 sample documents and show it for approval.
- Provenance on every fact. Each node/edge stores
source, extracted_at, and confidence.
Non-negotiable — fusion (stage 8) and trust both depend on it.
- Incremental over big-bang. Process a 10-document pilot through all 9 stages before
scaling. The pilot exposes ontology gaps at 1% of the cost.
- LLM extraction is stage machinery, not the pipeline. The LLM slots into stages 4-6;
the surrounding schema, validation, and fusion are what make the output a knowledge graph.
Reference Files
- references/curriculum.md — Full translated curriculum of the
source course with per-lecture summaries and links to the original Chinese slide decks.
Read when the user wants theory depth, the academic grounding, or the original materials.
- references/modeling.md — Knowledge representation & ontology
engineering (course lectures 2-3). Read during stages 2-3.
- references/extraction.md — Entity, relation, and event
extraction from rules to LLM prompting (lectures 4-7). Read during stages 4-7.
- references/fusion-and-llm.md — Knowledge fusion and
KG × LLM integration (lectures 8-9). Read during stages 8-9.
Credits
Distilled and translated from 东南大学《知识图谱》研究生课程 (Southeast University graduate
course on Knowledge Graphs), Prof. Peng Wang — https://github.com/npubird/KnowledgeGraphCourse.
All original lecture PDFs are in Chinese; this skill is an independent English distillation
adapted for AI-agent workflows.
1---2name: graph-engineering3description: Teaches an agent graph engineering — both halves. Knowledge graphs (ontology design, entity/relation/event extraction, fusion, GraphRAG/memory serving; distilled and translated from Southeast University's graduate Knowledge Graph course, npubird/KnowledgeGraphCourse, 4.4K stars) and task graphs (agent orchestration — parallel fan-out, verifier separation, the stop rule, human gates). Use when asked to build a knowledge graph, extract entities/relations from text, design an ontology, dedupe/merge entities, add graph memory or GraphRAG to an agent, orchestrate multi-agent workflows as a graph, or LEARN graph engineering — in teaching mode the agent explains each stage with worked examples and generates visual diagram artifacts.4---56# Graph Engineering78Graph engineering is the discipline of designing the structures agents work through — not the9prompts. It has two halves:10111. **Knowledge graphs** — what agents remember. Nodes are entities and facts, edges are12 relationships with time and provenance. This file's 9-stage pipeline covers it, distilled13 from Southeast University's graduate KG course14 (https://github.com/npubird/KnowledgeGraphCourse, Prof. Peng Wang), translated to English15 and adapted for LLM-era agents.162. **Task graphs** — how agents work. Nodes are jobs, edges are execution dependencies:17 parallel fan-out, separate verifier contexts, the stop rule, the human gate.18 Read [references/task-graphs.md](references/task-graphs.md) when the request is about19 orchestrating agents rather than building memory.2021Core mental model: a knowledge graph is a **product with a schema**, not a pile of triples.22Quality comes from the pipeline order — model the domain BEFORE extracting, fuse BEFORE storing,23evaluate at every stage.2425## Teaching Mode2627When the user wants to LEARN graph engineering (rather than build something), teach it — do28not just execute. Rules:29301. Anchor every stage in the user's own domain: ask for one real project or dataset, then use31 it as the running example through all stages.322. **Generate visual artifacts as you teach.** Concepts in this discipline are shapes; show33 them. For each major concept, produce a small diagram the user can keep — mermaid diagrams34 (flowchart for the pipeline and task graphs, `graph LR` for example ontologies and35 subgraphs) or a single self-contained HTML page when interactivity helps. At minimum:36 the 9-stage pipeline, a 3-type ontology drawn from the user's domain, one extracted37 subgraph (5-10 nodes) from a real sample, and the diamond pattern with the user's own jobs38 as nodes.393. Teach in the pipeline's order, one stage per exchange, each ending with a small exercise40 ("write 3 competency questions for your project") before moving on.414. Close by assembling what was built during the lesson into a starter `ontology.yaml` and a42 drawn task graph for the user's first real build.4344## The 9-Stage Pipeline4546Run stages in order. For small projects stages 4-6 collapse into one extraction pass, but never47skip stages 3 (ontology) or 8 (fusion) — they are where real-world graphs fail.48491. **Scope & value test** — Confirm a graph beats a simpler structure. A graph pays off when50 queries are multi-hop ("who worked with X on projects using Y"), when entities recur across51 documents, or when relationships ARE the data. If lookups are single-hop, use a table and stop.52532. **Knowledge representation choice** — Pick how facts are encoded: property graph54 (Neo4j-style, pragmatic default), RDF triples (interop/standards), or plain typed edges in55 JSON/SQLite (small scale). Decide now how time and provenance attach to every fact.56573. **Ontology modeling** — Define entity types, relation types (with domain/range), and58 attributes BEFORE extraction. Start minimal: 5-15 entity types, 10-30 relation types.59 Two rules from the course: every relation gets a precise verb name (`ACQUIRED`, not60 `RELATED_TO`), and if two types are always queried together, merge them.61 Details and worked examples: [references/modeling.md](references/modeling.md)62634. **Entity extraction (NER)** — Extract typed entities from sources. Method ladder: exact64 rules/dictionaries for closed vocabularies → LLM extraction with the ontology in the prompt65 for open text. Always extract with span + source pointer for provenance.66675. **Relation extraction** — Extract typed edges between recognized entities. Constrain the68 LLM to the ontology's relation list with domain/range checks; reject edges whose endpoints69 have incompatible types. This one validation step removes most hallucinated structure.70716. **Event extraction** — For dynamic domains (news, logs, transactions), extract events as72 first-class nodes (trigger + typed arguments + time), not just static edges.73 Extraction methods, prompt patterns, and failure modes for stages 4-6:74 [references/extraction.md](references/extraction.md)75767. **Quality gate** — Before fusion, sample and score: entity precision (are extracted77 entities real and correctly typed?), relation precision (does the source sentence actually78 assert the edge?). Fix the prompt/rules, not the output, then re-run. Target ≥90% precision79 on a 50-item sample before proceeding — recall improves with more passes; bad precision80 poisons the graph permanently.81828. **Knowledge fusion** — Merge duplicates within and across sources: same real-world entity,83 different surface forms ("SEU" = "Southeast University" = "东南大学"). Blocking + matching +84 merge policy. Skipping this is the #1 cause of useless graphs.85 Matching strategies: [references/fusion-and-llm.md](references/fusion-and-llm.md)86879. **Serve to LLMs (KG × LLM)** — Make the graph useful to agents: GraphRAG retrieval88 (subgraph → context), graph-as-memory (agent writes facts back through stages 4-8), and89 LLM-as-reasoner over paths. Patterns and pitfalls:90 [references/fusion-and-llm.md](references/fusion-and-llm.md)9192## Working Rules9394- **Schema first, always.** Extraction without an ontology produces a "graph" that is really a95 word cloud with arrows. If the user resists schema design, build the minimal 5-type ontology96 from 3 sample documents and show it for approval.97- **Provenance on every fact.** Each node/edge stores `source`, `extracted_at`, and confidence.98 Non-negotiable — fusion (stage 8) and trust both depend on it.99- **Incremental over big-bang.** Process a 10-document pilot through all 9 stages before100 scaling. The pilot exposes ontology gaps at 1% of the cost.101- **LLM extraction is stage machinery, not the pipeline.** The LLM slots into stages 4-6;102 the surrounding schema, validation, and fusion are what make the output a knowledge graph.103104## Reference Files105106- [references/curriculum.md](references/curriculum.md) — Full translated curriculum of the107 source course with per-lecture summaries and links to the original Chinese slide decks.108 Read when the user wants theory depth, the academic grounding, or the original materials.109- [references/modeling.md](references/modeling.md) — Knowledge representation & ontology110 engineering (course lectures 2-3). Read during stages 2-3.111- [references/extraction.md](references/extraction.md) — Entity, relation, and event112 extraction from rules to LLM prompting (lectures 4-7). Read during stages 4-7.113- [references/fusion-and-llm.md](references/fusion-and-llm.md) — Knowledge fusion and114 KG × LLM integration (lectures 8-9). Read during stages 8-9.115116## Credits117118Distilled and translated from 东南大学《知识图谱》研究生课程 (Southeast University graduate119course on Knowledge Graphs), Prof. Peng Wang — https://github.com/npubird/KnowledgeGraphCourse.120All original lecture PDFs are in Chinese; this skill is an independent English distillation121adapted for AI-agent workflows.