An LLM is not a solver

Why this matters

Chat products collapse four different statements into one sentence: “the period is 0.42 s.” That sentence might be a deterministic calculation, an AI suggestion, a human judgment, or a validated result. Those are not interchangeable. Mixing them is how unverified text ends up in calculation packages.

This site treats programming and AI as tools for engineering problems, not as authorities. A language model can help you write, search, and draft. It does not replace a solver, a standard, or the engineer who signs.

Four roles that marketing language flattens

Keep these roles separate in every workflow, including ones that never open a chat window.

Deterministic calculation. Same documented inputs, same algorithm, same outputs. The path is inspectable: a derivation, a locked spreadsheet, a scripted OpenSees model, a published closed-form expression. If you cannot replay it, it is not this role.

AI suggestion. Token generation conditioned on a prompt and training data. The text may look like Tcl, Python, or a clause number. Looking like engineering is not executing engineering. Sampling, context limits, and missing project data all change the output. Treat it as a draft from an unlicensed intern who has never seen your drawings.

Human review. A person with the competence and authority for the decision reads the suggestion, edits it, rejects it, or accepts it into a checked process. Review is not “the model sounded confident.” It is a named individual applying judgment to a specific scope.

Validation evidence. Independent comparison against something that does not share the same failure mode: a hand calculation for a reduced case, a known solution from a textbook, a second analysis engine, a laboratory result, or a regression suite you already trust. A screenshot of a chat is not evidence.

If a deliverable cannot say which role it is performing, assume it is a suggestion.

What a solver actually does

A structural solver (OpenSees, a commercial finite-element program, even a short script that implements T = 2π√(m/k) for a stated SDOF oscillator) operates on a model you defined. It applies a numerical method to that model. Equilibrium, compatibility, and constitutive assumptions live in the model and the method, not in English prose.

That does not make the solver “true.” It makes the calculation replayable. You can change one spring stiffness, rerun, and see the period move. You can print the tangent, the residuals, the eigenvalue. You can archive the input deck.

Replayability is the floor. Correctness still requires that the model match the intended mechanics, that units be consistent, and that someone compare the result to an independent check.

What a language model actually does

A language model predicts likely continuations of text. It does not know your member sizes unless you pasted them. It does not enforce equilibrium. It does not open ASCE 7, Eurocode 8, or NSR-10 as a controlled database unless you built that retrieval layer — and even then the generated sentence is not the legal text.

It can emit a plausible OpenSees snippet with the wrong geometric transformation. It can quote a clause that does not exist. It can mix editions. Those failures are normal for the technology. They are unacceptable as unreviewed design basis.

A worked distinction, not a design

Suppose the engineering question is the undamped period of a single-degree-of-freedom oscillator with stated mass m and stiffness k.

• Deterministic calculation: compute T = 2π√(m/k) in a checked environment, with units written down. Archive m, k, and T.
• AI suggestion: a chat replies “about 0.4 seconds.” That number has no standing until the calculation above exists.
• Human review: an engineer confirms that the SDOF idealization is even the right question (it often is not, for a building).
• Validation evidence: for this toy case, the closed-form expression is the reference. For a multi-story elastic model, evidence looks like comparison to a second model, a textbook example with published frequencies, or a solver regression — not agreement with a chatbot.

This example is pedagogical. It is not a building period, a code-based approximate period, or a substitute for modal analysis of a real system.

A workflow that keeps the roles honest

1. State the engineering question and the acceptance check before any prompt (what would make you distrust the answer?).
2. Use a model, if at all, to draft input, comments, or a checklist.
3. A human edits geometry, constraints, materials, and analysis options until they own the model.
4. A solver runs. Warnings, non-convergence, and unexpected mechanisms are first-class results.
5. An independent check is recorded. If you cannot name it, you do not have validation evidence.
6. Only then does a responsible engineer accept the result into a deliverable.

Skip a step and you are back to suggestion.

Common mistakes

• Asking a chat for “the required reinforcement” or “the story shear” and pasting the sentence into a report.
• Treating generated quotations from design standards as the standard.
• Trusting a generated OpenSees or Python file because it runs. Execution is not verification.
• Using the same model both to produce the number and to “confirm” it.
• Calling a confidence score, a longer answer, or a chain-of-thought trace “validation.”

Limitations

This article does not rank commercial assistants, does not specify a jurisdiction, and does not define a firm’s QA procedure. Closed-form SDOF remarks are not modal analysis of buildings. References to solvers name a class of tools; they do not endorse a particular version or input file.

AI systems change. A workflow that was unsafe last year is not automatically safe because a vendor added “citations.” Citations still have to be opened, edition-checked, and applied by a person who is allowed to apply them.

Professional context

Licensed practice, responsible charge, and stamped calculations are legal and professional constructs. They do not transfer to a model provider. If your jurisdiction requires documented checks, an LLM transcript does not meet that bar. If you are a student, the same discipline still applies: the point of the exercise is that you can defend the number.

Related material on this site may walk through a first elastic OpenSees model or through dynamics theory. Those entries are still not substitutes for project-specific analysis. Use them to practice the four roles, not to skip them.

References

• OpenSees documentation — opensees.github.io/OpenSeesDocumentation. Official solver documentation, not an AI authority.
• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0) — nist.gov/itl/ai-risk-management-framework. Useful for talking about measurement and residual risk; it is not a structural design standard.
• Chopra, A. K. Dynamics of Structures. Use a printed or licensed edition for theory. This article does not reproduce it.

Evaluation and limitations

Treat the notes below as evaluation context, not as a verified calculation or code check.

Evaluate any AI-assisted workflow by naming which of the four roles each artifact occupies. If you cannot point to a deterministic calculation, a named reviewer, and recorded validation evidence, the output is still a suggestion. This article does not validate a vendor tool, a prompt, or a model version.