Skip to content

Use cases & problems

Problems and use cases identified from Marcel Eggert’s emails, the LOI, and diligence notes — mapped to what RapidDraft can address.

← Start here

How to read this page

Column Meaning
Problem Pain Theegarten described or that shows up in packaging-machine engineering
Use case What an AI assistant would do (check, flag, draft — not auto-design)
Phase When to promise it: Pilot 1 (first demo/SOW) · Later
Source Where we saw it

What Marcel wrote (email 3 + LOI)

Direct topics from his third email and LOI scope:

# Topic (his words) Underlying problem
1 Ensuring high data quality Part data, drawings, and BOMs inconsistent across systems
2 Preventing design errors Mistakes reach manufacturing because release review is manual and uneven
3 Consistent and traceable engineering processes Release quality depends on who is on the project
4 Supporting change management Change packages incomplete (mechanical, electrical, docs, PLM)
5 Machinery regulation & functional safety Regulated machine changes need checklist discipline, easy to miss steps
6 Standardization of naming, terminology, components, documentation Same part called different names; docs drift from BOM/drawing
7 Centralization of engineering expertise Know-how in emails and heads, not searchable in PLM
8 Processing of drawings and BOMs Highest explicit AI value — manual, repetitive, error-prone
9 Standardization and automation of technical processes No guided path through release/change workflow
10 Protection of know-how + controlled AI Cannot use public cloud AI on design data
11 Employee trust (transparent, traceable, reliable) Engineers will reject black-box or auto-release tools

Sources: EMail chain.txt (email 3), LOI_Theegarten-Pactec_GmbH_Co._KG.pdf, email investigation theegarten marcel.rtf

Four use-case areas (maturity path)

Same order as Release check demo — build capability step by step.

flowchart LR
    A[1 Drawings] --> B[2 BOMs]
    B --> C[3 Processes]
    C --> D[4 Automation]
Area Priority (investigation) Pilot phase One-line use case
Drawing processing 8 Pilot 1 Check SOLIDWORKS drawing package before CIM release
BOM processing 8 Pilot 1 (combined in demo story) Check BOM vs drawing vs EPLAN vs PLM
Process standardization 7 Later Guide/check complete change & release package
Repetitive task automation 7 Later Draft revision text, action lists, summaries

1 — Drawing processing & automation

Use case: AI-assisted drawing release checker before PLM release.
The AI does not change the drawing — it acts like a disciplined reviewer.

Problems this addresses

Problem Example (packaging machine context) Phase
Incomplete drawing package Missing dimensions, surface treatment, or interface notes on a folding-tool carrier Pilot 1
Title block / metadata mismatch Drawing Rev C but CIM object still Rev B Pilot 1
Material mismatch Title block 1.4301 vs BOM 1.4305 Pilot 1
Wrong assembly link Drawing linked to prototype assembly, not production Pilot 1
Tolerance / fit conflicts Bearing seat tolerance conflicts with mating shaft drawing Pilot 1
Datum / GD&T unclear Datum B referenced but not shown; inspection features not marked Pilot 1
Revision notes too vague “Geometry updated” without saying what changed Pilot 1
Manufacturability gaps M6 depth missing; edge breaks unclear on guide edges Pilot 1
Terminology drift Old name for folding head still on drawing Later
Shopfloor questions after release Slot tolerance or section views don’t show build-critical features Pilot 1

Checks the mechanical engineer cares about

  • Is the drawing complete enough for release?
  • Are functional dimensions and tolerances present where needed?
  • Are interfaces to neighboring modules documented?
  • Is the revision text meaningful?

Source: email investigation — Wedge 1 (folding-tool carrier scenario)

2 — Bill of materials (BOM) processing

Use case: AI-assisted BOM consistency checker across SOLIDWORKS, EPLAN, CIM Database, and purchasing rules.

Problems this addresses

Problem Example Phase
Drawing ↔ BOM mismatch Part numbers or quantities don’t match Pilot 1
Mechanical ↔ EPLAN drift Sensor bracket moved; EPLAN tag unchanged Pilot 1
Duplicate / near-duplicate parts Same function, different part numbers Later
Obsolete parts still on BOM Old revision parts not flagged Later
Missing supplier / manufacturer data Procurement blocks on incomplete BOM lines Later
Spare-part classification weak Service BOM not aligned with field needs Later
Custom parts when standard exists Preferred-part rules not enforced Later
Assembly / commissioning impact unclear BOM change without build or adjustment note Pilot 1

Why it matters commercially

BOM errors hit procurement, assembly, commissioning, and service — often harder than drawing-only issues.

Source: email investigation — Wedge 2; Marcel email 3 “Stücklisten”

3 — Standardization of technical processes

Use case: AI process assistant for a machine module change (sealing/folding unit, guarding, sensors, format conversion) — checks that required steps and documents are covered.

Problems this addresses

Problem Example Phase
Inconsistent change notes Some engineers detailed; others vague Later
Drawing updated, docs forgotten Service manual or commissioning checklist stale Later
Mechanical change, EPLAN missed Bracket moved 20 mm; no EPLAN update request Pilot 1 (flag in combined demo)
Safety review not documented Guard geometry changed; risk checklist not attached Later
Incomplete change package in PLM Drawing in package; assembly-level doc missing Later
Old revision still valid elsewhere One machine variant still on Rev B Later
Commissioning confusion Checklist still references old sensor position Later
Cross-module impact not stated Guide geometry change without neighbor interface note Later

Regulatory / safety angle (language only)

  • Guarding, access, sensors, emergency stop, moving parts
  • Machinery regulation and functional safety review triggers
  • Do not claim the software certifies compliance — support checklists and traceability

Source: email 3; email investigation — Wedge 3

4 — Automation of repetitive engineering tasks

Use case: AI drafts revision texts, action lists, design-review summaries, and change summaries from approved engineering data — engineer edits and signs off.

Problems this addresses

Problem Example Phase
Manual revision writing Same boilerplate retyped every ECO Later
Slow design-review prep Lead engineer assembles package by hand Later
Knowledge lookup slow “How did we solve this on the last wrapper line?” Later
Documentation improvement tedious Suggesting better notes/terms is manual Later

Source: email 1 (repetitive tasks); email investigation — Wedge 4

Cross-cutting problems (all use cases)

These appear in every email — not optional.

Problem Use case response Phase
Design know-how must not leak Controlled / on-prem processing; no cross-customer training Pilot 1
AI must fit CIM workflow Trigger on release state; read PLM; attach report Pilot 1
Engineers don’t trust black box Finding → source (sheet, BOM line, rule ID) Pilot 1
No autonomous release Human approves every release Pilot 1
Unclear product scope One pilot wedge: drawing + BOM release check Pilot 1
Internal AI competition Be concrete; show engineering artifacts, not chat Pilot 1

Details: Data security · What they need

Problems by discipline (quick lookup)

Discipline Typical problems See section
Mechanical design Incomplete drawings, fits, revisions, interfaces § 1 Drawings
Electrical EPLAN vs mechanical mismatch § 2 BOMs
PLM / process Metadata, change package, workflow state § 1, § 3
Quality / inspection Datums, inspection notes, downstream EMPB lineage § 1; Quality forms
Shopfloor / commissioning Unclear build/adjustment impact § 2, § 3
Procurement / service BOM data, spares, obsoletes § 2
IT / security Where data is processed, audit trail Cross-cutting

What they are not asking for (first meeting)

From diligence notes — avoid over-promising:

  • Generic “AI transforms engineering” keynote
  • Fully autonomous design or release
  • Perfect CIM integration on day one (phased is OK)
  • Chatbot that answers anything without engineering sources
  • Replacing SOLIDWORKS, EPLAN, or CIM Database

Source: email investigation theegarten marcel.rtf

Pilot 1 deliverable Problems covered
Release check on one module family Drawing completeness, metadata, BOM/EPLAN cross-check, traceability
Findings report in PLM Process traceability, engineer trust
Controlled deployment Know-how, cybersecurity
Optional: 2 min on quality form lineage Downstream inspection (phase 2 teaser)

Success metrics (from investigation):

  • Findings with valid source links
  • Issues caught before release
  • Engineer acceptance rate
  • Shorter review time per change package

Phase 2 — adjacent problems (quality / supplier)

Not from Marcel’s first email priority, but in template research and cerpro.io context:

Problem Use case Page
Manual copy drawing → Excel → EMPB Extract characteristics → inspection plan / EMPB Quality forms
Inconsistent supplier quality docs Template-based EMPB, series reports Quality forms
Audit prep for characteristic lists Document register + traceability Quality forms

RapidDraft primary wedge remains upstream release, not Cerpro-style downstream QA.

Source map

Content on this page File
Email 3 bullet list EMail chain.txt
LOI indicative scope LOI_Theegarten-Pactec_GmbH_Co._KG.pdf
Priority scores, 4 wedges, example flags email investigation theegarten marcel.rtf
Quality / EMPB adjacent theegarten_pactec_quality_templates.md, CERPRO_deepresearchreport_GPT.md