From AI potential to operating capacity.

CHAPTER 01

An application is the beginning of a business case.

Salesforce’s AI in Utilities guide describes opportunities in customer service, demand forecasting, maintenance, outage response, energy procurement, and renewable integration. It also identifies privacy, integration, and responsible decision-making as implementation challenges. These are useful directions for investigation. The guide does not establish what a particular utility will save, how much human review it will need, or whether a specific deployment will meet its operating requirements.

The U.S. Department of Energy’s 2024 AI for Energy report similarly identifies opportunities in planning, permitting, operations and reliability, and resilience. Its examples include faster grid studies and support for permitting review. This expands the question beyond a single assistant: where could AI increase the organization’s ability to deliver?

Our research question is practical: under what conditions does an AI-assisted workflow produce more acceptable work with the same resources, while preserving the quality and authority the work requires?

Corvana’s proposed answer begins with a bounded workflow. “Customer service” is a department. “Prepare a billing explanation from an approved account record and tariff, then route exceptions to a specialist” is work that can be tested. That distinction makes the ambition measurable.

CHAPTER 02

Select work with a visible outcome.

The application areas below draw on Salesforce’s guide; the workflow boundaries and evaluation measures are Corvana’s proposals. They are candidates for testing, not descriptions of deployed Corvana products.

These workflows may require different techniques. A numerical forecast, an equipment anomaly detector, and a document-drafting assistant should not share a generic “AI accuracy” score. Each needs a baseline and an outcome appropriate to its job.

We propose prioritizing candidates with repeatable demand, accessible source records, an identifiable owner, and an outcome that qualified people can grade. A costly bottleneck with unusable records may first need data work. A polished demonstration with little recurring demand may have limited economic value. Selection should account for both.

CHAPTER 03

Test the whole path to an accepted result.

The proposed evaluation unit is the completed case, including human review and any fallback. If an assistant drafts a package quickly but shifts work to an engineer who must reconstruct its evidence, a model-level speed improvement has not established a workflow improvement.

For each candidate, Corvana proposes an evaluation with five elements:

1. Define the operating boundary. Name the task owner, permitted records, required output, and actions the system may take. For an initial document workflow, use an isolated environment with approved records and no live transaction authority. State what remains a human decision.
2. Build a comparison set. Separate development cases from cases reserved for evaluation. Reconstruct the information available when each case was handled; hide later outcomes. Include ordinary work, incomplete records, conflicting sources, and cases previously escalated. For forecasts, preserve the order of time and test unusual operating periods separately.
3. Agree on acceptance before running. Have domain reviewers define which errors require rejection, correction, or escalation. For a billing explanation, check account facts and the applicable tariff. For a maintenance package, check asset identity, document completeness, and unsupported recommendations. A persuasive answer can still fail.
4. Measure completion and effort. Compare equivalent cases with and without AI assistance. Record preparation, verification, corrections, escalations, failed attempts, and manual fallback. Separate hands-on time from waiting time. Report results by case type, including the cases the workflow could not finish.
5. Report uncertainty and a decision. Retain the input, model and tool versions, reviewer scores, and reasons for failure. Examine variation across repeated runs and reviewers. A small sample without observed serious errors is limited evidence. End with a recommendation to proceed within scope, revise and retest, or stop.

NIST’s AI Risk Management Framework Core supports documenting context, benchmarks, oversight, evaluation methods, and continuing monitoring. It organizes risk management through Govern, Map, Measure, and Manage. We use it as guidance for structuring evidence, not as proof that an individual workflow is safe or effective.

CHAPTER 04

More capacity and lower spending are different outcomes.

We propose keeping three ledgers: work completed, service and decision quality, and cash impact. They answer different questions. A team may clear a backlog without reducing payroll. Faster preparation may improve turnaround while a later approval remains the limiting step. Both can matter, but neither should automatically be reported as an expense reduction.

Net hours saved must include review, rework, and fallback. Recurring costs include models, tools, monitoring, support, and retesting. One-time evaluation, integration, and training costs belong in the investment case as well. Keep each cost in one place to avoid double counting.

Before rollout, finance and the workflow owner should identify how capacity will be used: completing deferred planning work, improving response times, reducing overtime, or changing a specific contractor commitment. Only the spending changes belong in cash savings. Forecasts of adoption and benefit should be tested against actual use after deployment.

For a worked financial example, see The economic case for an AI sandbox. The same discipline applies here: the economic case depends on the entire process, not the price of a model call.

CHAPTER 05

Match the next step to the consequence.

A useful sandbox result earns a deployment decision. It does not itself grant new permissions. We propose separating three kinds of authority when planning the next test.

Prepare information

The workflow retrieves, organizes, and drafts within a defined information boundary. Test source access, freshness, omissions, and the reviewer’s ability to trace a conclusion. Keep a clear route to reject or correct the result.

Support a decision

The workflow compares options or recommends a course of action. Test it against domain-specific criteria and counterexamples. Make uncertainty visible, record the reviewer’s disposition, and measure whether recommendations improve the decision process rather than simply getting accepted.

Take an operational action

Changing equipment settings, executing a transaction, or issuing a consequential instruction requires additional assurance specific to the system involved. A document replay cannot establish readiness for live grid control. The relevant engineering and operational owners must define the tests, safeguards, and authority appropriate to that action.

For a workflow that proceeds, start with a limited group and a defined review period. Compare actual quality, adoption, cost, and exception handling with the evaluation. Set conditions for pausing or reverting the workflow, and reassess material changes to models, tools, permissions, or source data.

CHAPTER 06

Build the company’s ability to deliver.

Our central proposition is that AI creates durable operating value when a company can repeatedly convert domain knowledge into work it can trust and use. The first successful workflow can leave behind reusable evaluation cases, clear source ownership, review criteria, and a measured baseline.

That foundation can make the next evaluation easier, but its results do not transfer automatically. A billing workflow does not validate a maintenance recommendation. Expansion still requires new evidence for the new context.

Start with work you can measure. Build toward a company that can accomplish more.

For Corvana, that is the ambition: connect decades of operating expertise to additional capacity, with evaluation making each step accountable.