Engineering Reverse Analysis
Give the model an assembly (drawing, photo, description, or part) and this three-part prompt:
Analyze this assembly/unit:
1. DECOMPOSITION: Break it down into its constituent components/parts.
List each component, its apparent function, and how it connects to neighbors.
2. CONSTRAINTS: For each component, identify likely materials and specs,
citing only recognized standards (GOST, ISO, ASTM, DIN). If a material/spec
cannot be tied to a standard, say so explicitly — do not guess.
3. VERIFICATION: For every claim above, mark it as:
- [VERIFIED] — directly observable from provided data
- [INFERRED] — reasonable engineering assumption, state the reasoning
- [UNCERTAIN] — guess/pattern-match, requires engineer confirmation
Do not calculate tolerances, strength, or load-bearing values. Flag these as
"requires CAE/manual calculation" instead.
Output feeds into a draft ТЗ (technical specification) — never directly into production or CAD without engineer sign-off.
Progress:
- Step 1: Define scope — single node/unit, not full system (keep decomposition tractable)
- Step 2: Decompose — list components, hierarchy, connections
- Step 3: Constrain — map each component to standards (GOST/ISO/ASTM); refuse to invent specs with no standard basis
- Step 4: Verify — tag every statement VERIFIED / INFERRED / UNCERTAIN
- Step 5: Route UNCERTAIN items back to the engineer as open questions, not as answers
- Step 6: Package into draft ТЗ format; explicitly exclude final tolerances/strength calculations
- Step 7: Engineer reviews, corrects, and performs final calculations in CAD/CAE
Never let AI output skip steps 4–7. The verification tagging is the trust mechanism — it's what lets a skeptical engineer accept the 80% that's solid and focus review time on the 20% flagged uncertain.
Example 1: Input: Photo of a bearing assembly from a competitor's gearbox. Output:
DECOMPOSITION:
- Outer race, inner race, rolling elements (balls), cage, two seals
CONSTRAINTS:
- Bearing type pattern matches deep-groove ball bearing per GOST 8338-75
- Seal material likely NBR rubber (common per GOST 9833) [INFERRED]
- Exact steel grade of races: cannot determine from photo alone [UNCERTAIN]
VERIFICATION:
- [VERIFIED] Component count and general geometry (visible in photo)
- [INFERRED] Bearing standard family, based on visual proportions
- [UNCERTAIN] Steel grade, tolerance class, load rating — requires
physical inspection or manufacturer datasheet
NOT CALCULATED: load capacity, fatigue life — engineer to verify in CAE.
Example 2: Input: "Разбери этот кронштейн и предложи материал." Output: Decomposes into mounting plate + rib + bolt holes; proposes Steel 3 (Ст3) per GOST 380-2005 as [INFERRED] based on typical bracket applications; flags "exact grade depends on expected load, which was not provided" as [UNCERTAIN]; explicitly states no strength calculation performed.
- Start with reverse-engineering known/existing assemblies, not greenfield design — lower stakes, builds trust incrementally
- Always anchor material/spec claims to a named standard; "best practice" or "commonly used" without a standard reference = reject
- Keep the three tags (VERIFIED/INFERRED/UNCERTAIN) visually distinct and mandatory on every technical claim
- Treat AI output as draft ТЗ or research acceleration only — never as final design input
- Give engineers a one-line escape hatch to override: "If this looks wrong, it probably needs your judgment, not a better prompt"
- Letting AI output tolerances, dimensions, or strength values as if final — always defer these to CAD/CAE and manual calc
- Treating INFERRED claims as VERIFIED just because the AI sounds confident
- Skipping the standards-constraint step — unconstrained material suggestions are a major source of engineer distrust
- Introducing AI with a design task first instead of analysis/decomposition — this is what triggers sabotage/resistance
- Omitting the "where might this be wrong" prompt — this self-flagging step is what makes engineers willing to adopt the tool