Graham Church, developer of SafetyStack, an online document toolkit for UK trades, explains why electrical contractors should check the wider impact of AI-generated document edits
An AI document assistant can make a paragraph easier to read while quietly changing something you wanted to keep. For electrical contractors evaluating software, a simple, controlled editing exercise can reveal more than an impressive demonstration. Ask for one change, then check the whole result.
Use a clearly fictional job and invented names. Do not enter a real customer’s information into a trial before understanding the product’s data arrangements. The exercise below tests document editing and review; it is not an electrical procedure, risk assessment or approval of work.
Imagine a draft carrying these administrative details: job reference TEST-041, site Eastgate Workshop and document version 1. The particular names do not matter. What matters is that you have a short list of information that should remain unchanged while you test the assistant.
Save a copy of the starting document using the product’s normal controls. Check that you can reopen it. A version label alone is not evidence that the earlier wording can be recovered; try the recovery route before making your test change.
Now choose one ordinary administrative sentence, such as: “Please use the job reference when discussing this document.” Ask the assistant to rewrite it more concisely, while preserving the reference, site label and version elsewhere. Keep the instruction narrow enough that you can judge whether the result followed it.
Compare the requested sentence before and after. A shorter version might read: “Quote the job reference in document queries.” That is a fictional wording example, not a required phrasing or evidence of what any particular product will generate.
Then look beyond that sentence. Search for the job reference and site label, and inspect the document title, headings and other identifying fields. Check whether information moved, disappeared or acquired an unexpected replacement. A fluent paragraph does not tell you whether the rest of the document remained intact.
Include a second identifying field in your notes, such as the fictional customer’s label. This helps you spot a change that leaves the main job reference apparently untouched.
If the software offers a change summary or comparison view, test it against what you can see in the document. Does it identify every alteration, or only the assistant’s intended change? If no comparison is available, decide whether reviewing the full result manually is workable for your business.
Test rejection as well as acceptance. Can you decline the proposed wording without losing other edits? After accepting it, can you recover the earlier version through the documented route? Record what actually happened rather than assume that an undo icon covers every kind of change.
Export the edited document and reopen the file outside the app. Check that the accepted wording appears, the identifying details remain clear and long answers are readable. The version sent to another person matters just as much as the version displayed inside the editor.
Repeat the exercise with a second narrow request. This time, deliberately reject the suggestion. Keep notes on the instruction, visible changes, recovery steps and exported result. Those observations can help you compare tools; they do not establish long-term reliability or measured time savings.
The boundary remains important. A starting template needs competent adaptation and review for the actual work and site. Neither readable prose nor a successful editing exercise demonstrates that risks have been adequately assessed, or that a customer will accept the document.
Graham Church is the developer of SafetyStack