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.