Simplifying a finding is not summarising it. The obligation is to keep facts, assumptions and opinions visibly separate — and that is exactly the distinction a fluent model is most likely to erase.
Key takeaways
Write the technical finding first and completely. Then have the model produce a plain-language layer that sits on top of it, structured so that the reader can see which sentences are findings, which are assumptions and which are recommendations. Then check that the limitations survived. That order is not stylistic — it is the only order in which the simplification cannot quietly become the finding.
The risk is specific and it is not hallucination. A capable model asked to make a report readable will smooth hedges into assertions, because hedged prose reads worse. “Assuming the as-built drawings are accurate, the connection appears adequate” becomes “the connection is adequate”, and a conditional professional opinion has become an unconditional one under someone’s seal.
Engineers Canada’s guideline on the code of ethics lists, among the conduct expected of registrants, that they should “provide professional statements that distinguish between facts, assumptions, and opinions”. Its interpretation of that principle is the part worth reading before you let anything rewrite a report: registrants are consulted for their expertise and judgment, so it is very important that they clearly indicate whether they are providing an opinion, making assumptions, or stating facts, because each carries a different level of certainty and serious consequences can follow if the types are not differentiated. Facts stated in professional documents must be supported by data or credited to a reliable source; representations of facts must be precise; sensitivity analyses should be carried out where conclusions rest on assumed parameters; and registrants should state what assumptions they are making in the absence of data.
The guideline also contains the single clearest statement of the AI question in any Canadian professional code: registrants should “assume responsibility only for work that they have prepared or that has been prepared under direct supervision and control, and for which they can validate outputs used in its development”. If you cannot validate the output, you cannot take responsibility for the work that rests on it. That is the test, and it is not a new one.
The same guideline explains that when engineers sign and seal documents they indicate their acceptance of responsibility for the work and that the work can be relied upon, and that this applies without exemption wherever engineering principles have been used and public welfare may be at risk. It is equally clear that supervision cannot be symbolic: a purely nominal supervisory role runs contrary to the concept of taking professional responsibility.
One caution about authority. Engineers Canada states that its national guidelines are not regulations or rules, that they do not establish a legal standard of care or conduct, that regulators may adopt them in whole, in part or not at all, and that the ultimate authority lies with the engineering regulator in the province or territory where the engineer works. Engineering is licensed provincially — Professional Engineers Ontario, APEGA in Alberta, EGBC in British Columbia and their counterparts elsewhere — so read your own regulator’s act, regulations and bylaws alongside it.
Give the model a fixed frame rather than an instruction to "make this clearer". The frame does the work:
The last item is the one to enforce mechanically. Pass the limitations text through unchanged and check the output still contains it verbatim. A paraphrased limitation is a narrowed limitation, and narrowing it is the most expensive edit anyone can make to a report.
Four checks, done by the person who will sign. If they take longer than the drafting saved, the frame is wrong — not the idea.
A consulting engineering practice produces condition assessments for commercial property owners. The technical report is thorough and unreadable, so a two-page client summary has always been written by hand, badly, at the end of the job.
The practice moves the summary to a fixed six-heading frame drafted by a model from the report, with the limitations section passed through verbatim. On the first three jobs the reviewing engineer rejects two drafts — both for the same reason: a recommendation stated as urgent where the report had said "recommend further investigation to determine". That is the failure mode working exactly as predicted, caught by the check that was designed for it.
The measurable claim the firm can make internally is the number of client clarifying questions per report before and after. It is countable, it is the thing the summary exists to reduce, and it does not require anyone to estimate hours saved.
A report written for a client can become a document in litigation, and the standards for expert material are different again — Treadstone Law sets out how expert evidence is admitted at an Ontario civil trial. Where that is a live prospect, the separation of fact, assumption and opinion stops being good practice and starts being the thing the report is judged on.
And do not rely on the disclaimer to carry the weight. Treadstone Law’s note on whether an engagement letter disclaimer avoids liability for negligence is worth reading before assuming the boilerplate does the job.
An accountant explaining a variance, a broker explaining a coverage exclusion and a consultant explaining a model output all face the same erosion. The professional codes differ; the discipline does not. Say what you found, say what you assumed, label the opinion as an opinion, and keep the limitation intact.
Where the explanation involves personal information, the Office of the Privacy Commissioner’s principles for generative AI add a further expectation worth borrowing: information communicated about a system should be designed to be understandable by its intended audience.
Can the model write the technical report too?
Not as the source of record. The plain-language layer is derived from the technical work; if the technical work is itself derived, there is nothing left to validate the output against, which is the condition the code of ethics attaches responsibility to.
How do we stop it inventing a recommendation?
Constrain the input. Give it the findings and the recommendations as separate blocks and instruct it that recommendations may only be restated, never added. Then run the recommendation audit, because instructions are not guarantees.
Should the client summary say a tool helped write it?
Usually not on the document itself, if the engineer of record has reviewed and signed it. Whether to say so at all is a separate question with its own test.
What about translating a report into French?
Translation is a different task with a different risk: a mistranslated limitation is still a narrowed limitation. Have the translated limitations section checked by someone who reads both languages before it goes out.
A 30-minute call is enough to tell you whether AI pays for itself here.
