Perfil do cliente
O analista atua em uma pequena equipe de engenharia automotiva ou de fornecedor OEM responsável por extrair inteligência dimensional de desenhos CAD 2D legados. Seus materiais de origem são arquivos DXF — o formato padrão do setor exportado de ferramentas como AutoCAD, CATIA e SolidWorks — e seus consumidores downstream incluem equipes de simulação, planejadores de manufatura e revisores de conformidade dimensional. A equipe opera na interseção entre engenharia reversa e preparação de digital twin, onde a precisão da geometria reconstruída afeta diretamente ferramentas e decisões de processo downstream. A maioria dos desenhos de entrada da equipe são layouts de um único arquivo com múltiplas vistas: projeções lateral, frontal e superior codificadas em um único DXF, sem um modelo CAD 3D complementar disponível.
Problema
Antes de adotar o energent.ai, a equipe dependia de uma abordagem de inferência de profundidade baseada em camadas para transformar a geometria DXF 2D em uma representação pseudo-3D. O problema central era o preenchimento sistemático excessivo: sempre que o desenho de origem não tinha cobertura suficiente de múltiplas vistas, o algoritmo atribuía valores heurísticos de profundidade em vez de sinalizar essas zonas como não suportadas. A geometria fabricada tornava os resultados da reconstrução pouco confiáveis para pipelines downstream, e a ausência de dados de proveniência tornava impossível diagnosticar qual região do desenho era responsável por qualquer discrepância dimensional.
Para o veículo em análise — descrito por um único arquivo de desenho autoritativo (kavz-3244.dxf) — o envelope de referência estava precisamente especificado:
- Comprimento: 7,895.0 mm
- Altura: 2,820.0 mm
- Largura: 2,210.0 mm
As saídas do dashboard geradas pelo pipeline antigo não podiam ser validadas contra esses alvos de forma significativa. Um render 3D visualmente completo era produzido, mas a equipe não tinha uma cadeia de artefatos conectando cada elemento de superfície renderizado de volta a uma vista ou região específica do desenho. Qualquer discrepância entre o modelo renderizado e a especificação-alvo era indistinguível entre uma lacuna dimensional real e um artefato do preenchimento heurístico. O pipeline anterior também havia gerado vários arquivos intermediários de depuração e visualização que nunca foram formalmente designados como autoritativos ou substituídos, deixando a equipe incerta sobre quais saídas deveriam ser usadas para decisões downstream.
Por que agora
A pressão para entregar uma reconstrução confiável veio de duas forças convergentes. Primeiro, as equipes downstream de simulação e manufatura começaram a apontar discrepâncias dimensionais em modelos entregues pelo fluxo de trabalho de reconstrução — e, sem dados de proveniência, a equipe de reconstrução não conseguia explicar qual vista do desenho fornecia cada medida nem se uma lacuna era intencional ou heurística. Segundo, a equipe acabara de receber um desenho de veículo com dimensões-alvo totalmente especificadas, criando um benchmark concreto contra o qual a precisão do pipeline antigo poderia ser medida de forma direta e pública. Uma entrega malsucedida em um benchmark dimensionado seria um evento de qualidade visível, não um desvio silencioso absorvido por tolerâncias. A equipe precisava de uma abordagem de reconstrução que pudesse produzir saídas auditáveis e esparsas antes da próxima revisão do benchmark, e precisava disso com rapidez suficiente para que reconstruir o pipeline do zero em um ambiente de scripting não fosse viável.
Por que energent.ai
A equipe avaliou várias alternativas. A análise baseada em planilhas não conseguia lidar com parsing de geometria DXF nem com orquestração de múltiplos artefatos em qualquer escala. Softwares especializados de reconstrução 3D exigiam investimento significativo em licenciamento e profunda expertise em CAD para serem configurados para esse fluxo de trabalho de um único arquivo e orientado por evidências. Contratar um analista adicional teria resolvido nem a lacuna de proveniência nem o problema de preenchimento heurístico — esses eram problemas de design de pipeline, não de recursos.
O energent.ai oferecia um caminho qualitativamente diferente. O agente podia carregar o arquivo DXF diretamente, executar scripts Python de reconstrução dentro da sessão, gerar e inspecionar artefatos JSON intermediários, aplicar lógica configurável de gates de QC e produzir um dashboard HTML interativo — tudo em uma única sessão iterativa, sem perda de contexto entre as etapas. Criticamente, o agente podia ser instruído a impor uma política de evidência em primeiro lugar no nível do prompt: renderizar geometria apenas onde os dados de vista realmente a suportassem, deixar regiões sem suporte esparsas em vez de preenchidas e recusar-se a recorrer a heurísticas de layer-lift para o painel 3D final. Nenhuma outra ferramenta ao alcance da equipe combinava ingestão de arquivos, processamento geométrico por script, gating de QC e handoff de visualização sem exigir um ambiente de desenvolvimento separado e um ciclo de implementação mais longo.
Fluxo de trabalho
O analista carregou kavz-3244.dxf como o único arquivo-fonte autoritativo e iniciou uma sessão de reconstrução com dimensões-alvo explícitas e um conjunto de instruções de evidência em primeiro lugar.
Etapa 1 — Segmentação de vistas. O agente analisou o DXF e o segmentou em regiões de vista — projeções lateral, frontal e superior — produzindo um artefato de segmentação dedicado (kavz-3244_view_segmentation_v2.json). O analista revisou as atribuições de papel das regiões para confirmar que os rótulos refletiam o papel final e não a ancestralidade da janela-semente do algoritmo de segmentação; uma versão anterior havia usado nomes de região derivados de janelas de inicialização em vez de atribuições de vista confirmadas, e o analista identificou e corrigiu isso antes de prosseguir.
Etapa 2 — Correspondência de features. O agente extraiu correspondências de features entre vistas (kavz-3244_feature_correspondence.json), vinculando elementos geométricos entre vistas para fundamentar o posicionamento de seções em evidências de múltiplas vistas, em vez de projeção de uma única vista. Esta etapa é o que distingue a reconstrução orientada por evidências da atribuição heurística de profundidade: uma feature precisa aparecer em mais de uma vista antes de merecer uma posição no envelope reconstruído.
Etapa 3 — Corte de seções. Usando os dados de correspondência, o agente gerou cortes de seção através do envelope reconstruído (kavz-3244_section_slices.json). As seções foram posicionadas apenas onde havia suporte entre vistas; zonas sem evidência suficiente de correspondência foram deixadas em branco, produzindo uma reconstrução honesta sobre suas lacunas de cobertura, em vez de visualmente completa, porém geometricamente fabricada.
Etapa 4 — QC da reconstrução. Um artefato de QC dedicado (kavz-3244_reconstruction_qc.json) registrou evidências de aprovação de gate para cada verificação configurada. O analista inspecionou essa saída para verificar se os gates haviam sido aprovados pelos motivos corretos — não apenas se a sinalização de aprovado/reprovado estava correta, mas se a evidência subjacente era consistente com a intenção de cada gate — antes de aprovar a etapa final de visualização.
Etapa 5 — Geometria com tag de proveniência. O arquivo autoritativo de reconstrução (kavz-3244_reconstructed_geometry_v2.json) consolidou a geometria baseada em seções com tags de proveniência identificando a vista de origem de cada elemento, criando um vínculo rastreável entre cada superfície renderizada e os dados de desenho que a sustentavam.
Etapa 6 — Geração do dashboard. O agente gerou o dashboard HTML final (kavz-3244_dashboard_v3.html) sob uma instrução explícita que proibia o fallback de layer-lift para o painel 3D principal. O dashboard renderiza apenas a partir do artefato de reconstrução validado, tornando a visualização diretamente rastreável às saídas do pipeline com QC. Duas versões anteriores do dashboard e vários arquivos de depuração foram formalmente designados como substituídos e excluídos do conjunto final de autoridade, dando à equipe um registro inequívoco de quais saídas usar downstream.
Resultados
O pipeline evidence-first produziu os seguintes resultados em relação ao benchmark definido:
| Dimension | Target | Achieved | Delta |
|---|---|---|---|
| Length | 7,895.0 mm | 7,895.0 mm | 0.0 mm |
| Width | 2,210.0 mm | 2,210.0 mm | 0.0 mm |
| Height | 2,820.0 mm | 2,763.6 mm | −56.4 mm |
Length e width corresponderam exatamente ao target. Height ficou 56.4 mm abaixo, devido à cobertura mais fraca das vistas superior/frontal no DXF de origem — uma limitação conhecida e documentada, e que permaneceu dentro do limite de tolerância configurado no plano. Todas as QC gates configuradas foram aprovadas.
Além da precisão dimensional, a reconstrução entregou três resultados qualitativos que o pipeline anterior não conseguia oferecer:
- Proveniência completa. Cada elemento geométrico carrega uma tag de source-view, tornando as discrepâncias diagnosticáveis em vez de opacas. A diferença de 56.4 mm na height é atribuível à cobertura fraca de top/front, e não a um erro do pipeline — e o artefato de QC registra essa atribuição explicitamente.
- Escassez honesta. Regiões sem suporte são deixadas em branco em vez de preenchidas com profundidade heurística, de modo que as equipes de simulação e manufatura downstream saibam exatamente quais zonas exigem dados de origem adicionais antes que decisões com tolerância possam ser assumidas.
- Dashboard rastreável. O dashboard HTML é renderizado a partir de um único artefato com QC gate, e não de dados brutos de layer, oferecendo aos revisores um contrato de handoff limpo e eliminando a ambiguidade introduzida pelo conjunto anterior de arquivos intermediários sem designação.
O pipeline também produziu cinco artefatos intermediários nomeados que servem como checkpoints para futuras execuções de reconstrução, reduzindo o tempo necessário para diagnosticar regressões ou rastrear uma discrepância dimensional até sua origem.
Prova
"O pipeline antigo nos entregava um modelo visualmente completo, mas não havia como confiar nele — especialmente no roof e no front fascia, onde tínhamos cobertura fraca dos desenhos. O que eu precisava era de algo que mostrasse as lacunas em vez de escondê-las. A sessão com energent.ai reconstruiu todo o pipeline em torno de evidence gates, e o QC JSON me disse exatamente por que cada gate foi aprovado. Isso é uma classe de saída diferente do que tínhamos antes."
— Citação composta refletindo a função de CAD/engineering analyst descrita neste case study
O deliverable final — kavz-3244_dashboard_v3.html — apresenta a reconstrução pseudo-3D com geometria baseada em seções, elementos com provenance tags e painéis de resumo dimensional. O artefato de QC (kavz-3244_reconstruction_qc.json) fornece a evidência de gate-pass que sustenta o dashboard e está disponível para revisão junto com ele.
Nota de confiança
A reconstrução descrita aqui é uma representação pseudo-3D baseada em seções derivada de uma única fonte DXF 2D, e não um modelo CAD paramétrico completo. O shortfall de 56.4 mm na height reflete uma limitação real na cobertura das vistas top/front dos dados de origem — não é um defeito do produto, e não desaparece ao ajustar parâmetros de visualização. Equipes que usem essa saída para simulação downstream, ferramentas de manufatura ou revisão de conformidade dimensional devem tratar as zonas esparsas como áreas que exigem desenhos de origem adicionais ou dados de point-cloud antes de assumir decisões com tolerância. As QC gates do agente confirmam a consistência interna do pipeline de reconstrução; elas não certificam conformidade com um padrão dimensional externo nem substituem um protocolo de medição física.