Write a Commissioning Observation Draft with AI at the Cursor

An electrical engineer can speak verified commissioning facts and use AI to produce a structured observation draft at the cursor of a compatible Windows text field. The draft keeps open actions visible and flags facts that were never supplied. To make it work, you supply four inputs (equipment, test record reference, observation and open action), instruct the AI to use only those inputs, and check every line against the source record before the text goes anywhere. The AI shapes wording and structure. It cannot verify test data or decide what is acceptable.

This article describes an illustrative writing practice. It gives no commissioning procedure, no energized-work guidance and no compliance advice. Your project specification, your organisation's procedures and your own professional judgment decide what counts as a pass, a fail or an open item.

Observation notes often get written in fragments: a line on a test sheet, a remark during a walkdown, a message to a contractor. A usable draft gathers those fragments into one entry that a reviewer can act on without asking what you meant. A common structure answers four questions:

• Which equipment? Use the identifier as it appears on drawings or schedules, since a nickname forces the reader to guess.
• Which record supports it? Give a test record reference so the reader can check your statement against the source.
• What was observed? State only what was seen or recorded, in plain terms.
• What remains open? Name the action, and the owner if one has been assigned.

Unresolved items are the easiest to lose when notes are tidied. A draft that reads smoothly while hiding a missing test entry is worse than rough notes that show the gap. The approach below makes gaps visible by design: you instruct the AI to flag missing facts and leave them unfilled.

SpeakLingo is built around Syping (speaking + typing), the habit of using voice and keyboard in one flow. The concept is explained at https://speaklingo.ai/syping. In this task, you might type a short reference number with the keyboard and speak the description of what you saw. Three SpeakLingo capabilities are in scope for the workflow:

1. Online transcription in 99+ languages. Your speech becomes text. Choose a supported language appropriate to you.
2. AI contextual formatting. Transcribed content can be shaped into labelled fields or short paragraphs, which reads more clearly than a block of dictated speech.
3. Spoken AI text requests at the cursor. You speak an instruction, and the result is delivered at a compatible, focused Windows text field. Where this cursor workflow fits your tools, it can reduce the need to copy text between a separate AI window and your document.

For the wider product overview, see the features and use cases pages.

Some boundaries matter in an engineering context:

• SpeakLingo is not compatible with every application or field. Test it in the tools you actually use before relying on it.
• It does not take over your computer or work through your applications for you. You choose where the cursor is, and you decide what happens to the text afterwards.
• AI requests need an internet connection, an enabled service, your consent and the relevant access.
• Audio and text may be sent to remote services to process an online request. If you opt in to screen context, that context may be sent too. Check your organisation's rules on project information before using either.
• AI output is a draft, and you review it.

A commissioning observation is a record other people will rely on, so the setup should keep you in control of when it leaves your screen.

One boundary matters before anything else. For this task, use the supported AI Task workflow and put the instruction and the facts the draft needs together in that one request: the equipment identifier, the test record reference, the observation and the open action. Dictating alone does not turn AI on. The AI does not automatically have your earlier dictations, text already in the field or what is on your screen. Screen context is a separate opt-in and may be sent to remote services. If you leave it off, anything the draft needs must be spoken or supplied in the request itself.

Before the first real entry:

1. Choose a safe destination field. Use the observations section of a report draft or a notes document, not an open message window or a chat box. A field that is unlikely to submit anything by accident is the best place to test.
2. Turn off automatic Enter or send behavior. SpeakLingo has an optional behavior that presses Enter after delivering text, and in some apps that can submit a message or form. Switch it off for this workflow so delivered text simply sits at the cursor.
3. Confirm the language. Select a supported transcription language that you speak naturally. Identifiers and numbers are easier to check when the surrounding sentences are in the language you think in.
4. Confirm online AI is ready. You need an internet connection, the AI service enabled, your consent given and access in place. Without these, the spoken AI request will not run. Transcription has its own mode, setup and access requirements, so AI being unavailable does not show that transcription is available, and the reverse also holds.
5. Decide on screen context. It is opt-in. If the entry concerns project information your organisation restricts, leave it off and speak only the four inputs.
6. Run a dummy entry first. Use invented equipment and references, as in the example below, and confirm the text lands where you expect and nothing is sent.
7. Review the draft before sending or using it. Read it against the source record, then send, save or file it yourself from whatever tool you normally use.

The draft can be no better than its inputs. Spend a minute assembling facts from the source record, and leave memory out of it.

Equipment. Copy the identifier from the schedule or test sheet. If the label on site and the schedule differ, record both and treat the difference as an observation in its own right.

Test record reference. Use the document number, sheet or entry that holds the data. If no record exists yet, say so. "No record reference supplied" is a legitimate input.

Observation. Write down what you saw, in words you can defend. Avoid conclusions such as "acceptable" unless the record itself states that result.

Open action. State what has to happen next and who owns it. If the owner is unknown, say "owner not yet assigned."

Interpreting measured values remains your job, so do not read them aloud and ask the AI to explain them. If values belong in the entry, copy them exactly as written in the record and check them again after generation.

The scenario below is fictional. The equipment, references and findings are invented to demonstrate the writing method. The draft shown is illustrative, not observed output from a test of the app, and nothing in it carries technical implications.

Before: rough notes

An engineer's raw notes after a walkdown, typed quickly:

DB-2 feeders. TR-0147 has IR results for feeders 1 to 6, feeder 7 line empty. Breaker 4 label says something different from the schedule, think it's the pump circuit vs workshop sockets? Need someone to look at original sheet. Contractor to sort label maybe.

As a handoff, these notes have several problems. The reader must infer which equipment is meant. "IR" is abbreviated. The label discrepancy is described with a guess. The owner of each action is vague. There is no date.

The spoken request

With the cursor in the observations section of a report draft, the engineer speaks the instruction from the template below, followed by the inputs:

Using only these verified inputs, write a commissioning observation draft. Equipment: distribution board DB-2. Test record reference: TR-0147. Observation: insulation resistance entries are present for feeders one to six; the entry for feeder seven is blank on the record. The label on breaker four does not match the circuit description on the schedule. Open action: test engineer to confirm feeder seven against the original test sheet; contractor to confirm the breaker four label against the schedule. Use a clear professional structure. Flag missing facts; do not invent them.

The engineer left the guess about the pump circuit and the workshop sockets out of the spoken inputs, because it was never verified.

After: AI draft at the cursor (illustrative output)

Commissioning observation: DB-2 (illustrative)

Equipment: Distribution board DB-2 Test record reference: TR-0147

Observation 1: Blank test entry. Insulation resistance entries on TR-0147 are present for feeders 1 to 6. The entry for feeder 7 is blank on the record.

Observation 2: Label discrepancy. The label on breaker 4 does not match the circuit description on the schedule.

Open actions 1. Test engineer to confirm the feeder 7 entry against the original test sheet. 2. Contractor to confirm the breaker 4 label against the schedule.

Missing facts to confirm before issue: observation date; reviewer name; schedule revision referenced; exact label text and schedule text for breaker 4; target dates for both actions.

What the engineer still does

The engineer reviews the draft against TR-0147 and the schedule and confirms that the feeder 7 entry really is blank. They add the observation date, the schedule revision and the exact label wording, and they remove each item from the "Missing facts" block as it is resolved. They also check that the draft states or implies no conclusion the record does not support. Only then do they use or send the text, manually, from whichever tool they normally use.

In this example the AI separated the two observations, numbered the actions, standardised the wording and listed what was absent. It did not guess which label was correct. That restraint came from the instruction to flag missing facts, and it still needs checking each time.

Keep this skeleton in a note and adapt the bracketed parts.

Spoken instruction

Using only these verified inputs, write a commissioning observation draft. Inputs: equipment [identifier]; test record reference [reference, or "none supplied"]; observation [what was seen or recorded]; open action [action and owner, or "owner not assigned"]. Use a clear professional structure. Flag missing facts; do not invent them.

Output structure to request or edit toward

Equipment: Test record reference: Observation (one per item): Open action(s) with owner: Missing facts to confirm before issue:

Optional additions to the instruction

• "Keep each observation to two sentences."
• "Number the open actions."
• "Do not state a pass or fail result."
• "Use the wording of the observation exactly where I give a quotation from the record."

Each addition narrows the AI's room to improvise, which helps when other people will rely on the content.

Run through this list before the draft leaves your hands. It reflects an illustrative writing practice and does not replace your project's own review requirements.

• [ ] Every equipment identifier matches the current schedule or drawing.
• [ ] Each test record reference opens the record I intended.
• [ ] Every observation traces to the record or to something I saw myself.
• [ ] Any numerical value in the draft was checked against the original source.
• [ ] The draft states no pass, fail or acceptability result that the record does not itself state.
• [ ] No invented detail has appeared, such as extra circuits, dates, names or causes.
• [ ] Each open action has an owner or is clearly marked as unassigned.
• [ ] The "missing facts" list is either resolved or deliberately retained.
• [ ] Nothing in the draft reads as instruction for energized work or as a statement about regulatory compliance.
• [ ] Project-sensitive details were handled in line with my organisation's rules for content sent to remote services.
• [ ] Automatic Enter or send behavior was off, and I decided whether to send or file the entry, and did it myself.

Any claim about speed needs your own data. To judge whether this workflow helps you, measure the whole path, including the review.

1. Define the end point. "Reviewed output" means a draft you have checked against the sources and would be willing to issue.
2. Time the full sequence for several real entries. Start when you begin assembling inputs and stop when the checklist above is complete.
3. Time your current method the same way. Use similar entries, for example other observations on the same kind of equipment.
4. Note the rework. Count the edits you made after generation, and whether any invented or misplaced detail appeared.
5. Compare across a run of entries. One entry says little. A series across different equipment types says more.

Include input preparation and review in both measurements. A draft that appears quickly but needs heavy correction may not reach reviewed output sooner.

• The AI sees your test data only if you supply it, whether by speaking it or through optional screen context. Even then it cannot confirm that the data is correct.
• Spoken numbers and identifiers can be mis-transcribed. Check them visually.
• If a compatible text field is not available in your tool, you may need another route, such as drafting in a supported field and moving the text yourself.
• Transcription support for 99+ languages is not a guarantee of the same range for AI-generated output, and the workflow is not translation. If you work in a language other than English, test results carefully.
• AI does not work offline. Offline English transcription is only a fallback, and only if it has been configured. It is not a substitute for the online workflow. You can structure raw notes with AI once the connection, service and access are available again.