What they need¶
What Theegarten-Pactec expects from an AI engineering tool — from Marcel Eggert’s emails, LOI, and diligence notes.
Who we are talking to¶
Dr.-Ing. Marcel Eggert — Engineering. He is doing technical diligence, not browsing vendors. By his third email he sent an explicit requirements list.
Benedikt Schulte — Director of Engineering & Development — signed the LOI.
Their agenda for the meeting (~1 h):
- Introductions
- AI in SOLIDWORKS-based mechanical engineering
- Interfaces & data security
- Use cases & next steps
They also run their own AI exploration internally — we must be concrete, not generic.
Must have (deal-breakers)¶
| Topic | What Marcel said | What we show |
|---|---|---|
| Deployment | Local or controlled AI environment | Architecture: data stays in their network |
| Know-how | Design data must not leak | No training on their data; isolated project boundary |
| PLM | CIM Database is central | Read released objects; write back review report |
| Drawings & BOMs | Main value area | Live release-check on a real module story |
| Trust | Engineers must accept output | Human approval; finding → source link |
Should have (win the evaluation)¶
| Topic | Expectation |
|---|---|
| SOLIDWORKS | Works with their mechanical drawings / release packages |
| EPLAN | Cross-check electrical references where possible |
| Traceability | Consistent processes; audit-friendly findings |
| Transparency | No black box — show rule and location |
| Machinery / safety context | Speak competently about regulated machine design (no false “we certify” claims) |
| Reliability | Same demo repeatable; stable day-to-day use |
Later (phase 2 — do not over-promise in demo 1)¶
- Deep change-management automation
- Company-wide naming / terminology enforcement
- Engineering knowledge search across all projects
- Supplier quality forms (EMPB, inspection plans) — see Quality forms
Full requirements table (reference)¶
Priority 10 = must answer in the meeting or progress stops.
| ID | Requirement | Pri | Demo answer |
|---|---|---|---|
| R01 | Controlled / on-prem deployment | 10 | Data security |
| R02 | Protect design know-how | 10 | Policy + boundary diagram |
| R03 | LLM cybersecurity | 9 | Subprocessor / routing template |
| R04 | Fit existing workflows | 9 | PLM-triggered pilot |
| R05 | CIM Database integration | 9 | PLM integration |
| R06 | SOLIDWORKS | 8 | Drawing checks in demo |
| R07 | EPLAN | 8 | Cross-discipline step in demo |
| R08 | Drawings | 8 | Primary |
| R09 | BOMs | 8 | Primary |
| R10 | Data quality | 7 | Rule violations list |
| R11 | Prevent design errors | 7 | Pre-release findings |
| R12 | Traceable processes | 8 | Revision-linked report |
| R13 | Change management | 6 | Phase 2 |
| R14 | Machinery reg. / functional safety | 8 | Checklist language only |
| R15 | Naming / documentation standards | 6 | Phase 2 |
| R16 | Engineering knowledge | 6 | Phase 2 |
| R17 | Transparent outputs | 8 | Show sources in UI |
| R18 | Explainable suggestions | 8 | Finding IDs |
| R19 | Reliable daily use | 8 | Scripted demo |
| R20 | Employee trust | 7 | No auto-release |
| R21 | Repetitive task automation | 7 | Change summary draft |
| R22 | Process standardization | 7 | Release checklist |
| R23 | ~1 h demo | 5 | Demo day |
| R24 | Clear product scope | 8 | Opening slide |
Sources: EMail chain.txt, email investigation theegarten marcel.rtf, LOI.
Implications for the demo¶
Open with deployment + PLM, then run one module release check. Do not walk through all 24 rows — hit the Must have table above.
Problem detail: Use cases & problems · Next: Their tools → Release check demo