Abstract
The Merlin™ Document Writer turns a completed power quality analysis into finished, shareable documents: customer letters, executive summaries, technical reports, regulatory responses, and more. It works from reusable templates that capture a set of editorial decisions once (who the document is for, in what tone, in what form) and then applies them on demand to any analyzed recording. Where the Merlin™ AI Dashboard answers “what did the analysis find?” and Merlin™ Chat answers “help me understand this issue,” the Document Writer answers “write it up for this reader.” This paper describes the feature, how it fits into the power quality workflow engineers already use in PQ Canvass, and walks a single example end to end: a plain-language letter to a homeowner who reported flickering lights.
The Document the Analysis Doesn’t Write
A Merlin™ analysis reviews an entire recording and presents its findings in an organized, severity-ranked view. Merlin™ Chat lets an engineer interrogate those findings conversationally (see WP420). But at the end of most investigations there is still a document to write, and that document is rarely written for another power quality engineer. It is written for a homeowner, an executive, a regulator, or a customer-service ticket. Each reader needs a different audience, tone, length, structure, and stance.
This is where a great deal of engineering time goes, and it is work that engineers are not, as a rule, trained or eager to do. A technically excellent analysis still has to be translated into prose a non-specialist will accept, and most technical people find that translation slow going. Power quality engineers in particular often lack the time to assemble a detailed technical report, and to render a flicker study into language a residential customer will understand. Management has a different problem: the people who coordinate with regulators and internal departments need a consistent, predictable voice across everything the organization sends out.
Some of these communications are delicate (a finding that places a cause on the customer’s side, say, or a fix that will fall to them), where the wording needs to be as careful as it is accurate.
Where the Document Writer Lives in PQ Canvass
The Document Writer is part of the Merlin™ Assistant, the same surface reached from a recording’s Assistant tab that hosts Merlin™ Chat. Within the Assistant, a Documents area sits alongside Chat and is organized into two halves:
- Reports: the documents Merlin™ has written about this recording. Reports are tied to the recording they were generated against.
- Templates: the reusable recipes those reports are generated from. Templates are not tied to a recording; they belong to the account and can be reused on any recording.
Like the rest of the Assistant, the Document Writer reasons about a recording that has already been analyzed. The analysis is the source material; the Document Writer never invents findings, it renders the ones Merlin™ has already produced into a document for a particular reader.
Templates and Reports
The split between templates and reports is important to get right. A template captures the editorial decisions that make a document suitable for its audience: who it is written for, the tone it takes, the form it takes (a letter, a memo, an executive summary, a checklist), what it is mainly trying to accomplish, and how it handles a complaint or assigns responsibility. A report is what you get when Merlin™ applies a template to a specific recording: a finished document, grounded in that recording’s analysis.
Templates are grouped into two sections in the gallery. Under Power Quality are the presets curated by PMI, spanning a range of audiences and forms: an executive summary for management, a plain-language letter for a customer, a site-survey checklist for the field, and more. Under Your Organization are the templates your own team has created and saved for reuse across your account, whether built from scratch or adapted from one of the presets. The presets work either way: you can generate a report straight from one, or use it as the basis for a template of your own.
A Customer Letter from a Flicker Recording
To show the Document Writer in use, we will use an example: a residential service at “100 Example Road, Anytown,” monitored for almost six days. The Merlin™ analysis found the service generally healthy (voltage well within normal range, no interruptions, no loose-neutral signature), with one real issue: borderline long-term flicker, driven by repeated small voltage drops when heavy equipment cycles on and off. The flicker is customer-leaning in origin and shares a transformer with two neighboring homes. The homeowner has reported flickering lights, and the utility (here called Acme Electric) needs to write back.
This is precisely the delicate translation described earlier. The letter has to confirm the problem is real, reassure the homeowner it is not dangerous, and convey that the flicker is driven by load on the customer’s side rather than by the power the utility delivers, without accusing the homeowner, and without either dismissing the concern or committing the utility to a fix.
From the recording’s Reports view we choose New Report, which opens Create Report (Figure 3). The screen has two columns. On the left we choose a template; here we select the Customer Letter (Plain Language) preset. On the right we configure the run:
- Report Name auto-fills as “Customer Letter (Plain Language) – 100 Example Road, Anytown” and can be edited.
- Output Language is left at English. Spanish is also available.
- Utility Name is set to Acme Electric, which brands the letter.
- Additional Guidance is where a single run is steered. The template already knows how a plain-language customer letter should read; the guidance supplies what the template cannot know, namely the specifics of this situation: “Write to the homeowner who reported flickering lights, on behalf of the utility. Keep the tone warm, plain, and reassuring, no technical jargon (avoid Pst, Plt, IEEE 1453, ‘compliance’). In everyday terms: we placed a monitor on the service and confirmed the flickering is real. Explain clearly but gently that the cause is heavy equipment at their own location cycling on and off, not a problem with the power the utility delivers, so the flicker follows their own usage.”
The guidance is short on purpose. Most of the editorial work is carried by the template; the per-run guidance just points the run at this homeowner, this complaint, and the particular thing that is awkward to say.
Generating the report hands off to the Report View, which shows the finished letter alongside the recording, the guidance that was given, and the template that produced it (Figure 4). The result reads as a letter, not a report:
Thank you for letting Acme Electric know about the flickering lights at your home. We installed a power monitor at your meter for almost six days so we could see exactly what the voltage at your house was doing while your everyday appliances were running.
It states the good news first, in plain terms: the power coming to the home is healthy; the voltage stayed in the normal range; there is no sign of a loose or broken neutral. Then it confirms the homeowner’s actual complaint, and here it does the delicate part:
The monitor shows that the biggest of these changes line up with heavy equipment turning on and off on your service (for example, a heat pump, well pump, air conditioner, or similar motor load) … We also see some smaller dips when your load is low, which tells us the two neighboring homes that share the same transformer with you, and the wider neighborhood, also play a part.
That single passage carries the whole communication. It places the cause on the customer’s side (equipment cycling “on your service”) without calling it the homeowner’s fault, and it credits the shared transformer and the wider neighborhood honestly rather than overstating the homeowner’s role. It never says the power Acme Electric delivers is at fault, because the analysis does not support that, and it never says the homeowner did anything wrong, because that is not the message. The letter closes with practical steps the homeowner can take and an offer to look further if reports continue; the utility neither dismisses the concern nor shoulders a fault that is not its own.
A letter like this is the kind of thing an engineer can spend real time drafting and second-guessing: getting the reassurance right, keeping the jargon out, finding language for the cause that is honest but not accusatory. Here it is produced in a single run, grounded in the recording’s actual findings, and the editorial decisions that make it land (the plain language, the reassuring tone, the careful handling of cause) are captured in a template the next engineer can reuse on the next complaint.
Builidng Your Own Templates
The presets cover common cases, but the feature’s leverage comes from building templates of your own: encoding your organization’s house style for a customer letter, your standard structure for a regulatory filing, the exact posture you take on attribution. Templates are built in Create Template, which offers three ways in.
From Scratch opens the recipe form, a small set of plain-English choices that define the document. Past a name, an icon, and a short description (when to use the template and the style you want, where stronger wording pushes the writing further in that direction), the choices are:
- Audience: who the document is written for; this sets its technical level and tone.
- Tone: the voice of the writing, from warm and approachable to strict and regulatory.
- Document Type: the kind of document to produce; this sets its default length and format.
- Primary Goal: what the document is mainly trying to accomplish.
- Complaint Handling: how the document treats the customer’s complaint or concern.
- Responsibility Posture: whose perspective the framing leads with; responsibility is assigned only where the recording supports it.
- Section Plan: let Merlin™ choose the section structure, or define your own ordered sections.
From a Template starts from a preset, prefilling the same form with the preset’s choices so they can be customized and saved as a new template; the preset itself is untouched.
From Documents skips the recipe entirely: you upload one to three finished documents you already like, and Merlin™ infers a reusable template from their style.
Whatever the starting point, the builder does not save a template directly. It hands off to a review step (Figure 6), where Merlin™ presents a plain-English interpretation of what the template will actually produce, along with anything worth a second look, for instance a note that a request for a confident, no-hedging tone will still soften conclusions where the recording evidence is weak. The template is not published until you confirm it.
How it Fits with the Dashboard and Chat
The Document Writer is the third of three Merlin™ surfaces, and they are complementary views of the same analysis. The AI Dashboard presents what Merlin™ found, in a structured, severity-ranked form. Merlin™ Chat opens that analysis to free-form investigation: what caused this, how bad is it, what would fix it. The Document Writer takes the result and writes it up for a specific reader.
A typical investigation moves through all three: an engineer triages on the Dashboard, investigates a finding in Chat, and then produces the deliverable (the customer letter, the executive summary, the regulatory response) with the Document Writer, reusing a template that already encodes the right audience and tone. Because all three draw on the same completed analysis, the document does not diverge from what the Dashboard shows or what Chat discussed.
Conclusion
The Document Writer closes the loop from analysis to communication. The same recording that Merlin™ analyzed becomes the letter to the customer, the summary for management, the response to the regulator, each written for its reader, each grounded in the recording’s actual findings rather than invented. Templates make that output consistent across engineers and fast to produce, and they capture the editorial judgment that is hard to scale: not the technical content, which the analysis already provides, but the tone, the framing, and the tact required to say a difficult thing well. For the engineer who would rather analyze than write, and for the organization that needs every customer-facing document to sound the same, that is the highlight of the feature.
