A load forecaster at a mid-sized investor-owned utility typed a single sentence into an AI tool and got back a number that looked exactly right. She forwarded it to her planning team. Three weeks later, when a capacity procurement decision was on the line, a colleague traced the figure back to the AI output and found the model had assumed a flat commercial growth rate from 2019, ignoring a 400 MW data-center interconnection that had just cleared the queue. The number was plausible. It was also wrong. The lesson was not "don't use AI." The lesson was: the prompt you put in shapes the output you get back, and in a regulated grid environment every prompt is the first line of your quality-control process.

Why Prompting Is a Professional Skill for Utility Work

Outside of energy, the standard advice about prompting AI tools is to "be specific." That is correct but incomplete for anyone working in a regulated, safety-critical, audited environment. Utility professionals need something tighter: a mental model for what information the AI needs before it can produce output worth trusting, and a set of standing disciplines that keep every session inside defensible boundaries.

Think of an AI model as a very well-read analyst who has never visited your service territory, does not know your tariff schedule, has not seen your latest SCADA data, and cannot look up your GIS asset register unless you hand it over. That analyst can draft, summarize, reason, and calculate. But left to their own devices, they will fill every gap with plausible inference. In a rate case or a NERC audit, plausible inference is not evidence. Your prompt is the briefing document you hand that analyst before you ask them to produce anything that could influence a real decision.

The stakes in utility work are unusually high. A wrong number in a load forecast feeds a procurement decision that locks in capacity costs for a decade. A wrong regulatory citation in a compliance filing can trigger a NERC notice of alleged violation. A wrong restoration estimate during a storm shapes how many crews you dispatch and whether customers wait two hours or twelve. These are not edge cases. They are the daily work of the audience for this program. The prompting discipline is not a nice-to-have; it is a professional obligation.

The good news is that the discipline is teachable in a single sitting and improvable over time. The prompts you write six months from now will be better than the ones you write today, not because the underlying AI has changed, but because you will have a library of tested patterns, a clearer sense of where the model tends to improvise, and habits that catch the most dangerous gaps before you send.

The Four Briefing Layers Every Grid Prompt Needs

Effective utility prompts are built in layers. Each layer closes a gap that, if left open, invites the model to improvise. Think of these not as a checklist you run through reluctantly before pressing send, but as the structure of a good briefing memo. A field operations supervisor who briefs a contractor for a substation switching job does not hand them a one-sentence task description. They provide role context, scope, the relevant switching procedure, the asset IDs involved, and the person to call if anything looks wrong. A good AI prompt does the same thing.

1. Role and jurisdiction. Tell the model who is asking and where the work lives. "You are assisting a load forecaster at a vertically integrated IOU in the PJM footprint" is a different brief than "You are a general assistant." The jurisdiction matters because tariffs, interconnection rules, and reliability standards differ by region. A NERC FAC-001 citation is correct everywhere in North America; a capacity obligation calculation is not. Jurisdiction also matters for the model's prior: in a deregulated market, "capacity" means an auction obligation; in a vertically integrated state, it means the IRP resource plan. Without the jurisdiction lock, the model will answer for the interpretation it saw most often in training data, which skews toward the ISO market structure.
2. Units and conventions. Specify MW vs. MWh, summer peak vs. annual energy, gross load vs. net load, coincident vs. non-coincident peak. An AI that receives an ambiguous question about "load" will answer for whichever interpretation is most common in its training data, which may not match your planning convention. Ambiguity here caused real procurement errors before AI was in the picture; it causes them faster now because the confident prose hides the assumption. A forecaster in the Midwest who asks for "expected load growth" and gets back MWh when she needed summer peak MW will not see the error in the first paragraph. She will see it when the number does not cross-check against her peak-day analysis.
3. Source material. Tell the model what documents, data, or standards it should reason from. "Using the tariff language I am pasting below" or "based on NERC Reliability Standard FAC-001-3 only" constrains the model to your source of truth rather than its training-data memory. This is the foundation of the cite-or-refuse discipline described in the next section. The more specific the source material, the more useful the output: "the IRP I am pasting" beats "my utility's IRP," and "NERC FAC-001-3, Section R1" beats "NERC FAC-001."
4. Output format and verification flag. Specify what you want back and whether the model should flag every number it cannot verify from the materials you provided. The flag instruction sounds simple but it transforms the output. Instead of a confident paragraph where every sentence sounds equally certain, you get a draft with explicit uncertainty markers your team can resolve against authoritative sources. The format instruction also matters for downstream use: a table of data is easier to move into a planning model than narrative prose; a bulleted list of obligations is easier to review than a flowing summary.

The Cite-or-Refuse Discipline

Of the four briefing layers, the most important for utility work is the instruction to cite sources or refuse to answer. This is not a politeness convention. It is a structural guard against the class of AI failures that hurt most in a regulated environment: confident, fluent, plausible-sounding output that is factually wrong.

A generative AI model is a next-token predictor. It does not distinguish between "I read this in NERC's posted standard" and "this is the most probable completion of this sentence given my training data." Both feel the same to the model. The only way to make the distinction visible is to require the model to show its evidence trail. If it cannot show one, it should say so explicitly rather than papering over the gap with authoritative prose.

The pattern shows up most dangerously in three places in utility work. First, regulatory citations: the model may state a NERC or FERC requirement confidently while getting the standard number, the version, the requirement number, or the effective date wrong. Second, asset references: if you describe a situation involving a specific substation or circuit and the model has never seen your asset register, it may invent plausible-sounding designations. Third, numeric thresholds: tariff rates, interconnection queue deposit amounts, and MAPE targets all have specific values that the model may have memorized from an outdated or regional source.

The practical cite-or-refuse instruction is straightforward. Append one of the following to any prompt that could produce a number, a regulatory claim, or an asset reference:

• "For every number or regulatory citation in your response, state the source document and section. If you cannot cite a source, write [UNVERIFIED] and explain why you cannot verify it."
• "If you are not certain of a fact, say 'I am not certain' rather than stating it as fact. Do not fill gaps with inference unless you label it clearly as inference and explain the basis for the inference."
• "Do not invent asset IDs, substation names, or circuit designations. If the question requires a specific asset record that I have not provided, ask me for it rather than substituting a plausible-sounding value."

Each of these instructions shifts the model from confident improvisation to disciplined drafting. The output is more useful, not less, because you know what to verify and what is already grounded in a source you control. A draft with ten [UNVERIFIED] flags is better than a clean draft with ten hidden errors, because the flagged version tells you exactly where to spend your verification time.

The cite-or-refuse discipline also has a secondary benefit: it trains you to notice when you are asking a question the AI fundamentally cannot answer well. If a prompt consistently returns [UNVERIFIED] on every number, that is a signal that you need to provide the source material rather than relying on the model's training-data memory. That is a useful diagnostic.

A prompt without a source instruction is a blank check. The model will spend it on whatever looks right to a well-read generalist who has never seen your tariff.

Real Prompts and Outputs: What Changes When You Brief the Model

The fastest way to understand the difference between a weak and a strong grid prompt is to see both. What follows are illustrative examples that show the transformation. These are constructed for teaching purposes; the patterns they demonstrate are drawn from real failure modes observed in utility AI deployments.

Example 1: Requesting a Forecast Context Summary

Weak prompt:

What is the expected peak load growth in my region over the next five years?

What you get: a national-average projection, possibly from a DOE or EIA publication in the training data, stated as if it applies to your territory. The model may cite an EPRI study, a DOE grid assessment, or a regional ISO report it encountered during training. It may be accurate nationally and completely wrong for your service area, which is absorbing three data-center campuses totaling 900 MW of anticipated peak demand. The output will be confident, well-formatted, and almost entirely useless for a resource planning decision.

What you cannot see from the output: whether the number is five years old, which geography it covers, whether it is summer peak or annual energy, and whether it accounts for behind-the-meter solar and EV loads at all.

Strong prompt:

You are assisting a load forecasting analyst at an investor-owned utility in the Mid-Atlantic region, operating in the PJM footprint. Our IRP uses summer peak MW as the primary planning metric. I am pasting our five-year load growth assumptions from last year's IRP below. For each assumption, identify (a) whether recent large-load interconnection activity for data centers above 50 MW could materially change it, and (b) what specific data I would need to update the assumption before the next IRP filing. For every claim you make, cite either the IRP text I have provided or label it [INFERENCE: basis]. Do not state any number as fact unless it comes from the text I have provided. If you are uncertain whether a data-center interconnection trend applies to the Mid-Atlantic specifically, say so rather than generalizing from national figures. [IRP excerpt follows]

What you get: a structured, assumption-by-assumption analysis that flags the data-center blind spot by name, lists the specific data sources needed (queue position reports, developer filings, PJM capacity tracking, ISO-NE published data if applicable), and marks every inferential step so your team knows exactly what to verify before the next IRP. The output is longer, but it is a working draft your team can actually use. More importantly, it is honest about what the model does not know, which is more valuable than a confident number the model invented.

Example 2: Requesting a Regulatory Summary

Weak prompt:

Summarize the NERC CIP requirements I need to know for our new AI system in the control room.

What you get: a plausible summary of CIP standards as of some point in the training data. It may miss CIP-003-9 (enforceable April 1, 2026) entirely, or mischaracterize the scope of CIP-012-2 (real-time data communication between control centers). It may omit the electronic access control requirements that apply to systems receiving SCADA data. It will sound authoritative and complete. It will not be. The risk is not that the summary is wrong in a way you can see; it is that the errors are in the gaps and the caveats, which confident prose does not surface.

Strong prompt:

I am a NERC compliance lead at a transmission-owning utility in WECC. I am evaluating whether deploying a generative AI summarization tool in our energy management system (EMS) constitutes a change that triggers obligations under NERC CIP-003-9 or CIP-012-2. For context: the tool would receive real-time SCADA data from our EMS and produce operator-facing summaries displayed in the control room; it would not issue control commands or interface with any field device. Using only the standard text I am pasting below, list each requirement that could apply and explain why, with section references. If the standard text does not address AI tools explicitly, say so and identify the specific requirement language I should take to legal and compliance counsel for interpretation. Do not state any compliance conclusion as settled; flag every conclusion as requiring human verification against the current effective standard. [CIP-003-9 and CIP-012-2 excerpts follow]

What you get: a structured, section-by-section analysis grounded in the text you provided, with explicit flags where the standard is silent on AI and clear pointers to where human legal judgment is required. The output does not pretend the AI knows the answer to a question that requires regulatory interpretation; it organizes the relevant standard text in a way that makes the legal and compliance review faster. This output is defensible in an audit. The first version is not.

Example 3: Requesting a Storm Outage Brief

Weak prompt:

Write a brief about last night's outages for the morning ops call.

What you get: a generic outage-brief template filled with placeholder language and no actual data. Or, if the model has somehow seen your data, a confident summary that may contain fabricated circuit IDs, wrong customer counts, and an estimated restoration time (ERT) it invented rather than derived from field inputs.

Strong prompt:

You are assisting an outage management specialist at a distribution utility. I am pasting below the OMS export from 11 PM to 6 AM covering last night's storm event. Using only this data, write a structured morning operations briefing that includes: (1) total customers affected at peak, (2) current customers still out, (3) circuits with the longest outage duration, (4) estimated restoration time for each open outage. For the ERT column, use only the field crew notes in the OMS data. If no field note supports an ERT, write [ERT: no field basis, verification required]. Do not invent circuit IDs or substation names. If the OMS data is ambiguous on any point, flag it. [OMS export follows]

What you get: a brief grounded in actual OMS data, with explicit flags on every ERT that lacks field-crew support. The operator reviewing it knows exactly where to make a phone call before the morning briefing. No invented data, no false confidence, and no ambiguous statements that could mislead crews or customer communications.

Jurisdiction, Units, and Standards: The Three Locks

Utility professionals work inside a web of overlapping rules: NERC reliability standards, FERC tariff requirements, state commission rules, and your utility's own operational procedures. An AI model without explicit context will blend these together in ways that feel coherent but may be legally or technically wrong. Three explicit "locks" in your prompt prevent this blending.

The Jurisdiction Lock

State the RTO/ISO, the state commission jurisdiction, and whether you are transmission-owning, distribution-owning, or both. These three facts change which rules apply. A capacity obligation calculation in MISO is not the same as in ISO-NE. A data-center tariff in a state with retail choice is not the same as in a vertically integrated state. A NERC reliability standard applies everywhere in NERC's footprint, but its interpretation in a specific context may depend on whether you are a Transmission Owner, Generator Owner, or Distribution Provider as defined in the glossary of terms.

If you do not state jurisdiction, the model will pick the most common or most publicized answer, which is usually something from a deregulated ISO market in the training data. For utility professionals in vertically integrated states, public power systems, or co-ops, this systematic bias toward ISO market assumptions can produce answers that are wrong in specific and expensive ways.

The Units Lock

State whether you are working in MW (demand) or MWh (energy), summer peak or winter peak, gross or net load, and what time resolution matters. These are not interchangeable, and the consequences of mixing them are material. A forecast for a peaker capacity procurement uses summer peak MW in the year of the study. A forecast for a solar interconnection study needs net load at fifteen-minute or five-minute resolution to capture the duck-curve shape. An energy-efficiency resource plan needs annual MWh savings, not peak MW reduction. An AI that misreads the unit will produce output that passes a quick look and fails when cross-checked against actual planning models.

This problem is not hypothetical. Energy professionals have discovered after the fact that an AI output they acted on was in the wrong unit. The confusion between MW and MWh is the most common, followed by the confusion between coincident and non-coincident peak, which matters in the context of transmission system peak contributions.

The Standards Lock

Name the specific standard version you are working against. Not "NERC standards" but "NERC FAC-001-3." Not "FERC rules" but "FERC Order 2023 as amended by Order 2023-A." Not "state PUC requirements" but "the commission's IRP rules as revised in Docket No. XXXX." Vague references invite the model to reason from whichever version is most represented in training data, which may be outdated. The stakes are highest in compliance work: a CIP requirement has an enforcement date; a tariff rate schedule has a docketed effective date; an interconnection rule has a queue-vintage applicability. Get the version number right in the prompt, or explicitly tell the model you are not sure which version applies and ask it to flag the question for legal review.

Building Your Personal Prompt Library for Grid Work

The most experienced AI users in energy organizations are not necessarily the ones who write the cleverest prompts in the moment. They are the ones who tested their prompts systematically over time and built a library of patterns they can reuse and share. Every task you do repeatedly has a best prompt. That prompt should be written down, tested against a range of inputs, and shared with your team.

The categories to build first are the ones where a bad AI output is most likely to influence a real decision:

• Forecast context summary. A template that includes your service territory, planning convention (summer peak MW, five-year horizon), and the cite-or-refuse instruction. Paste in your current forecast assumptions and ask for gaps and risks, specifically data-center step-load exposure and DER penetration blind spots.
• Regulatory change digest. A template that takes a FERC order or NERC standard excerpt and produces a structured summary: what changed, effective date, what your utility must do, open questions for counsel. Every claim tied to a section number. Every open question flagged for human review.
• Outage and restoration brief. A template that takes OMS data and field reports and produces a structured incident summary with explicit flags on ERT where the field basis is unclear. Includes a customer communication draft that does not state an ERT the field has not confirmed.
• Work order draft. A template that takes telemetry data and produces a switching order draft, with an explicit instruction not to invent asset IDs, circuit designations, or clearance numbers that are not in the input data. Every invented identifier is a safety risk.
• Rate case data response. A template for drafting responses to commission data requests, with an instruction to flag every number that requires retrieval from a source system (financial model, load forecast database, asset register) rather than the text already provided. The draft can show the structure; the numbers must come from verified sources.
• Interconnection study narrative. A template for drafting the boilerplate sections of a study report from structured engineering inputs, with explicit flags on every number and section that requires an engineer's sign-off before the draft is treated as a working document.

None of these templates is static. Every time a prompt produces a notable failure, figure out which briefing layer was missing and add it to the template. Every time a prompt produces a notably better result than expected, examine what made the difference and make it a standing feature. Your prompt library is a living quality-control document that gets better with every session. Share it with your team: the institutional knowledge about which prompts work for which tasks is as valuable as any other piece of operational documentation.

The 90-Second Prompt Review Before You Send

Before submitting any prompt that will produce output you might act on, run a 90-second mental check. This review is not a bureaucratic formality; it is a professional habit that the most effective AI users have internalized to the point where it takes less than a minute and prevents hours of correction work.

1. Have I stated who I am and where this work lives (role plus jurisdiction, including RTO/ISO and state commission if applicable)?
2. Have I stated the units and planning conventions my work uses (MW vs. MWh, peak vs. energy, gross vs. net, coincident vs. non-coincident)?
3. Have I told the model what source material to reason from? Or, if I have no source material to provide, have I told the model explicitly that it has none and must label everything as inference?
4. Have I asked the model to flag unverified numbers and citations, and to refuse to invent asset IDs or specific regulatory conclusions?
5. Is there any part of this question where the answer would change depending on a fact I have not provided: a tariff rate, an asset ID, a standard version number, a state-specific rule?

If you answer no to any of the first four, add the missing element before you send. If you answer yes to the fifth, either add the relevant fact to the prompt or instruct the model to ask you for it rather than filling the gap on its own.

This review does not guarantee a correct output. Nothing does. What it does is ensure that the output you receive is honest about its own limitations, which is the foundation of every verification step that follows. An output that clearly marks its own uncertainties is always more useful than one that hides them behind confident prose. The 90-second check is how you get the former instead of the latter.

Operators who built this habit into their workflows reported a measurable drop in the number of AI outputs that had to be discarded or corrected before they could be used. The time spent on the pre-send review is consistently less than the time saved by not chasing a plausible-but-wrong draft through multiple rounds of correction. It is also a form of professional discipline: the habit of thinking clearly about what you are asking before you ask it is good practice whether the question goes to an AI, a junior analyst, or a contractor.

Key Takeaways

• A prompt for utility work is a professional briefing document, not a search query. The quality of what you get back is bounded by the quality of what you put in.
• The four briefing layers every grid prompt needs are: role and jurisdiction, units and planning conventions, source material to reason from, and an output-format instruction with a verification flag.
• The cite-or-refuse discipline is the single most important guard against confident, plausible, wrong AI output. Append it to every prompt that produces numbers, regulatory citations, or asset references.
• Three explicit locks prevent jurisdiction blending: state your RTO/ISO and state commission, your units and planning convention, and the specific standard version (with version number) you are working against.
• A personal prompt library for your most frequent grid tasks is a living quality-control document. Every notable failure or success should update it, and it should be shared with your team.
• The 90-second prompt review before you send is your first line of quality control. Answering the five review questions takes less time than correcting a confident-but-wrong output after it has already shaped a decision.
• Reliability accountability stays human. A well-structured prompt makes the model a better assistant; it does not transfer accountability for the output to the model. The model recommended it is never a defense in a control room or a rate case.
• The most dangerous AI output in a utility context is not the obviously wrong one. It is the plausible-looking one with a wrong jurisdiction assumption, a wrong unit, or a fabricated regulatory citation buried in an otherwise accurate paragraph.