Analysis Reports & Technical Communication

A Report Is an Engineering Argument, Not a Results Dump

A technical analysis report is not a collection of stress contours, displacement plots and solver screenshots. It is an engineering argument: a structured presentation of the engineering reasoning that connects a clearly stated question, through a defined configuration, a defined set of loads and assumptions, a verified model and a set of interpreted results, to a defensible technical conclusion. The distinction matters because a results dump — however colourful, however many plots it contains — does not communicate the reasoning. A reader of a results dump can see what the solver produced but cannot determine whether the model was appropriate, whether the assumptions were reasonable, whether the results were verified or whether the conclusion is supported. A reader of a well-structured report can follow the engineering argument from the question to the conclusion and can identify the points where the argument could be challenged. The purpose of the report is to communicate that argument, not to document every operation that was performed in the pre-processor and the post-processor. The most useful plots are those that support a specific point in the argument — the plot that shows the critical stress location, the plot that demonstrates mesh convergence, the plot that compares load cases — not every contour plot the solver can generate.

THE REPORT SHOULD COMMUNICATE THE ENGINEERING ARGUMENT, NOT DOCUMENT EVERY MOUSE CLICK. A report that presents stress contours without stating the assumptions, the method, the verification and the limitations is a results dump, not a technical argument. The purpose is to connect the model to the decision through defensible reasoning.

Recommended Report Structure

A well-structured analysis report follows a logical sequence that mirrors the engineering process: what was analysed, why, what was assumed, how it was modelled, how the model was verified, what the results are, what they mean and what remains uncertain. The following seventeen-section structure is a recommended framework, not a rigid template. The specific organisation, customer or certification basis may impose a different structure, and where it does, that structure takes precedence. Some sections may be combined for shorter reports; some may be expanded into multiple subsections for complex analyses. The key principle is that every element of the engineering argument should be present and traceable in the report.

1. 1. PURPOSE — The engineering question being answered. Why the analysis was performed. What decision it supports.
2. 2. SCOPE — What is included in the analysis and what is explicitly excluded. The boundary of the work.
3. 3. CONFIGURATION — The design configuration analysed, including revision identification. What was modelled, as distinct from the current or intended configuration.
4. 4. REQUIREMENTS — The acceptance criteria against which the results are assessed. The allowable values, the margin definitions and the certification or design requirements.
5. 5. INPUTS — The input data: geometry, material properties, masses, boundary conditions. With source references and revision identification.
6. 6. LOADS — The applied loads and load cases. Magnitudes, directions, distributions, combinations. With source references.
7. 7. MATERIALS — The material models and material data used. Response properties and allowables, with sources. Identification of which is which.
8. 8. ASSUMPTIONS — The engineering assumptions made in the analysis. Modelling assumptions, simplifications, idealisations. With justification.
9. 9. ANALYSIS METHOD — The analysis type: static, dynamic, linear, non-linear, contact, buckling. The solver, the element types, the solution controls. Why this method is appropriate.
10. 10. MODEL — The model description: geometry idealisation, mesh description, element types, boundary conditions, contact definitions, connections. Sufficient for a reader to understand what was built.
11. 11. VERIFICATION — The checks performed to confirm the model is correct: equilibrium checks, reaction force checks, mesh convergence, hand-calculation comparison, model-to-test correlation if available. The evidence that the model is fit for purpose.
12. 12. RESULTS — The key results presented in the context of the engineering argument. The critical plots, the critical quantities, the margins. Not every plot — the plots that matter.
13. 13. INTERPRETATION — What the results mean for the engineering decision. Which locations are critical, which load cases govern, what the margins indicate.
14. 14. SENSITIVITY / UNCERTAINTY — The sensitivity of the results to key parameters and assumptions. The identified uncertainties and their potential effect on the conclusion.
15. 15. LIMITATIONS — What the model does not represent. The known simplifications, the excluded physics, the boundary of applicability. What the reader should not infer from the results.
16. 16. CONCLUSIONS — The technical conclusions, stated clearly and proportionately. What the evidence supports, subject to the assumptions and limitations.
17. 17. REFERENCES — The source documents for loads, geometry, materials, methods and requirements. Enabling traceability from the report back to the evidence base.

Executive Summary vs Technical Detail

A technical report serves two audiences with different needs. The executive reader — the project manager, the chief engineer, the customer representative — needs to know the answer: does the structure meet the requirement, what is the margin, what is the risk, what action is needed. This reader needs a concise statement of the conclusion, the key result that controls it and the critical limitation that conditions it. The technical reader — the independent checker, the stress engineer who will build on the work, the certification reviewer — needs the full reasoning: the assumptions, the method, the model, the verification, the results and the interpretation. This reader needs to follow the argument and to challenge it. A well-structured report serves both: an executive summary at the front that states the conclusion and its conditions in a few paragraphs, followed by the technical sections that provide the full evidence. The executive summary should not be a restatement of the contents; it should be a statement of the engineering conclusion. The technical sections should not be a data dump; they should be the structured argument that supports the conclusion.

Conclusion Language

The language of the conclusion matters. A conclusion should state what the evidence supports, subject to the stated assumptions and limitations, without over-reaching. "FEA looks good" is not a conclusion — it communicates no engineering content. "Under the assessed load cases, the analysed configuration satisfies the defined static-strength criterion, subject to the assumptions and limitations stated in Sections 8 and 15" is a conclusion — it states what was assessed, what was found, against what criterion and subject to what conditions. The conclusion should be specific about what was analysed (the configuration, the load cases), what was assessed (the criterion), what was found (the margin, the critical location) and what conditions apply (the assumptions, the limitations). It should not imply broader applicability than the analysis supports. It should not claim certainty that the analysis does not provide. And it should not omit the limitations that condition the conclusion — a conclusion without its conditions is an overstatement. The specific acceptance statements depend on the organisation, the customer and the certification basis; the examples here are illustrative of the appropriate level of precision and qualification, not prescribed wording.

Analysis Report Quality Check

Before a report is issued, the author should confirm that a competent engineer — one who was not involved in the analysis — can answer the following questions from the report alone. If any of these questions cannot be answered from the report, the report is incomplete as an engineering argument. These questions are not about format; they are about the engineering reasoning that the report must communicate.

• What was analysed? — The configuration, the component, the assembly. Not vague; specific and revision-identified.
• Why was it analysed? — The engineering question, the decision being supported. Not "to check stress"; the actual purpose.
• Which configuration? — The design revision, the drawing number, the build standard. Not "the bracket"; the specific configuration.
• Which requirements? — The acceptance criteria, the allowable values, the margin definitions. Not "it needs to be strong enough"; the specific requirements.
• Which loads? — The load cases, the magnitudes, the sources. Not "flight loads"; the specific cases and values.
• Which material data? — The material models, the allowables, the sources. Not "aluminium"; the specific alloy, temper, product form, basis and source.
• Which assumptions? — The modelling assumptions, the simplifications, the idealisations. Stated, not hidden.
• Which analysis method? — The analysis type, the solver, the element formulation, the solution controls. Not "FEA"; the specific method.
• How was the model checked? — The verification: equilibrium, reactions, convergence, hand-calc comparison. Not "it ran without errors"; the engineering verification.
• What were the key results? — The critical quantities, the critical locations, the governing load cases. Not "stresses are shown in Figure 47"; the key results stated.
• What controls the conclusion? — The result that drives the decision. The critical margin, the limiting location, the governing case. Stated explicitly.
• What uncertainty remains? — The sensitivity, the unknowns, the parameters that could change the conclusion. Not hidden; stated.
• What is excluded? — The scope boundary, the physics not represented, the configurations not assessed. Explicit, not implied.
• What decision is supported? — The technical conclusion. Clear, qualified, proportionate. Not vague; defensible.

IF A COMPETENT ENGINEER CANNOT ANSWER THESE QUESTIONS FROM THE REPORT ALONE, THE REPORT IS INCOMPLETE AS AN ENGINEERING ARGUMENT. The report must communicate what was analysed, why, with what assumptions, by what method, with what verification, with what results, and what conclusion is supported — subject to what limitations. A report that omits any of these is not a technical argument; it is a partial record.

The Report Hierarchy — Where the Important Plot Belongs

The structure of a report is a hierarchy of evidence, not a linear dump of output. The executive engineering conclusion sits at the top, supported by the configuration and loads, which are supported by the model description, which is supported by the verification, which is supported by the results, which are supported by the margins, all conditioned by the limitations. The most important plot — the one that shows the critical result that controls the conclusion — should appear where it supports the engineering argument, not in a giant results appendix where it is lost among dozens of other contours. A report that buries the critical plot among fifty other stress contours is communicating that all plots are equally important, which is never true. The critical plot should be in the results section, referenced from the interpretation, and discussed in the context of the conclusion. The supporting plots — the ones that confirm convergence, show load-case comparison or illustrate secondary behaviour — should be in the technical sections where they support specific points. The remaining plots — the ones that are not central to the argument — should be in an appendix or omitted. The report should present the evidence that supports the argument, not every piece of output the solver can generate.

ANALYSIS REPORT HIERARCHY — EVIDENCE STRUCTURE

  ┌──────────────────────────────────────────────┐
  │  EXECUTIVE ENGINEERING CONCLUSION             │  ← What the reader needs first
  │  "Under the assessed load cases, the analysed  │
  │   configuration satisfies the defined static-  │
  │   strength criterion, subject to the stated    │
  │   assumptions and limitations."               │
  └──────────────────────┬───────────────────────┘
                         │ supported by
                         ▼
  ┌──────────────────────────────────────────────┐
  │  CONFIGURATION & LOADS                        │  ← What was assessed
  │  Specific revision, specific load cases,      │
  │  specific requirements.                       │
  └──────────────────────┬───────────────────────┘
                         │ supported by
                         ▼
  ┌──────────────────────────────────────────────┐
  │  MODEL DESCRIPTION                            │  ← How it was represented
  │  Idealisation, mesh, elements, BCs, contact.  │
  └──────────────────────┬───────────────────────┘
                         │ supported by
                         ▼
  ┌──────────────────────────────────────────────┐
  │  VERIFICATION                                 │  ← Evidence the model is fit
  │  Equilibrium, reactions, convergence,         │
  │  hand-calc comparison.                        │
  └──────────────────────┬───────────────────────┘
                         │ supported by
                         ▼
  ┌──────────────────────────────────────────────┐
  │  RESULTS                                      │  ← What the model predicted
  │  ★ The critical plot belongs HERE ★           │
  │  The plot that shows the governing result,    │
  │  in the context of the argument.              │
  └──────────────────────┬───────────────────────┘
                         │ leads to
                         ▼
  ┌──────────────────────────────────────────────┐
  │  MARGINS & INTERPRETATION                     │  ← What it means for the decision
  │  Allowable comparison, critical location,     │
  │  governing case, stated margins.              │
  └──────────────────────┬───────────────────────┘
                         │ conditioned by
                         ▼
  ┌──────────────────────────────────────────────┐
  │  LIMITATIONS                                  │  ← What the reader must NOT infer
  │  What is not represented. What is excluded.   │
  │  The boundary of applicability.               │
  └──────────────────────────────────────────────┘

  The critical plot appears where it supports the
  argument — not in a 50-plot results dump.

Report Sections and Their Purpose

The following table summarises each report section, what it contains, why it matters and what a reader needs from it. The table is a guide to the content and purpose of each section, not a mandatory template. The specific structure may vary; the engineering argument must not.

The Most Common Reporting Failure

The most common failure of analysis reports is the presentation of a collection of stress contours without a clear engineering argument. This failure is easy to produce — the solver generates dozens of plots, and inserting them into a document is straightforward. But a document full of stress contours, without stated assumptions, without identified limitations, without verification evidence and without a clear conclusion, is not a technical report. It is a results dump. A reader of a results dump cannot determine whether the model was appropriate, whether the results were verified, whether the assumptions were reasonable or whether the conclusion is supported. The reader can see what the solver produced but cannot assess whether it is correct, meaningful or applicable. The report must communicate the engineering reasoning that connects the model to the decision — the assumptions that bound the applicability, the verification that confirms the model is fit for purpose, the interpretation that converts results into engineering meaning and the limitations that condition the conclusion. Without that reasoning, the plots are just coloured pictures.

PRESENTING A COLLECTION OF STRESS CONTOURS WITHOUT A CLEAR ENGINEERING ARGUMENT, STATED ASSUMPTIONS OR IDENTIFIED LIMITATIONS IS A RESULTS DUMP, NOT A TECHNICAL REPORT. The report must communicate the engineering reasoning that connects the model to the decision — the assumptions, the method, the verification, the interpretation and the limitations. Without that reasoning, the results cannot be assessed.

Key Takeaways

• A technical report is an engineering argument, not a results dump
• The seventeen-section structure — purpose through references — provides a framework for the complete argument
• The executive summary states the conclusion; the technical sections provide the evidence
• Conclusion language should be specific, qualified and proportionate — "FEA looks good" is not a conclusion
• The critical plot belongs where it supports the argument, not in a fifty-plot results dump
• Before issuing, confirm that a competent engineer can answer the fourteen quality-check questions from the report alone
• The report structure may vary by organisation, customer or certification basis; the engineering argument must not