Kundenprofil
Der Analyst arbeitet in einem kleinen Automotive-Engineering- oder OEM-Supplier-Team, das dafür verantwortlich ist, aus alten 2D-CAD-Zeichnungen dimensionsrelevante Informationen zu extrahieren. Die Quelldaten sind DXF-Dateien — das branchenübliche Format, exportiert aus Tools wie AutoCAD, CATIA und SolidWorks — und die nachgelagerten Nutzer umfassen Simulationsteams, Fertigungsplaner und Prüfer für Maßhaltigkeit. Das Team arbeitet an der Schnittstelle von Reverse Engineering und Digital-Twin-Vorbereitung, wobei die Genauigkeit der rekonstruierten Geometrie direkte Auswirkungen auf nachgelagerte Werkzeuge und Prozessentscheidungen hat. Die meisten Eingangszeichnungen des Teams sind Single-File-Layouts mit mehreren Ansichten: Seiten-, Front- und Draufsichten, kodiert in einer einzigen DXF, ohne zusätzlich verfügbares 3D-CAD-Modell.
Problem
Vor dem Einsatz von energent.ai verließ sich das Team auf einen layerbasierten Ansatz zur Tiefeninferenz, um 2D-DXF-Geometrie in eine Pseudo-3D-Darstellung zu überführen. Das Kernproblem war ein systematisches Überfüllen: Immer wenn die Quelldatei nicht genügend Multi-View-Abdeckung bot, vergab der Algorithmus heuristische Tiefenwerte, statt diese Bereiche als nicht unterstützt zu markieren. Die erfundene Geometrie machte die Rekonstruktionsergebnisse für nachgelagerte Pipelines unzuverlässig, und das Fehlen von Provenienzdaten machte es unmöglich zu diagnostizieren, welcher Zeichnungsbereich für eine bestimmte Maßabweichung verantwortlich war.
Für das analysierte Fahrzeug — beschrieben durch eine einzelne maßgebliche Zeichnungsdatei (kavz-3244.dxf) — war der Benchmark-Rahmen exakt vorgegeben:
- Länge: 7,895.0 mm
- Höhe: 2,820.0 mm
- Breite: 2,210.0 mm
Die vom alten Workflow erzeugten Dashboard-Ausgaben ließen sich in keiner sinnvollen Weise gegen diese Zielwerte validieren. Es wurde zwar ein visuell vollständiges 3D-Rendering erzeugt, aber dem Team fehlte eine Artefaktkette, die jedes gerenderte Oberflächenelement mit einer bestimmten Ansicht oder einem Zeichnungsbereich verknüpft hätte. Jede Abweichung zwischen dem gerenderten Modell und der Zielvorgabe war nicht von einem realen Maßfehler zu unterscheiden, sondern von einem Artefakt des heuristischen Füllens. Die frühere Pipeline hatte außerdem mehrere Zwischen- und Visualisierungsdateien erzeugt, die nie formal als maßgeblich oder ersetzt gekennzeichnet worden waren, sodass das Team unsicher war, welche Ausgaben für nachgelagerte Entscheidungen verwendet werden sollten.
Warum jetzt
Der Druck, eine vertrauenswürdige Rekonstruktion zu liefern, entstand aus zwei zusammenlaufenden Faktoren. Erstens hatten nachgelagerte Simulations- und Fertigungsteams begonnen, Maßabweichungen in Modellen zu beanstanden, die aus dem Rekonstruktions-Workflow übergeben wurden — und ohne Provenienzdaten konnte das Rekonstruktionsteam nicht erklären, welche Zeichnungsansicht welche Messung geliefert hatte oder ob eine Lücke absichtlich oder heuristisch entstanden war. Zweitens hatte das Team gerade eine Fahrzeugzeichnung mit vollständig spezifizierten Zielmaßen erhalten, wodurch ein konkreter Benchmark entstand, an dem die Genauigkeit der alten Pipeline direkt und öffentlich gemessen werden konnte. Ein fehlgeschlagener Übergabeprozess bei einem bemaßten Benchmark wäre ein sichtbares Qualitätsereignis gewesen, kein stiller, durch Toleranzen aufgefangener Mismatch. Das Team brauchte einen Rekonstruktionsansatz, der vor der nächsten Benchmark-Prüfung prüfbare, sparsame Ausgaben erzeugen konnte — und zwar schnell genug, dass ein kompletter Neuaufbau der Pipeline in einer Scripting-Umgebung nicht praktikabel war.
Warum energent.ai
Das Team prüfte mehrere Alternativen. Tabellenkalkulationsbasierte Analysen konnten weder DXF-Geometrie parsen noch eine Multi-Artefakt-Orchestrierung in irgendeinem relevanten Umfang bewältigen. Spezialisierte 3D-Rekonstruktionssoftware hätte erhebliche Lizenzinvestitionen und tiefes CAD-Fachwissen erfordert, um sie für diesen One-File-Evidence-First-Workflow zu konfigurieren. Die Einstellung eines weiteren Analysten hätte weder die Provenienzlücke noch das Problem des heuristischen Füllens gelöst — das waren Pipeline-Designprobleme, keine Ressourcenprobleme.
energent.ai bot einen qualitativ anderen Weg. Der Agent konnte die DXF-Datei direkt laden, Python-Rekonstruktionsskripte innerhalb der Session ausführen, Zwischen-JSON-Artefakte erzeugen und prüfen, konfigurierbare QC-Gate-Logik anwenden und ein interaktives HTML-Dashboard erzeugen — alles in einer einzigen iterativen Session ohne Kontextverlust zwischen den Schritten. Entscheidend war, dass der Agent auf Prompt-Ebene angewiesen werden konnte, eine Evidence-First-Policy durchzusetzen: Geometrie nur dort zu rendern, wo die View-Daten sie tatsächlich stützen, nicht unterstützte Bereiche sparsam statt gefüllt zu lassen und für das finale 3D-Panel nicht auf Layer-Lift-Heuristiken zurückzufallen. Kein anderes Tool im Zugriff des Teams kombinierte Dateieingang, skriptgestützte Geometrieverarbeitung, QC-Gating und Visualisierungsübergabe, ohne eine separate Entwicklungsumgebung und einen längeren Implementierungszyklus zu erfordern.
Workflow
Der Analyst lud kavz-3244.dxf als einzelne maßgebliche Quelldatei und startete eine Rekonstruktionssession mit expliziten Zielmaßen und einem Evidence-First-Instruktionssatz.
Schritt 1 — View-Segmentierung. Der Agent analysierte die DXF und segmentierte sie in View-Bereiche — Seiten-, Front- und Draufsichten — und erzeugte dabei ein dediziertes Segmentierungsartefakt (kavz-3244_view_segmentation_v2.json). Der Analyst prüfte die Zuordnung der Regionenrollen, um sicherzustellen, dass die Labels die endgültige Rolle und nicht die Seed-Window-Abstammung aus dem Segmentierungsalgorithmus widerspiegelten; eine frühere Version hatte Regionsnamen verwendet, die von Initialisierungsfenstern statt von bestätigten View-Zuordnungen abgeleitet waren, und der Analyst hatte dies vor dem Fortfahren erkannt und korrigiert.
Schritt 2 — Feature-Korrespondenz. Der Agent extrahierte viewübergreifende Feature-Korrespondenzen (kavz-3244_feature_correspondence.json) und verknüpfte Geometrieelemente über die Ansichten hinweg mit der Platzierung von Grundschnitten in Multi-View-Evidenz statt mit einer Einzelansichtsprojektion. Dieser Schritt unterscheidet eine Evidence-First-Rekonstruktion von einer heuristischen Tiefenzuordnung: Ein Feature muss in mehr als einer Ansicht erscheinen, bevor es einen Platz im rekonstruierten Envelope erhält.
Schritt 3 — Section-Slicing. Mithilfe der Korrespondenzdaten erzeugte der Agent Sectionschnitte durch den rekonstruierten Envelope (kavz-3244_section_slices.json). Die Schnitte wurden nur dort platziert, wo viewübergreifende Unterstützung vorhanden war; Bereiche ohne ausreichende Korrespondenz-Evidenz blieben leer, wodurch eine Rekonstruktion entstand, die ehrlich über ihre Abdeckungslücken ist, statt visuell vollständig, aber geometrisch erfunden zu sein.
Schritt 4 — Rekonstruktions-QC. Ein dediziertes QC-Artefakt (kavz-3244_reconstruction_qc.json) erfasste für jede konfigurierte Prüfung den Nachweis des Gate-Passings. Der Analyst prüfte diese Ausgabe, um sicherzustellen, dass die Gates aus den richtigen Gründen bestanden wurden — nicht nur, dass das Pass/Fail-Flag korrekt gesetzt war, sondern dass die zugrunde liegende Evidenz mit der Absicht jedes Gates übereinstimmte — bevor er den finalen Visualisierungsschritt freigab.
Schritt 5 — Provenienzgetaggte Geometrie. Die maßgebliche Rekonstruktionsdatei (kavz-3244_reconstructed_geometry_v2.json) konsolidierte die abschnittsbasierte Geometrie mit Provenienz-Tags, die die Quellansicht für jedes Element identifizierten, und schuf so eine nachvollziehbare Verbindung zwischen jeder gerenderten Oberfläche und den zugrunde liegenden Zeichnungsdaten.
Schritt 6 — Dashboard-Generierung. Der Agent erzeugte das finale HTML-Dashboard (kavz-3244_dashboard_v3.html) unter einer expliziten Anweisung, für das Haupt-3D-Panel kein Layer-Lift-Fallback zu verwenden. Das Dashboard rendert ausschließlich aus dem geprüften Rekonstruktionsartefakt und macht die Visualisierung damit direkt auf die QC-gegateeten Pipeline-Ausgaben zurückführbar. Zwei frühere Dashboard-Versionen und mehrere Debug-Dateien wurden formal als ersetzt gekennzeichnet und aus dem finalen Authority-Set ausgeschlossen, wodurch das Team einen eindeutigen Nachweis darüber erhielt, welche Ausgaben downstream zu verwenden sind.
Ergebnisse
Die evidenzbasierte Pipeline erzielte gegen den definierten Benchmark die folgenden Ergebnisse:
| Dimension | Ziel | Erreicht | Delta |
|---|---|---|---|
| Länge | 7,895.0 mm | 7,895.0 mm | 0.0 mm |
| Breite | 2,210.0 mm | 2,210.0 mm | 0.0 mm |
| Höhe | 2,820.0 mm | 2,763.6 mm | −56.4 mm |
Länge und Breite entsprachen dem Ziel exakt. Die Höhe blieb um 56.4 mm unter dem Ziel, was auf eine schwächere Abdeckung der Draufsicht/Frontansicht in der Quell-DXF zurückzuführen ist — eine bekannte und dokumentierte Einschränkung, die innerhalb der konfigurierten Toleranzgrenze des Plans blieb. Alle konfigurierten QC-Gates wurden bestanden.
Über die Maßgenauigkeit hinaus lieferte die Rekonstruktion drei qualitative Ergebnisse, die die vorherige Pipeline nicht leisten konnte:
- Vollständige Provenienz. Jedes Geometrieelement trägt ein Tag zur Quellansicht, wodurch Abweichungen diagnostizierbar statt undurchsichtig werden. Die Höhenlücke von 56.4 mm ist auf die schwache Abdeckung von oben/vorne zurückzuführen, nicht auf einen Pipeline-Fehler — und das QC-Artefakt hält diese Zuordnung ausdrücklich fest.
- Ehrliche Sparsamkeit. Nicht unterstützte Bereiche bleiben leer, statt mit heuristischer Tiefe gefüllt zu werden. So wissen nachgelagerte Simulations- und Fertigungsteams genau, welche Zonen zusätzliche Quelldaten benötigen, bevor toleranzrelevante Entscheidungen getroffen werden können.
- Nachvollziehbares Dashboard. Das HTML-Dashboard rendert aus einem einzigen, durch QC freigegebenen Artefakt statt aus Roh-Layer-Daten. Dadurch erhalten Prüfer einen klaren Übergabevertrag und die Unklarheit entfällt, die durch die frühere Menge nicht benannter Zwischenfiles entstand.
Die Pipeline erzeugte außerdem fünf benannte Zwischenartefakte, die als Prüfpunkte für künftige Rekonstruktionsläufe dienen und die Zeit verkürzen, die zur Diagnose von Regressionen oder zur Rückverfolgung einer Maßabweichung bis zur Quelle benötigt wird.
Nachweis
"Die alte Pipeline lieferte uns ein visuell vollständiges Modell, aber wir hatten keine Möglichkeit, ihm zu vertrauen — besonders rund um das Dach und die Frontverkleidung, wo unsere Zeichnungsabdeckung schwach war. Ich brauchte etwas, das mir die Lücken zeigt, statt sie zu verstecken. Die energent.ai-Session hat die gesamte Pipeline um Evidenz-Gates herum neu aufgebaut, und das QC-JSON sagte mir genau, warum jedes Gate bestanden wurde. Das ist eine andere Art von Ergebnis als das, was wir vorher hatten."
— Zusammengesetztes Zitat, das die in dieser Fallstudie beschriebene Rolle des CAD-/Engineering-Analysten widerspiegelt
Das finale Deliverable — kavz-3244_dashboard_v3.html — präsentiert die pseudo-3D-Rekonstruktion mit abschnittsbasierter Geometrie, provenance-markierten Elementen und Panels mit Maßzusammenfassung. Das QC-Artefakt (kavz-3244_reconstruction_qc.json) liefert die den Dashboard zugrunde liegenden Nachweise für die bestandenen Gates und steht zusammen mit diesem zur Prüfung bereit.
Vertrauenshinweis
Die hier beschriebene Rekonstruktion ist eine abschnittsbasierte pseudo-3D-Darstellung, abgeleitet aus einer einzelnen 2D-DXF-Quelle, kein vollständiges parametrisches CAD-Modell. Der Höhenunterschuss von 56.4 mm spiegelt eine reale Einschränkung in der Abdeckung der Draufsicht/Frontansicht der Quelldaten wider — er ist kein Produktfehler und verschwindet nicht durch Anpassung von Visualisierungsparametern. Teams, die diese Ausgabe für nachgelagerte Simulation, Fertigungswerkzeuge oder die Prüfung der Maßhaltigkeit verwenden, sollten die sparsamen Zonen als Bereiche behandeln, die zusätzliche Quelldateien oder Punktwolkendaten erfordern, bevor toleranzrelevante Entscheidungen getroffen werden. Die QC-Gates des Agenten bestätigen die interne Konsistenz der Rekonstruktionspipeline; sie zertifizieren weder die Konformität mit einem externen Maßstandard noch ersetzen sie ein physisches Messprotokoll.