4. Introduction to AI for report generation

CAE reports are fundamentally a translation problem. On one side sits a solver output deck: nodal displacements, element stresses, contact forces, modal frequencies, and time-history curves. On the other side sits a document that a design engineer, a project manager, or a certification body can read and act upon. Historically, that translation has been performed manually by an analyst who interprets contour plots, selects governing load cases, and writes prose that connects numerical evidence to engineering conclusions. Large language models (LLMs) change the economics of that translation by automating the narrative layer while leaving the numerical layer under deterministic control.

This chapter explains what LLMs and transformer architectures actually are in the context of CAE reporting, how they consume simulation data, where they are reliable, and where they must be constrained. The goal is not to turn analysts into machine-learning engineers, but to give them enough architectural understanding to design a report-generation pipeline that is both useful and defensible.

From Solver Output to Structured Evidence

An LLM cannot read a binary .odb, .rst, or .h3d file directly. Before any language model is involved, the simulation results must be reduced to a structured, machine-readable evidence set. This reduction step is the single most important determinant of report quality, because the model can only reason over what it is given.

A practical evidence extraction stage typically produces a JSON document containing scalar summaries, ranked extremes, and metadata. For example, a static structural analysis of a bracket might yield:

{
  "model": "bracket_rev_C",
  "solver": "Abaqus 2024",
  "analysis_type": "static_linear",
  "load_cases": [
    {"id": "LC1", "description": "Vertical 5g inertial load"},
    {"id": "LC2", "description": "Lateral 3g inertial load"}
  ],
  "results": {
    "LC1": {
      "max_von_mises_MPa": 214.6,
      "location": "fillet radius, node 18422",
      "allowable_MPa": 276.0,
      "margin": 0.287,
      "max_displacement_mm": 1.82
    },
    "LC2": {
      "max_von_mises_MPa": 168.3,
      "location": "bolt boss, node 9031",
      "allowable_MPa": 276.0,
      "margin": 0.640,
      "max_displacement_mm": 0.94
    }
  },
  "mesh_convergence": {"status": "passed", "delta_percent": 2.1}
}

Notice that the evidence set already contains derived quantities — margins, governing locations, convergence status. The LLM's job is to narrate these facts, not to compute them. This separation of concerns is the foundation of trustworthy AI-assisted reporting.

What a Transformer Actually Does

A transformer is a neural network architecture built around a mechanism called self-attention. Given a sequence of tokens — words, numbers, or structured field names — self-attention computes, for every token, a weighted sum over all other tokens in the sequence. Those weights represent how much each token should influence the interpretation of every other token. This is what allows a transformer to connect "max von Mises stress of 214.6 MPa" in one part of the input to "allowable of 276 MPa" in another and produce the sentence "the margin of safety is 0.29."

An LLM is a transformer trained on a very large text corpus to predict the next token. Through that training it acquires grammar, technical vocabulary, and patterns of technical argumentation. When fine-tuned or prompted with CAE-specific instructions, it can produce report prose that reads like an experienced analyst wrote it — provided the underlying facts are supplied in the prompt.

The critical property to internalize is this: an LLM generates plausible text, not verified truth. If the evidence set says the margin is 0.287, the model will usually write 0.287. But if the evidence set is ambiguous or the prompt is poorly constrained, the model may interpolate, round inconsistently, or invent a plausible-sounding value. Every numerical claim in an AI-generated report must therefore be traceable to the evidence set.

Design principle: Treat the LLM as a technical writer, not as an analyst. It receives verified facts and produces narrative. It never computes, never extrapolates, and never decides pass/fail on its own.

The Report Generation Pipeline

A production-grade AI report generator is a pipeline with four distinct stages, each with its own validation gate. The diagram below shows the data flow and the control boundaries between deterministic computation and language generation.

1. Solver Output .odb / .rst / .h3d raw field data 2. Evidence Extraction Python / API scripts → structured JSON 3. LLM Narrative prompt + evidence → draft sections 4. Review traceability check Deterministic zone — reproducible, auditable Generative zone — requires validation Failed traceability → re-extract or re-prompt Evidence Set Contents • Load case IDs and descriptions • Max/min stress, displacement • Governing node/element IDs • Allowables and margins • Mesh convergence status • Units and coordinate system • Solver version and date Prompt Constraints • Role: "You are a CAE analyst" • Cite only supplied values • No unit conversion • State pass/fail per margin • Flag missing data explicitly • Output section structure • Max 200 words per section Validation Checks • Every number in draft exists in evidence set • No invented load cases • Units consistent • Pass/fail matches margin • No unsupported claims • Human sign-off required

Prompt Engineering for CAE Narratives

The prompt is where engineering judgment is encoded. A weak prompt produces generic prose; a well-constructed prompt produces text that an analyst would only need to lightly edit. Three elements matter most.

Role and scope. The system prompt should establish the model as a CAE report writer with a specific discipline — structural, thermal, modal, or fatigue. This narrows vocabulary and reduces hallucination. For example: "You are a structural analysis report writer. You produce concise, factual narrative sections from supplied JSON evidence. You never compute values. You never introduce data not present in the evidence."

Evidence injection. The full JSON evidence set is placed in the user prompt, followed by a section-by-section instruction. A typical instruction for the results section might read: "Write a Results section of no more than 180 words. For each load case, state the maximum von Mises stress, its location, the allowable, and the resulting margin. State whether the margin is positive. Do not round values differently from the evidence."

Output schema. Constraining the output format — for example, requiring a JSON object with keys summary, results, discussion, conclusion — makes downstream validation and template insertion far more reliable than free-form text.

Practical tip: Keep the evidence set and the prompt in the same repository as the report template. When a report is questioned six months later, you can reproduce the exact input that produced it.

Where LLMs Help and Where They Fail

LLMs excel at three tasks in the CAE reporting workflow. First, summarization: condensing dozens of load cases into a coherent executive summary. Second, consistency: applying the same sentence structure and terminology across every report, which is difficult for humans under deadline pressure. Third, drafting: producing a first pass that an analyst edits rather than writes from scratch, often cutting report preparation time by half or more.

They fail predictably in four areas. Numerical reasoning: an LLM may miscompare two margins or misstate a trend. Unit handling: if the evidence set mixes MPa and ksi, the model may silently conflate them. Missing data: when a load case has no result, the model may invent a plausible value rather than flag the gap. Regulatory language: certification reports require specific phrasing that must be templated, not generated.

Task LLM Suitability Required Control
Executive summary from ranked results High Evidence set must contain pre-ranked extremes
Per-load-case results narrative High Prompt must forbid unit conversion
Margin calculation None Compute in Python; pass result to LLM
Pass/fail determination Low Deterministic rule; LLM only states outcome
Certification statement wording None Fixed template; no generation
Anomaly flagging (e.g., convergence failure) Medium Rule-based detection; LLM describes flagged item

A Minimal Working Example

Consider a modal analysis of a printed circuit board assembly. The evidence set contains the first six natural frequencies, the target lower bound of 200 Hz, and a note that the mesh was refined once with a 1.8% frequency shift. A constrained prompt produces the following draft:

Section: Modal Results

The first six natural frequencies of the PCB assembly were extracted
using the Lanczos solver. The fundamental frequency is 247.3 Hz,
which exceeds the 200 Hz lower bound by 23.7%. The second and third
modes occur at 312.8 Hz and 401.5 Hz. A mesh refinement study
produced a 1.8% shift in the fundamental frequency, indicating
acceptable convergence. All modes fall above the required threshold;
no further stiffening is required.

Every number in this paragraph traces directly to the evidence set. The convergence statement is a restatement of a supplied fact, not an independent judgment. The conclusion — "no further stiffening is required" — follows from the margin, which was computed deterministically before the LLM was invoked.

Validation and Traceability

The final gate before a report is released is automated traceability checking. A simple validator extracts every numeric token from the generated draft and confirms that each appears in the evidence set. Any number that cannot be matched is flagged for human review. This catches the most common and most dangerous failure mode: a plausible but fabricated value.

Beyond numbers, the validator checks that every load case mentioned in the draft exists in the evidence, that pass/fail statements are consistent with the sign of the margin, and that no section exceeds its word limit. Reports that pass all checks are marked as "AI-assisted, validated." Reports that fail are routed to the analyst with the specific discrepancy highlighted.

Warning: Never release an AI-generated CAE report without human sign-off. The validator reduces risk but does not eliminate it. The engineer of record remains responsible for every conclusion in the document.

The next chapter builds on this foundation by examining how evidence extraction scripts are written for common solvers, and how the resulting JSON schema is standardized across analysis types so that a single prompt template can serve structural, thermal, and modal reports alike.

← Previous 📖 Contents Next →