# Kistenhubgerät GT — Recall/Precision Memo

**Stand:** 2026-06-09
**GT-Quelle:** `breakpilot-core/docs-src/Kistenhubgeräte GT.xlsx` (37 Einträge, 4 Hazard-Gruppen)
**Engine:** Pattern-Bibliothek aktuell auf main (HP2100-2102 Lift-Bridge + M600-M604, SHA `c771d8e`)
**Test:** `internal/iace/gt_kistenhub_test.go` (in-memory, kein DB, reproduzierbar via `go test -v -run TestKistenhub_GTCoverage`)

---

## Headline-Zahlen

| Metrik | Wert | Vergleich Bremse-GT |
|---|---|---|
| **Hazard Coverage** | **81,1 %** (30/37 erkannt) | Bremse: 85 % (51/60) |
| **Realer Recall** (ohne Platzhalter)¹ | **85,7 %** (30/35) | — |
| **Measure Coverage** | **100 %** | Bremse: 90,2 % |
| **Engine-Hazards** | 83 (davon 53 extra) | Bremse: 109 (58 extra) |
| **Precision** | 36,1 % | Bremse: 46,8 % |

¹ Zwei der 37 Einträge sind GT-seitige Platzhalter ohne Inhalt (`1.15` „weitere Risikominderung" und `Allgemeine MaschinenRiL`-Zeile) — die zählen nicht als reale Misses.

---

## Lift-Bridge Verifikation (eigentliches Ziel)

Die Lift-Bridge wurde am 22.05.2026 (SHA `c771d8e`) gebaut, um die Lücke bei körperteil-spezifischen Quetsch-Gefährdungen unter absenkenden Hubplattformen zu schließen. Dieses GT testet, ob die Bridge bei einem realen Kistenhubgerät-Projekt wirklich greift.

| Pattern / Measure | Ergebnis |
|---|---|
| HP2100 (Fuß-Quetschung unter absenkender Hubplattform) | ✅ feuert |
| HP2101 (Hand-Quetschung am Bodenanschlag) | ✅ feuert |
| HP2102 (Bein-Quetschung im Scherenmechanismus) | ✅ feuert |
| M600 (Bodenanschlag-Geometrie nach EN 1570-1) | ✅ feuert |
| M601 (akustisches Senk-Warnsignal) | ✅ feuert |
| M602 (manuelles Absenken bei Last-Erkennung) | ✅ feuert |
| M603 (Sicherheitsabstand zum Scherenmechanismus) | ✅ feuert |
| M604 (Endschalter mit redundanter Überwachung) | ✅ feuert |

**Befund:** Bridge funktioniert wie konstruiert. Alle 3 Patterns + alle 5 Mitigations werden ausgelöst, sobald `MachineTypes` `{lift, hoist, scissor_lift, elevator}` enthält und die C014/EN03-Tags geliefert werden.

---

## Coverage per Hazard-Gruppe

| Gruppe | Coverage | Misses |
|---|---|---|
| Mechanische Gefährdungen | **21/22 (95 %)** | nur GT 1.15 (Platzhalter) |
| Ergonomische Gefährdungen | **2/2 (100 %)** | — |
| Elektrische Gefährdungen | **7/11 (64 %)** | 4 reale Misses |
| Zusätzliche Gefährdungen | 0/2 (0 %) | GT 11.1 + 1 Platzhalter |

---

## Reale Misses (5 Stück)

### Elektrik (4) — größte Lücke

1. **GT 2.3** „Direktes oder indirektes Berühren von spannungsführenden Teilen"
   *Pattern für lift+IP-Schutz vermisst* — HP1640/HP1685 sind robot-cell-spezifisch und greifen nicht bei MachineTypes=lift.

2. **GT 2.6** „Gefährliche Berührungsspannung an berührbaren Teilen"
   *gleiche Lücke wie 2.3* — Niederspannungs-Direkt-Berührung an Mobilgeräten fehlt als eigenes Pattern.

3. **GT 2.8** „Beschädigen/Ausreißen verlegter Leitungen"
   *Pattern für mechanische Leiterschädigung an mobilen Geräten fehlt.* Stolperfalle (1.2) gibt es, aber kein Pattern für „Anschlusskabel wird unter Last gequetscht".

4. **GT 2.11** „Brand durch Kurzschluss durch eindringendes Wasser"
   *Schutzart-bezogenes Pattern (IPxy) fehlt für Hubgeräte.*

### Sonderfälle (1)

5. **GT 11.1** „Bestimmungswidrige Personenbeförderung — Sturz"
   *Misuse-Pattern fehlt komplett.* Allgemeines Problem mehrerer Hubgeräte; käme ggf. unter „missuse_prevention" als eigene Bridge.

---

## Precision-Bewertung

Engine erzeugt 83 Hazards bei 30 GT-Treffern → 53 Extras → Precision 36 %.

Das ist niedriger als Bremse (47 %), aber nicht alarmierend:
- Kistenhubgerät hat NUR 37 GT-Einträge (Bremse: 60) — kleinere Nenner-Basis macht Precision empfindlicher.
- Die Engine fährt mit allen Lifecycle-Phasen + großzügigen CustomTags (`hand_operated`, `mobile_machine`) gegen ein relativ einfaches Gerät. Real würde der Operator das Narrative schmaler halten (z. B. nur „Niederspannung, Hand-betrieben, kein Hydraulik-Kreislauf").

**Wenn das ein Verkaufs-Test wäre:** Engine zeigt 83 Hazards, Fachmann sichtet → 30 sind GT-richtig, 53 sind plausibel-aber-aussortierbar. Aufwand: ~30 Min Sichten statt 2,5 Tage Aufbau von Null. Werte entsprechen der Business-Aussage (siehe `project_iace_benchmark_results.md`).

---

## Nächste Schritte (Vorschlag)

1. **Elektrik-Bridge für Mobilgeräte** — eigenes Pattern-Set HP2200-2210 mit `MachineTypes={lift, hoist, mobile_machine}` für:
   - Berührungsspannung an berührbaren Niederspannungsteilen
   - Schutzart IP gegen Wasser/Spritzwasser
   - Mechanische Schädigung verlegter Anschlussleitungen
   → würde Elektrik-Coverage von 64 % auf ~90 % heben.

2. **Misuse-Pattern HP2220** — bestimmungswidrige Personenbeförderung als eigenes Pattern für Hub-/Hebezeuge.

3. **Precision-Tuning** — die `isPatternRelevant`-Narrative-Filter-Logik gegen Lift-Narrative validieren (kommt bisher von Roboter-Zelle her). Schwer zu sagen ohne den parsed-narrative-Output.

4. **Zweite GT „im Feld"** — Excel-Schema steht, weitere Maschinen (Stapler, Pressen) lassen sich gleich nachziehen.

---

## Test-Wartung

Der Test `TestKistenhub_GTCoverage` ist **non-strict**: er loggt nur, schlägt nicht bei Coverage-Drop fehl. Das ist Absicht für die erste Iteration. Sinnvolle Schwellen (z. B. „Hazard Coverage ≥ 75 %, Lift-Bridge muss feuern") können nachgezogen werden, sobald die Engine stabilisiert ist und wir die Erwartungen einfrieren wollen.

Reproduktion:
```bash
cd ai-compliance-sdk
go test -v -vet=off -run TestKistenhub_GTCoverage ./internal/iace/
```