Benjamin Admin
b1357915ae
Generische Pattern-Engine-Optimierung: behebt zwei Seiten derselben Wurzel (inkonsistente Applicability-Deklaration ueber 1216 Patterns). - Ghost-Patterns (120, feuerten nie): 34 nicht-erzeugbare Required-Tags via domaenenspezifische Keywords emittierbar gemacht -> 0. - Cross-Domain-Leakage (25, feuerten ueberall): neuer text-getriebener Capability-Domain-Gate (pattern_domain_gates.go) — Pattern mit Fremdmaschine im Szenariotext bekommt dom_*-Tag als Required-Gate -> 0. - Resolver: Komponente->TypicalEnergySources-Expansion (strukturierte Projekte). - Benchmark: GT-Platzhalter-Filter; faithful Cross-GT-Narrative-Harness. - Harte Regression-Guards: Ghosts=0, Leakage=0, Coverage>=90% (beide GTs). - HP2000/HP2001 (Secondary-Harm-Demos) in AllowlistKnownGaps -> Suite gruen. Echte Pipeline beide GTs: Coverage 100%/100%, 0 Leaks, 0 Ghosts. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
5.5 KiB
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
-
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.
-
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.
-
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".
-
GT 2.11 „Brand durch Kurzschluss durch eindringendes Wasser" Schutzart-bezogenes Pattern (IPxy) fehlt für Hubgeräte.
Sonderfälle (1)
- 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)
-
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.
-
Misuse-Pattern HP2220 — bestimmungswidrige Personenbeförderung als eigenes Pattern für Hub-/Hebezeuge.
-
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. -
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:
cd ai-compliance-sdk
go test -v -vet=off -run TestKistenhub_GTCoverage ./internal/iace/