A design engineer asks the tool for the quantified requirements in a brief. Thirty seconds later, a clean six-line table comes back. Two lines are wrong: one floor area carried across incorrectly, and an acoustic requirement that is not in the brief at all, added because it is common in documents of that kind. Engineering prompts in construction are not there to get a good-looking answer. They are there to get an answer you can check. This article sums up what chapters 1 to 4 of the book say about that. The example, a 400 m² office floor, is fictional.
The workshop · a worked case
A clean table can hold two errors.
| Output to check | What the scenario document says | Treatment |
|---|---|---|
| Archive room: 12 m² · p. 2 | Archive room: 15 m² · p. 3 | CORRECT VALUE + SOURCE |
| Acoustic requirement stated | No such requirement found in the brief provided | REMOVE · QUERY TO THE CLIENT |
| Another requirement extracted | Check the value, the unit and where it sits in the document | CHECKING TO CONTINUE |
A requirement missing from the output does not prove it is missing from the brief. Read the document the other way round as well, to check the coverage.
Fictional teaching example · Adapt it to the data and the scope of your own commission.
01 · A confident answer can still be wrong
Chapter 2 explains the mechanism: a model generates an answer from its context. Depending on how it is set up, it may also search files or the web; that search does not guarantee the answer is accurate. An invented reference looks exactly like a real one: plausible numbering, precise vocabulary, assertive tone, credible value. Three consequences for writing a prompt:
- a decision that was never provided cannot be treated as established project data;
- without access to a current, verified source, an amended text may be cited in its superseded version;
- a calculation done directly can be wrong: have the operations run in a tool you can check, then verify the assumptions, the units and the results.
A good prompt therefore narrows the space in which the tool can invent, and forces every piece of information to carry its source.
02 · Set the rules before the first request
- The account decides. A professional account approved by your organisation, with a contract that rules out training on your data or lets you opt out: you upload the documents as they are. A “no” on either of those two points: no project document goes into that account, anonymised or not. A sensitive project (defence, healthcare, a demanding client): management decides before the first conversation. Anonymising matters mainly for copies that leave their job.
- The check follows what the output does. A rewording is read for sense, a figure is recalculated, a reference is reopened (does it exist, does it say that, is it current), a document that goes out is read in full.
- You remain responsible for what you sign. Record the real chain: prepared by the tool, checked by this person, approved by that one.
03 · Give your request a structure
The book works at two levels.
The project instructions (chapter 4)
Five lines saved once for the job: who the assistant is, for which practice, which commission under the contract, which role you hold (architect, structural engineer, cost consultant, project manager). Then the working rules: use only the project documents, cite the document and the page for every piece of information, write “not found in the documents provided” rather than filling the gap, and finish with the assumptions and the open questions. Test them with a question whose answer you know, then with a question the documents do not answer.
The request itself
- The documents named, with their revision: “Here is the brief (revision B)”.
- A precise, bounded task.
- An output format in columns: value / unit / page, or question / source / evidence expected.
- One source per line: the document and the page.
- Imposed statuses for anything not established: “not found”, “to confirm”, “to be filled in”, “to be decided”.
- An explicit guard on what the tool must not do: do not conclude on compliance, do not choose the right value, leave the rates empty.
04 · Avoid requests you cannot check
- Asking about a job in a conversation outside its project: the answer comes back general and unsourced.
- Leaving two revisions of the same document in the project: the tool may cite the older one without saying so.
- Handling several subjects in one conversation, or letting it run on indefinitely: a long conversation forgets how it began.
- Asking it to “find the errors” without saying what is being checked, and against what (see the design review with AI).
- Accepting a result that does not give its page.
- Taking “I did not find it” for “it is not there”: first check that no document is missing, re-run with different terms, and check the document is not a scan.
- Judging the tool on a published standard: it may already have known it.
05 · Try the prompt on your own brief
This is the request in the full example in chapter 4. Open a dedicated conversation in the job’s project, on an approved account, and paste:
Here is the client’s brief (revision B). List the quantified requirements it contains: for each one, the value, the unit and the page. If a piece of information is not in the document, write "not found" instead of supplying it. Present the result as a table.
What you have to check: a few lines at random and every line that commits you, by opening the brief at the page cited. If you find errors, widen the check to every line. Then check the coverage by working back through the document, page by page, to spot a quantified value missing from the table.
In the book’s example, two errors appear in four lines checked: the archive room is 15 m² on page 3, not 12 m² on page 2; the acoustic requirement does not exist in the brief. The corrected table is saved with the brief’s revision and filed in the project. If the acoustic requirement strikes you as necessary, that is a query to the client, not a line to keep.
06 · Find applications by discipline
The book offers 67 plates to reproduce. Each gives the input, an example of the result, the prompt to copy and the professional’s check. A few examples:
- Structures. Plate 18 (chapter 9): a script calculates a simply supported beam, plots the moment, shows units and assumptions and checks equilibrium, without concluding on design adequacy. Plate 34 (appendix): comparing three floor systems on the same grid. See also structural design calculations with AI.
- Building services. Plate 40 (appendix): from the occupancy brief to the fresh air flow rate schedule. Every rate cites its text and its clause, otherwise “to confirm”. No equipment is selected.
- Infrastructure. Plate 17 (appendix): from a manhole schedule to a longitudinal section, with gradients and cover depths, with no hydraulic sizing. Plate 53 (appendix): detecting an adverse gradient and treating it as a scenario.
- Cost. Plate 19 (chapter 11): from a BIM export to a cleaned take-off, with duplicates flagged rather than silently deleted. Plate 45 (appendix): a priced breakdown tied to the location drawing, rates left empty. See take-off and estimating with AI.
In every case, the tool prepares. The engineer checks, decides and signs.
Author of “AI for Architecture and Engineering”.
One approach: document the inputs, produce, check, decide.