Profilo del cliente
L’analista lavora all’interno di un piccolo team di ingegneria automotive o di un fornitore OEM responsabile dell’estrazione di informazioni dimensionali da disegni CAD 2D legacy. I materiali di partenza sono file DXF — il formato standard del settore esportato da strumenti come AutoCAD, CATIA e SolidWorks — e gli utenti a valle includono team di simulazione, pianificatori di produzione e revisori della conformità dimensionale. Il team opera all’intersezione tra reverse engineering e preparazione del digital twin, dove l’accuratezza della geometria ricostruita influisce direttamente sugli strumenti e sulle decisioni di processo downstream. La maggior parte dei disegni di input del team è costituita da layout multi-vista in un unico file: proiezioni laterali, frontali e dall’alto codificate in un singolo DXF, senza alcun modello CAD 3D supplementare disponibile.
Problema
Prima di adottare energent.ai, il team si affidava a un approccio di inferenza della profondità basato sui layer per trasformare la geometria DXF 2D in una rappresentazione pseudo-3D. Il problema principale era il riempimento sistematico eccessivo: ogni volta che il disegno sorgente non offriva una copertura multi-vista sufficiente, l’algoritmo assegnava valori di profondità euristici invece di segnalare quelle aree come non supportate. La geometria fabbricata rendeva i risultati della ricostruzione inaffidabili per le pipeline downstream, e l’assenza di dati di provenienza rendeva impossibile diagnosticare quale regione del disegno fosse responsabile di una determinata discrepanza dimensionale.
Per il veicolo in analisi — descritto da un singolo file di disegno autorevole (kavz-3244.dxf) — l’inviluppo di riferimento era specificato con precisione:
- Length: 7,895.0 mm
- Height: 2,820.0 mm
- Width: 2,210.0 mm
Gli output del dashboard generati dal vecchio flusso non potevano essere convalidati rispetto a quei target in alcun modo significativo. Veniva prodotto un rendering 3D visivamente completo, ma il team non disponeva di alcuna catena di artefatti che collegasse ogni elemento superficiale renderizzato a una vista o a una regione del disegno specifica. Qualsiasi discrepanza tra il modello renderizzato e la specifica target era indistinguibile tra un reale gap dimensionale e un artefatto del riempimento euristico. Il flusso precedente aveva inoltre generato diversi file intermedi di debug e visualizzazione che non erano mai stati formalmente designati come autorevoli né sostituiti, lasciando il team incerto su quali output dovessero essere usati per le decisioni downstream.
Perché adesso
La pressione per consegnare una ricostruzione affidabile derivava da due forze convergenti. In primo luogo, i team di simulazione e produzione downstream avevano iniziato a segnalare discrepanze dimensionali nei modelli consegnati dal workflow di ricostruzione — e, in assenza di dati di provenienza, il team di ricostruzione non poteva spiegare quale vista del disegno fornisse ciascuna misura o se un gap fosse intenzionale o euristico. In secondo luogo, il team aveva appena ricevuto un disegno del veicolo con dimensioni target completamente specificate, creando un benchmark concreto rispetto al quale l’accuratezza del vecchio flusso poteva essere misurata direttamente e pubblicamente. Un handoff fallito su un benchmark dimensionato sarebbe stato un evento di qualità visibile, non un piccolo disallineamento assorbito dalle tolleranze. Il team aveva bisogno di un approccio di ricostruzione in grado di produrre output sparsi e verificabili prima della prossima revisione del benchmark, e ne aveva bisogno abbastanza rapidamente da rendere impraticabile la ricostruzione del flusso da zero in un ambiente di scripting.
Perché energent.ai
Il team ha valutato diverse alternative. L’analisi basata su fogli di calcolo non era in grado di gestire il parsing della geometria DXF né l’orchestrazione di più artefatti su alcuna scala significativa. I software specialistici per la ricostruzione 3D richiedevano un investimento rilevante in licenze e una profonda competenza CAD per essere configurati per questo workflow one-file, evidence-first. Assumere un analista aggiuntivo non avrebbe risolto né il gap di provenienza né il problema del riempimento euristico — si trattava di problemi di progettazione della pipeline, non di risorse.
energent.ai offriva un percorso qualitativamente diverso. L’agente poteva caricare direttamente il file DXF, eseguire script Python di ricostruzione all’interno della sessione, generare e ispezionare artefatti JSON intermedi, applicare una logica di gate QC configurabile e produrre un dashboard HTML interattivo — tutto all’interno di un’unica sessione iterativa senza perdita di contesto tra i passaggi. In modo cruciale, l’agente poteva essere istruito a imporre una policy evidence-first a livello di prompt: renderizzare la geometria solo dove i dati di vista la supportano realmente, lasciare le aree non supportate sparse anziché riempite e rifiutare di ricorrere a euristiche di layer-lift per il pannello 3D finale. Nessun altro strumento alla portata del team combinava ingestione di file, elaborazione geometrica scriptata, gating QC e handoff di visualizzazione senza richiedere un ambiente di sviluppo separato e un ciclo di implementazione più lungo.
Workflow
L’analista ha caricato kavz-3244.dxf come unico file sorgente autorevole e ha avviato una sessione di ricostruzione con dimensioni target esplicite e un set di istruzioni evidence-first.
Step 1 — Segmentazione delle viste. L’agente ha analizzato il DXF e lo ha segmentato in regioni di vista — proiezioni laterali, frontali e dall’alto — producendo un artefatto di segmentazione dedicato (kavz-3244_view_segmentation_v2.json). L’analista ha esaminato le assegnazioni dei ruoli delle regioni per confermare che le etichette riflettessero il ruolo finale anziché l’ereditarietà delle finestre seed dal algoritmo di segmentazione; una versione precedente aveva usato nomi di regione derivati dalle finestre di inizializzazione invece che dalle assegnazioni di vista confermate, e l’analista se ne è accorto e ha corretto il problema prima di procedere.
Step 2 — Corrispondenza delle feature. L’agente ha estratto le corrispondenze delle feature tra le viste (kavz-3244_feature_correspondence.json), collegando gli elementi geometrici tra le viste al posizionamento della sezione di riferimento nell’evidenza multi-vista anziché nella proiezione di una singola vista. Questo passaggio è ciò che distingue la ricostruzione evidence-first dall’assegnazione euristica della profondità: una feature deve comparire in più di una vista prima di ottenere una posizione nell’inviluppo ricostruito.
Step 3 — Sezionamento. Utilizzando i dati di corrispondenza, l’agente ha generato sezioni attraverso l’inviluppo ricostruito (kavz-3244_section_slices.json). Le sezioni sono state posizionate solo dove esisteva supporto tra le viste; le zone prive di evidenze di corrispondenza sufficienti sono state lasciate vuote, producendo una ricostruzione che è onesta riguardo ai propri gap di copertura invece di essere visivamente completa ma geometricamente fabbricata.
Step 4 — QC della ricostruzione. Un artefatto QC dedicato (kavz-3244_reconstruction_qc.json) ha registrato le evidenze di superamento dei gate per ciascun controllo configurato. L’analista ha esaminato questo output per verificare che i gate fossero stati superati per i motivi corretti — non solo che il flag pass/fail fosse impostato correttamente, ma che l’evidenza sottostante fosse coerente con l’intento di ciascun gate — prima di approvare il passaggio finale di visualizzazione.
Step 5 — Geometria con tag di provenienza. Il file di ricostruzione autorevole (kavz-3244_reconstructed_geometry_v2.json) ha consolidato la geometria basata sulle sezioni con tag di provenienza che identificano la vista sorgente per ciascun elemento, creando un collegamento tracciabile tra ogni superficie renderizzata e i dati di disegno che la supportano.
Step 6 — Generazione del dashboard. L’agente ha generato il dashboard HTML finale (kavz-3244_dashboard_v3.html) sotto un’istruzione esplicita che vietava il fallback layer-lift per il pannello 3D principale. Il dashboard renderizza solo a partire dall’artefatto di ricostruzione verificato, rendendo la visualizzazione direttamente tracciabile agli output della pipeline con gate QC. Due versioni precedenti del dashboard e diversi file di debug sono stati formalmente designati come superati ed esclusi dal set finale autorevole, fornendo al team un record inequivocabile di quali output usare downstream.
Risultati
La pipeline evidence-first ha prodotto i seguenti risultati rispetto al benchmark dichiarato:
| Dimensione | Target | Raggiunto | Delta |
|---|---|---|---|
| Lunghezza | 7,895.0 mm | 7,895.0 mm | 0.0 mm |
| Larghezza | 2,210.0 mm | 2,210.0 mm | 0.0 mm |
| Altezza | 2,820.0 mm | 2,763.6 mm | −56.4 mm |
Lunghezza e larghezza hanno corrisposto esattamente al target. L’altezza è risultata inferiore di 56.4 mm, a causa di una copertura più debole delle viste dall’alto/davanti nel DXF sorgente — una limitazione nota e documentata, che è rimasta comunque entro la soglia di tolleranza configurata nel piano. Tutti i gate QC configurati sono stati superati.
Oltre all’accuratezza dimensionale, la ricostruzione ha prodotto tre risultati qualitativi che la pipeline precedente non poteva offrire:
- Provenienza completa. Ogni elemento geometrico riporta un tag della vista sorgente, rendendo le discrepanze diagnosticabili anziché opache. Il gap di 56.4 mm sull’altezza è attribuibile alla debole copertura dall’alto/davanti, non a un errore della pipeline — e l’artefatto QC registra esplicitamente tale attribuzione.
- Sparsità onesta. Le aree non supportate vengono lasciate vuote invece di essere riempite con profondità euristica, così i team di simulazione e produzione sanno esattamente quali zone richiedono ulteriori dati sorgente prima di poter prendere decisioni entro tolleranza.
- Dashboard tracciabile. La dashboard HTML viene renderizzata da un singolo artefatto sottoposto a gate QC, anziché da dati grezzi di layer, offrendo ai revisori un contratto di handoff pulito ed eliminando l’ambiguità introdotta dal precedente insieme di file intermedi non designati.
La pipeline ha inoltre prodotto cinque artefatti intermedi nominati che fungono da checkpoint per futuri run di ricostruzione, riducendo il tempo necessario per diagnosticare regressioni o risalire alla fonte di una discrepanza dimensionale.
Prova
"La vecchia pipeline ci restituiva un modello visivamente completo, ma non avevamo modo di fidarci — soprattutto attorno al tetto e alla fascia anteriore, dove la copertura dei disegni era debole. Quello che mi serviva era qualcosa che mostrasse i gap invece di nasconderli. La sessione energent.ai ha ricostruito l’intera pipeline attorno a gate basati sulle evidenze, e il JSON QC mi ha detto esattamente perché ogni gate è passato. È una classe di output diversa da quella che avevamo prima."
— Citazione composita che riflette il ruolo di analista CAD/engineering descritto in questo case study
Il deliverable finale — kavz-3244_dashboard_v3.html — presenta la ricostruzione pseudo-3D con geometria basata su sezioni, elementi taggati con provenienza e pannelli di riepilogo dimensionale. L’artefatto QC (kavz-3244_reconstruction_qc.json) fornisce le evidenze di superamento dei gate alla base della dashboard ed è disponibile per la revisione insieme ad essa.
Nota di affidabilità
La ricostruzione descritta qui è una rappresentazione pseudo-3D basata su sezioni derivata da una singola sorgente DXF 2D, non un modello CAD parametrico completo. Il deficit di 56.4 mm sull’altezza riflette una reale limitazione nella copertura delle viste dall’alto/davanti dei dati sorgente — non è un difetto del prodotto e non scompare modificando i parametri di visualizzazione. I team che utilizzano questo output per simulazione downstream, tooling di produzione o verifica di conformità dimensionale dovrebbero considerare le zone sparse come aree che richiedono ulteriori disegni sorgente o dati point-cloud prima di impegnarsi in decisioni entro tolleranza. I gate QC dell’agente confermano la coerenza interna della pipeline di ricostruzione; non certificano la conformità a uno standard dimensionale esterno né sostituiscono un protocollo di misurazione fisica.