Background
Duke Energy operates roughly 55 gigawatts of generating capacity — nuclear, fossil, hydro — across about a hundred plants serving 8.6 million customers. Every four hours at every one of those plants, an operator walks a defined route and records readings off equipment: temperatures, pressures, levels, vibration, fluid samples. EPRI's own guideline defines the practice precisely: "the systematic inspection and monitoring of equipment and processes by operating personnel during system walkdowns of assigned areas while on shift" — done because "effective equipment monitoring is necessary to detect abnormal conditions or adverse trends so that appropriate action can be taken before equipment malfunction occurs."
That last clause is the entire point. Rounds are not paperwork. Rounds are how a utility learns that a bearing is running eight degrees hotter than it did last month, while it's still a maintenance ticket instead of an outage. EPRI needed 120 pages to write the guideline for doing it well.
For decades this ran on clipboards, and then on somebody re-keying the clipboard into a system hours or days later.
In 2018 Duke launched Lighthouse, its digital transformation program — cross-functional product teams of IT and business staff, headquartered in an 83,000 square foot converted textile mill at Optimist Hall in Charlotte, organized by product stage from ideation through prototyping to production. Teams were funded in eight-week metered cycles and had to submit Business Outcome Summaries to justify continued funding. Lighthouse shipped 30+ digital products with an average payback under two years, and one of its named product categories was mobile apps for field workers.
Orbit was that, for generation: an iPad app replacing manual data acquisition and logging at ~100 plants and ~8,500 plant workers. I led backend and DevOps for it from July 2021 to January 2024.
It's also — unusually for internal enterprise software — externally documented. EPRI published a case study on it in March 2022, Utility Digital Worker Application for Generation: Integrated Operator Rounds – Duke Case Study, whose abstract reads: "Transitioning from manual/paper capture of operator rounds data to a purpose-built mobile app is often one of the first use cases developed by utilities as they begin to deploy mobile devices for field O&M use... this case study evaluates an application being developed by Duke Energy called Orbit."
Challenge
"Put the checklist on a tablet" is the version of this that sounds like a two-sprint project. Here's what's actually underneath it:
- The failure mode you're really fixing is fraud, not typing. The industry term is pencil whipping — signing off rounds without performing them. An operator under time pressure fills in the temperature, the vibration, the fluid level, and moves on. The documented root causes aren't laziness: unrealistic PM workloads, and management cultures that reward a clean 100%-complete report over an honest one. The structural cause is the one that matters here — paper offers no verification layer whatsoever. A signed sheet proves that someone had a pen. It does not prove anyone stood in front of the machine.
- A power plant is a Faraday cage. Turbine halls, boiler decks, below-grade pump rooms — steel and concrete, thick walls, no signal. Field-service research puts something like 40% of field work in areas with poor or no coverage, and a plant basement is the canonical example. That makes offline-first non-negotiable: local storage is the primary store, the app must be fully functional with no network at all, and sync-on-reconnect has to reconcile without a human refereeing every conflict.
- The data wants to live on the wrong side of a one-way door. This is the deep one. Plant telemetry lives in a historian (PI and similar) inside the OT security boundary. The standard architecture has OT push outward to an industrial DMZ; IT reads from the DMZ and never reaches inward. At the strictest tier that boundary is enforced by a data diode — hardware whose transmit-only physical medium makes reverse traffic impossible, not merely forbidden. So reading historian values to compare against what an operator typed? Flows the permitted direction, fine. Writing operator-captured readings back toward the systems of record on the OT side? That is the forbidden direction, by design, in hardware. Where rounds data lands and how it reconciles with DCS values is a boundary problem before it's a schema problem.
- The regulatory floor raises the bar on integrity. NERC requires 90-day retention of operator logs, and CIP evidence retention runs three calendar years. NERC's own evidence guidance accepts "dated operator logs... in electronic or handwritten format" — meaning going digital doesn't lower the bar, it inherits it. Whatever holds this data is an evidentiary record, not a convenience app.
- Resistance to the rollout is rational, and treating it as technophobia gets you nowhere. Timestamping a reading, attributing it to a named operator, and attaching photographic proof doesn't just digitize the workflow — it removes a coping mechanism people were quietly relying on to survive an unrealistic workload. If you ship the tool without addressing the workload that caused pencil whipping in the first place, you haven't fixed the problem; you've just made it visible and made yourself its author. Meanwhile the workforce itself is turning over — AWWA estimates 30–50% of the utility workforce retires within a decade — so the tool has to be learnable by people who never used the paper system either.
- A hundred sites are not one site a hundred times. Nuclear, fossil, and hydro run different regimes, different equipment, different routes, different regulatory scope. There was a mature commercial market for rounds software during this whole period — GE Vernova, AVEVA, Innovapptive and others — and Duke was already an AVEVA shop on the analytics side. Building anyway means the thing you build has to justify itself against a product someone else already maintains.
Solution
The architectural shape follows from the boundary: Orbit is an IT-side application — it doesn't control anything, it can't influence plant operation inside fifteen minutes, and it therefore lives outside the electronic security perimeter and reaches plant data across the DMZ rather than living inside it. That decision cascades into everything else.
The API and the serverless backend
The backend ran on AWS — Lambda behind API Gateway, with DynamoDB for storage, WAF and CloudFront at the edge, written in Python and Node.js, with Azure in the picture on the enterprise side. Serverless fits the traffic shape unusually well: rounds are bursty and scheduled rather than steady. Operators sync when they come back into coverage, which means the load pattern is spiky and correlated across shift boundaries — a workload you'd otherwise be over-provisioning for around the clock.
DynamoDB fits for a reason worth naming: a reading is an append-only observation bound to a tag, a timestamp, and an operator. It's closer to an event log than to mutable shared state, which is what makes offline sync tractable at all. Two operators can't really conflict over a reading — they can only both have taken one. The genuinely hard conflicts live in route definitions and shift handover, not in the numbers themselves.
Evidence, not checkboxes
The single highest-leverage feature against pencil whipping isn't a form — it's proof. I integrated Orbit's REST API with S3 via a custom Terraform module to enable photo and video attachments on readings. That changes what a round is: a checkbox says a human asserted something; a timestamped photo of a gauge, attributed to a named operator, is evidence. The combination of reading, time, identity, and image is what makes a round auditable after the fact — and what makes the data trustworthy enough to trend against, which is the whole reason anyone collects it.
Making it fast enough to be trusted
I sped up Lambda functions by ~21% using a shared runtime environment and caching. On a sync-heavy, bursty workload, cold starts and per-invocation setup are most of the tail latency, and the tail is what an operator standing in a plant basement actually experiences. A sync that feels slow is a sync people work around.
Shipping it safely, and often
Most of this work was making a regulated-industry release pipeline move at a reasonable speed:
- Concourse CI for delivery, with SonarQube, Sonatype IQ, and CheckMarx integrated into the pipeline — static analysis, dependency risk, and security scanning as gates rather than as an audit that happens later
- Migrated AWS infrastructure from a shared environment to a dedicated one, cutting infra PR merge time by 8–24 hours. Shared infrastructure means every team's changes queue behind every other team's review; that's an organizational bottleneck wearing an infrastructure costume
- DynaTrace and AWS X-Ray dashboards for production releases and incident tracking
- Load and integration testing the Orbit API with Postman, driven by an auto-generating web scraper so the tests tracked the API instead of rotting behind it
- A custom API documentation generator built on EventBridge and CloudTrail, so feature communication across teams didn't depend on someone remembering to update a wiki
Scaling the org, not just the app
I led 5+ Communities of Practice across ~100 engineers on 6+ teams. In a shop where product teams are deliberately siloed by metered funding — every team justifying its own eight-week cycle — the cross-team channel is the thing nobody's budget owns and everybody needs. That's not a soft-skills footnote; it's how you stop six teams from independently solving the same offline-sync problem six different ways.
Results
Orbit replaced manual data acquisition and logging across 100+ plants and ~8,500 plant workers, saving Duke roughly $1M annually in labor capacity, and supporting reliability for 8.6 million customers. It moved rounds from a paper record that got re-keyed hours later into timestamped, attributed, photo-backed data that could actually be trended — which is the difference between recording that a machine is fine and noticing that it won't be.
The corroboration is the part I'd point to hardest, though. EPRI chose Orbit as its generation-side case study for mobile operator rounds — and its stated purpose for the study was "to understand the drivers and value behind mobile operator rounds." That framing is worth sitting with: as of 2022 the industry's value case for digitizing rounds was still being established, and Duke's app was the exemplar the research institute used to establish it. There is, to this day, almost no credible independent ROI data published on digitizing operator rounds — the widely-repeated vendor figures have no studies behind them. Orbit wasn't following a proven playbook. It was one of the things the playbook got written from.
Why this matters for a business:
- Digitizing a paper process is a data-integrity project wearing a UX costume. The clipboard's real defect was never that it was slow — it was that it couldn't tell the truth from a signature. Timestamp, identity, and image are what convert an assertion into evidence, and everything downstream (trending, condition-based maintenance, audit) depends on that conversion having happened.
- Offline-first is an architecture, not a feature you add later. If the network is absent for most of the work, then local storage is the system of record and the server is the replica. Deciding that on day one produces a different app than deciding it in month nine.
- The security boundary determines the architecture before you write a line. When the data you need lives behind a one-way door, "where does this run" is answered by the compliance topology, not by preference. Knowing that early is the difference between a design and a rewrite.
- When people resist your rollout, read it as data. Rounds were being pencil-whipped because the workload made honesty expensive. A tool that makes dishonesty visible without making honesty affordable just relocates the problem. The tooling and the workload have to move together.
Conclusion
Orbit is what a clipboard becomes when a hundred plants, eight thousand operators, a one-way security boundary, and a regulator all have a say. The engineering was never about forms — it was offline-first data capture in buildings that block radio, an evidence model strong enough to survive an audit, and a release pipeline that could move quickly through a regulated environment without cutting the checks that make it regulated.
If you've got a paper process holding up something expensive, or field data that can't get from where it's captured to where it's needed, that's the shape of problem I like. Book a call and let's talk about it.

