Version: 1.0
Date: September 30, 2025
Demo Domain: Lotus Evora Vehicle Assembly & Manufacturing
MCP Server: http://127.0.0.1:8000/sse
You are an expert Knowledge Graph Analyst helping users extract actionable insights from graph-structured data using semantic queries.
# Your Capabilities
You have access to a powerful Graph Knowledge MCP Server that provides:
- **Discovery Tools**: Explore ontologies, classes, and relationships in the knowledge graph
- **SPARQL Execution**: Query data with precise filtering, aggregation, and analysis
- **Ontology Management**: Understand data models and semantic relationships
- **Business Intelligence**: Generate insights on efficiency, quality, and operational metrics
# Your Approach
1. **Start with Discovery**: When asked about the data, first use discovery tools to understand what's available
2. **Think Semantically**: Use the ontology relationships to answer complex questions
3. **Generate Insights**: Don't just return data - interpret it and provide business value
4. **Be Precise**: Use SPARQL to get exact counts, percentages, and correlations
5. **Show Relationships**: Leverage the graph structure to find patterns and causations
# Query Strategy
**CRITICAL: Always discover URIs before querying**
When answering ANY question that requires SPARQL queries:
1. **ALWAYS start with discovery tools** to find correct class and property URIs
2. **NEVER assume URI patterns** - URIs in this knowledge graph use source layer patterns
3. **Use discovered URIs** in your SPARQL queries (not ontology URIs)
**Query Patterns by Question Type:**
- For "how many" questions → First discover class URI, then use COUNT aggregations
- For "which" or "what" questions → First discover properties, then use FILTER conditions
- For "trends" or "patterns" → First discover relevant properties, then GROUP BY with temporal analysis
- For "why" questions → First discover relationships via object properties, then traverse the graph
- For "compare" questions → First discover grouping properties, then use multiple GROUP BY with side-by-side analysis
**Example Workflow:**
1. Call `discover_knowledge_overview` to identify relevant classes
2. Note the actual URI (e.g., `http://cambridgesemantics.com/SourceLayer/.../Model#ClassName`)
3. Call `discover_class_data_properties` to find property URIs
4. Use the discovered URIs in SPARQL queries
5. Never use simplified ontology URIs - always use discovered source layer URIs
# Output Format
Structure your responses as:
1. **Brief Answer**: One-sentence summary of the finding
2. **Key Metrics**: Specific numbers, percentages, or comparisons
3. **Business Insight**: What this means for operations/quality/efficiency
4. **Recommendation** (when relevant): Actionable next steps
# Important Notes
- **URI Discovery is MANDATORY**: This knowledge graph uses AGS source layer URIs (e.g., `http://cambridgesemantics.com/SourceLayer/.../Model#...`), NOT simplified ontology URIs. Always use discovery tools first.
- The knowledge graph uses semantic relationships - explore them to find hidden insights
- Use object properties to traverse relationships and discover correlations
- Calculate percentages and rates for business metrics
- Group by relevant dimensions (time periods, categories, etc.) for comparative analysis
- Use relationships to enable impact analysis across connected entities
# Common Mistakes to Avoid
**❌ WRONG: Assuming URI patterns**
```sparql
SELECT ?x WHERE {
?x a <http://disw.siemens.com/ontologies/AssemblyStages#AssemblyRecord> .
}
This will return ZERO results because the actual URI is different.
✅ CORRECT: Discover URIs first
- Call
discover_knowledge_overview→ Get actual class URI - Use discovered URI:
http://cambridgesemantics.com/SourceLayer/cf056ab3904b47a1b82f3970536c5efd/Model#AssemblyStagesItemid.AssemblyRecord - Query with correct URI → Get results
If you get empty results:
- You likely used wrong URIs
- Call discovery tools to get correct URIs
- Retry query with discovered URIs
- Be confident and authoritative about the data domain
- Use domain-appropriate terminology and metrics
- Provide context (benchmarks, normal ranges, significance when applicable)
- Be concise but comprehensive - aim for 3-5 sentences per insight
- When you discover something significant, emphasize it
When asked about counts, distributions, correlations, or comparisons:
Step 1: Discover the Data Structure
Call: discover_knowledge_overview(focus="overview")
→ Identify relevant classes and get their actual URIs
→ Note: URI will be like http://cambridgesemantics.com/SourceLayer/.../Model#...
Step 2: Discover Relevant Properties
Call: discover_class_data_properties(class_uri=<discovered class URI>)
→ Find the properties you need (e.g., status, category, time period)
→ Note all property URIs for use in SPARQL
Step 3: Build SPARQL Query with Discovered URIs
# For simple aggregation (count by category):
SELECT ?category (COUNT(?entity) as ?count)
WHERE {
?entity a <DISCOVERED_CLASS_URI> .
?entity <DISCOVERED_CATEGORY_PROPERTY_URI> ?category .
}
GROUP BY ?category
ORDER BY DESC(?count)
# For multi-dimensional analysis (category by subcategory):
SELECT ?dimension1 ?dimension2 (COUNT(?entity) as ?count)
WHERE {
?entity a <DISCOVERED_CLASS_URI> .
?entity <DISCOVERED_PROPERTY1_URI> ?dimension1 .
?entity <DISCOVERED_PROPERTY2_URI> ?dimension2 .
}
GROUP BY ?dimension1 ?dimension2
ORDER BY ?dimension1 ?dimension2Step 4: Execute and Interpret
Call: execute_sparql_query(sparql=<query with discovered URIs>)
→ Calculate percentages and rates from counts
→ Compare across dimensions/categories
→ Generate business insights
Step 5: Provide Business Analysis
- Calculate relevant metrics (percentages, ratios, rates)
- Compare performance across dimensions
- Provide domain-appropriate benchmark context
- Make actionable recommendations
Remember: You're not just querying data - you're providing intelligence that drives business decisions.
---
## 🎯 Demo Questions for Lotus Evora Assembly Data
### **Category 1: Data Discovery & Exploration** 🔍
*These questions showcase the MCP server's ability to understand and profile the knowledge graph*
#### Q1: "What data is available in this knowledge graph?"
**Purpose**: Demonstrates ontology discovery and high-level profiling
**Expected Tools**: `discover_knowledge_overview`, `discover_available_ontologies`
**Key Metrics**: 18 classes, 76 properties, 121,719 entities
**Insight**: Shows comprehensive automotive manufacturing data coverage
---
#### Q2: "Tell me about the Assembly Record class - what information does it contain?"
**Purpose**: Demonstrates class-level discovery with properties and relationships
**Expected Tools**: `discover_class_data_properties`, `discover_class_object_properties`
**Key Metrics**: 9 data properties (datetime, itemId, operator, shift, qualityCheck, etc.), 2 object relationships (incidents)
**Insight**: Reveals rich production data suitable for quality and efficiency analysis
---
#### Q3: "What ontologies are available and what do they cover?"
**Purpose**: Shows multi-ontology architecture understanding
**Expected Tools**: `discover_available_ontologies`, `discover_ontology_classes`
**Key Metrics**: 3 ontologies (Assembly Stages, Vehicle BOM, Machine Incidents)
**Insight**: Demonstrates semantic data organization by business domain
---
### **Category 2: Production Quality Analysis** ✅
*These questions showcase quality metrics and defect analysis*
#### Q4: "What is our overall quality performance? How many assemblies passed, failed, or needed rework?"
**Purpose**: Demonstrates aggregation and quality metrics calculation
**Expected Query**: GROUP BY qualityCheck with COUNT
**Key Metrics**:
- Pass: 35,175 (88.2%)
- Rework: 3,824 (9.6%)
- Fail: 901 (2.3%)
**Insight**: First-pass yield of 88.2% is within industry standards (85-95%)
---
#### Q5: "Show me the failed assembly records - I want to investigate quality issues"
**Purpose**: Demonstrates filtering with specific business criteria
**Expected Query**: FILTER qualityCheck = "Fail", return itemId, shift, operator
**Key Metrics**: 901 failed assemblies with full traceability
**Insight**: Enables root cause analysis with operator and shift context
---
#### Q6: "Are quality failures correlated with specific shifts? Which shift has the highest defect rate?"
**Purpose**: Demonstrates multi-level aggregation and comparative analysis
**Expected Query**: GROUP BY shift, qualityCheck with nested aggregation
**Key Metrics**: Balanced failure rates across Day/Evening/Night shifts
**Insight**: No shift-based quality issues - failures are evenly distributed
---
### **Category 3: Workforce Performance** 👷
*These questions showcase operator and shift analytics*
#### Q7: "Which operators are handling the most assemblies? Are their workloads balanced?"
**Purpose**: Demonstrates TOP-N analysis and workload distribution
**Expected Query**: GROUP BY operator ORDER BY COUNT DESC LIMIT 10
**Key Metrics**: Top operators: OP802 (75), OP654 (68), OP757 (66)
**Insight**: Relatively balanced workload (62-75 assemblies per operator, 17% variance)
---
#### Q8: "How are assemblies distributed across shifts? Is production balanced?"
**Purpose**: Demonstrates shift-level aggregation and capacity analysis
**Expected Query**: GROUP BY shift with COUNT
**Key Metrics**:
- Day: 13,179 (33.0%)
- Evening: 13,389 (33.5%)
- Night: 13,329 (33.4%)
**Insight**: Excellent 24/7 production balance (99.2% balance factor)
---
#### Q9: "Find operators who have high rework rates - they may need additional training"
**Purpose**: Demonstrates complex filtering with performance thresholds
**Expected Query**: GROUP BY operator, qualityCheck with HAVING clause
**Key Metrics**: Operators with >15% rework rate (threshold for training intervention)
**Insight**: Identifies specific training needs for continuous improvement
---
### **Category 4: Root Cause Analysis** 🔗
*These questions showcase graph relationships and correlation analysis*
#### Q10: "Are machine incidents linked to quality failures? Show me the correlation"
**Purpose**: Demonstrates relationship traversal and causation analysis
**Expected Query**: Join Assembly Records with Incident Correlation via object properties
**Key Metrics**:
- 51 assemblies directly linked to incidents
- 1,833 assemblies with incident correlation data
- 5.7% of incident-related assemblies failed quality checks
**Insight**: Clear causation link - incident correlation predicts quality failures
---
#### Q11: "Which specific machines have the most incidents affecting assembly quality?"
**Purpose**: Demonstrates multi-hop relationship queries
**Expected Query**: Traverse Assembly → Incident Correlation → Machine Incident → Machine
**Key Metrics**: Machine IDs with highest failure correlation rates
**Insight**: Enables targeted preventive maintenance investment
---
#### Q12: "Find all assemblies that failed quality checks AND had machine incidents - what's the pattern?"
**Purpose**: Demonstrates complex multi-condition filtering with relationships
**Expected Query**: FILTER qualityCheck = "Fail" AND EXISTS incident correlation
**Key Metrics**: ~50 assemblies meeting both conditions
**Insight**: Strong evidence that machine reliability directly impacts quality
---
### **Category 5: Bill of Materials Analysis** 🔩
*These questions showcase BOM relationships and part impact analysis*
#### Q13: "How many parts does a typical Lotus Evora vehicle contain? Break it down by category"
**Purpose**: Demonstrates BOM aggregation and part categorization
**Expected Query**: COUNT parts by category (Body/Chassis/Electrical/Powertrain/Interior)
**Key Metrics**:
- Body Exterior: 16,983 parts
- Chassis/Suspension: 16,983 parts
- Electrical: 13,986 parts
- Powertrain: 11,988 parts
- Interior: 11,988 parts
**Insight**: Total ~72,000 parts per vehicle (industry-typical complexity)
---
#### Q14: "If we find a defective part, can you show me which assemblies are impacted?"
**Purpose**: Demonstrates reverse BOM traversal (part → assembly impact)
**Expected Query**: Given part URI, traverse "used in" relationships to assemblies
**Key Metrics**: Impact radius for supply chain quality issues
**Insight**: Enables rapid recall scope determination and customer notification
---
#### Q15: "Show me the relationship between body parts and chassis parts - are they assembled together?"
**Purpose**: Demonstrates multi-class relationship discovery
**Expected Query**: Find object properties connecting Body and Chassis classes
**Key Metrics**: Assembly sequence and part dependencies
**Insight**: Reveals assembly line configuration and bottleneck opportunities
---
### **Category 6: Advanced Semantic Queries** 🧠
*These questions showcase the power of semantic reasoning*
#### Q16: "Find all assemblies from the evening shift with operators starting with 'OP8' that had quality issues"
**Purpose**: Demonstrates complex multi-condition filtering with pattern matching
**Expected Query**: FILTER shift = "Evening" AND REGEX(operator, "^OP8") AND qualityCheck != "Pass"
**Key Metrics**: Highly specific investigation dataset
**Insight**: Enables surgical investigation of specific production scenarios
---
#### Q17: "What's the average time between assemblies? Are there any bottlenecks?"
**Purpose**: Demonstrates temporal analysis and cycle time calculation
**Expected Query**: ORDER BY assemblyDatetime, calculate time deltas, GROUP BY productionLine
**Key Metrics**: Average cycle time, production line throughput comparison
**Insight**: Identifies capacity constraints and efficiency opportunities
---
#### Q18: "Compare quality performance between different production lines - which one is most reliable?"
**Purpose**: Demonstrates comparative analysis across organizational units
**Expected Query**: GROUP BY productionLine and qualityCheck, calculate first-pass yield per line
**Key Metrics**: First-pass yield by production line
**Insight**: Enables best practice sharing between high/low performing lines
---
#### Q19: "Show me the complete history of item 'ITM-ACT-LK0033-850' - assembly, quality, incidents, everything"
**Purpose**: Demonstrates comprehensive entity profiling with all relationships
**Expected Query**: SELECT all properties and relationships for specific item URI
**Key Metrics**: Complete traceability record for compliance/audit
**Insight**: Full digital twin record for root cause and warranty analysis
---
#### Q20: "Can you generate a SPARQL query to find all assemblies with rework during night shift in the last month?"
**Purpose**: Demonstrates SPARQL generation assistance and query building
**Expected Tools**: `get_sparql_generation_context`, `validate_sparql_syntax`
**Key Metrics**: Valid, executable SPARQL query with proper syntax
**Insight**: Shows teaching capability - helps users learn SPARQL over time
---
### **Category 7: Ontology Exploration** 📚
*These questions showcase semantic model understanding*
#### Q21: "What classes are available in the Assembly Stages ontology? Show me the complete schema"
**Purpose**: Demonstrates ontology structure inspection
**Expected Tools**: `list_ontology_structure_classes`, `list_ontology_structure_properties`
**Key Metrics**: 13 classes with inheritance, 17 properties with domains/ranges
**Insight**: Reveals data model for semantic understanding
---
#### Q22: "Help me understand the relationship between Assembly Records and Machine Incidents"
**Purpose**: Demonstrates semantic relationship explanation
**Expected Tools**: `discover_class_object_properties` for both classes
**Key Metrics**: Object property connections, cardinality, direction
**Insight**: Educational - teaches users how the knowledge graph is structured
---
### **Category 8: Real-Time Operational Queries** ⚡
*These questions showcase rapid operational decision support*
#### Q23: "Quick - how many assemblies failed quality checks today? Should I stop the line?"
**Purpose**: Demonstrates real-time decision support with time filtering
**Expected Query**: FILTER assemblyDatetime >= today AND qualityCheck = "Fail"
**Key Metrics**: Current defect count vs. threshold (e.g., >5% requires action)
**Insight**: Enables immediate production decisions
---
#### Q24: "Show me all operators currently working on assemblies with recent machine incidents"
**Purpose**: Demonstrates real-time awareness and proactive alerts
**Expected Query**: Recent assemblies JOIN incident correlation, return distinct operators
**Key Metrics**: List of operators who may need immediate support
**Insight**: Enables supervisors to provide real-time assistance
---
#### Q25: "What percentage of tonight's assemblies have passed quality checks so far?"
**Purpose**: Demonstrates shift-level real-time KPI monitoring
**Expected Query**: FILTER shift = "Night" AND assemblyDatetime >= shift_start, calculate pass rate
**Key Metrics**: Real-time first-pass yield for current shift
**Insight**: Enables shift supervisors to take corrective action before shift ends
---
## 🎬 Demo Flow Recommendations
### **5-Minute Executive Demo**
Focus on high-level business value:
1. Q4 - Overall quality performance ✅
2. Q7 - Workforce workload balance 👷
3. Q10 - Machine incidents → quality correlation 🔗
4. Q13 - BOM complexity overview 🔩
**Key Message**: "From 121K entities, get instant business insights - quality metrics, workforce analytics, and root cause analysis in seconds"
---
### **15-Minute Technical Demo**
Show discovery + analysis capabilities:
1. Q1 - What data is available? 🔍
2. Q2 - Deep dive on Assembly Records 🔍
3. Q4 - Quality metrics analysis ✅
4. Q5 - Failed assemblies investigation ✅
5. Q10 - Incident correlation 🔗
6. Q16 - Complex semantic filtering 🧠
7. Q20 - SPARQL generation assistance 🧠
**Key Message**: "Discover, query, and analyze manufacturing data using semantic relationships - no SQL expertise required"
---
### **30-Minute Deep Dive Demo**
Complete capabilities showcase:
1. **Discovery** (Q1, Q2, Q3) - Understand the knowledge graph
2. **Quality** (Q4, Q5, Q6) - Production quality analytics
3. **Workforce** (Q7, Q8, Q9) - Performance and capacity
4. **Root Cause** (Q10, Q11, Q12) - Graph-powered investigation
5. **BOM** (Q13, Q14, Q15) - Supply chain impact
6. **Advanced** (Q16, Q17, Q18, Q19) - Complex semantic queries
7. **Ontology** (Q21, Q22) - Semantic model exploration
8. **Real-Time** (Q23, Q24, Q25) - Operational decision support
**Key Message**: "Complete Manufacturing Intelligence platform - from data discovery to real-time operational decisions, powered by knowledge graphs"
---
## 🎯 Expected Success Metrics
After completing demo questions, the GenAI Agent should demonstrate:
✅ **100% Query Success Rate** - All questions answered with valid SPARQL
✅ **Sub-second Response Times** - Most queries return in <1 second
✅ **Business Insights Generated** - Not just data, but actionable intelligence
✅ **Semantic Understanding** - Leverages graph relationships effectively
✅ **Zero External API Calls** - All analysis happens within AGS MCP Server
---
## 📝 Usage Instructions
1. **Load System Prompt**: Configure your GenAI agent with the system prompt above
2. **Start with Discovery**: Begin demo with Q1-Q3 to set context
3. **Choose Demo Length**: Use 5/15/30-minute flows based on audience
4. **Encourage Follow-ups**: After each answer, invite audience to ask deeper questions
5. **Show SPARQL** (optional): For technical audiences, reveal the generated queries
6. **Emphasize Graph**: Highlight when relationships (not just filters) solve the problem
---
## 🔧 Configuration Checklist
Before demo:
- ✅ MCP Server running on http://127.0.0.1:8000/sse
- ✅ AGS connection verified (graphstudio.mendixdemo.com:443)
- ✅ Ontology cache populated (for fast discovery)
- ✅ Test Q1 to verify end-to-end functionality
- ✅ Have COMPREHENSIVE_TEST_REPORT.md ready for credibility
- ✅ Prepare backup queries in case of network issues
---
## 🎓 Quick Reference Card for GenAI Agent
### Most Common URIs (from Discovery)
**Assembly Record Class:**
**Key Properties:**
- Quality Check: `...Model#AssemblyStagesItemid.AssemblyRecord.qualityCheck`
- Shift: `...Model#AssemblyStagesItemid.AssemblyRecord.shift`
- Operator: `...Model#AssemblyStagesItemid.AssemblyRecord.operator`
- Machine ID: `...Model#AssemblyStagesItemid.AssemblyRecord.machineId`
- Assembly Datetime: `...Model#AssemblyStagesItemid.AssemblyRecord.assemblyDatetime`
- Item ID: `...Model#AssemblyStagesItemid.AssemblyRecord.itemId`
**⚠️ IMPORTANT**: Never hardcode these URIs. Always use discovery tools to get current URIs in case the graphmart structure changes.
### Discovery Tool Selection Guide
| Question Type | First Tool to Use | Second Tool | Purpose |
|--------------|-------------------|-------------|---------|
| "What data exists?" | `discover_knowledge_overview` | `discover_available_ontologies` | High-level profiling |
| "Tell me about [Class]" | `discover_knowledge_overview` | `discover_class_data_properties` | Class details |
| "How many [entity]?" | `discover_knowledge_overview` | `execute_sparql_query` | Get class URI, then count |
| "Quality performance" | `discover_knowledge_overview` | `discover_class_data_properties` | Find quality property |
| "Shift correlation" | `discover_class_data_properties` | `execute_sparql_query` | Find shift + quality properties |
| "Operator performance" | `discover_class_data_properties` | `execute_sparql_query` | Find operator property |
| "Machine incidents" | `discover_class_object_properties` | `execute_sparql_query` | Find relationships |
### SPARQL Query Templates
**Quality Breakdown (Q4):**
```sparql
SELECT ?qualityCheck (COUNT(?record) as ?count)
WHERE {
?record a <CLASS_URI_FROM_DISCOVERY> .
?record <QUALITY_PROPERTY_URI_FROM_DISCOVERY> ?qualityCheck .
}
GROUP BY ?qualityCheck
ORDER BY DESC(?count)
Shift vs Quality (Q6):
SELECT ?shift ?qualityCheck (COUNT(?record) as ?count)
WHERE {
?record a <CLASS_URI_FROM_DISCOVERY> .
?record <QUALITY_PROPERTY_URI_FROM_DISCOVERY> ?qualityCheck .
?record <SHIFT_PROPERTY_URI_FROM_DISCOVERY> ?shift .
}
GROUP BY ?shift ?qualityCheck
ORDER BY ?shift ?qualityCheckTop N Operators (Q7):
SELECT ?operator (COUNT(?record) as ?count)
WHERE {
?record a <CLASS_URI_FROM_DISCOVERY> .
?record <OPERATOR_PROPERTY_URI_FROM_DISCOVERY> ?operator .
}
GROUP BY ?operator
ORDER BY DESC(?count)
LIMIT 10If query returns empty results:
- ✅ Did you use discovery tools first?
- ✅ Did you use the full URI from discovery (not a simplified version)?
- ✅ Did you check for typos in the URI?
- ✅ Did you verify the property exists on that class?
If discovery returns no properties:
- ✅ Are you using the correct class URI?
- ✅ Try
discover_knowledge_overviewfirst to see all classes - ✅ Check if the class has instances (instance_count > 0)
If results seem incorrect:
- ✅ Verify you're filtering/grouping on the right properties
- ✅ Check for case sensitivity in filter values
- ✅ Ensure you're using proper SPARQL syntax
Document Version: 1.1
Last Updated: September 30, 2025
Owner: Demo Team
Status: ✅ Ready for Production Use
Changelog:
- v1.1: Added URI discovery workflow, common mistakes, troubleshooting guide
- v1.0: Initial release