Assemble the inputs behind an ignition, spread, storm or water-system score, return the score with its confidence and the direction of its error, and hold the decision for a named incident commander.
Weather feeds, fuel-moisture readings, telemetry and circuit records, from supported sensor, GIS and outage sources.
02
Field names, units and timestamps, normalised, with each value carried forward under the source it was read from.
Reason
03
An ignition, spread, storm-impact or water-system score, produced with its confidence and the direction of its error.
04
Your own thresholds, circuit segments and basin definitions, applied as configured and versioned when they change.
05
Every input behind a score — the reading, the record and its age — bound to it, so a reviewer can take it apart.
Decide
06
Measured results and actual events, marked apart from anything modelled, because duties run on facts, not on scores.
07
Scores, routed to the named incident commander who decides, with nothing acted on ahead of that decision.
Out
08
The score, the inputs, the decision and the reason, retained under the retention rules your owner approved.
09
Write actions only inside the boundaries agreed at implementation — never to a switch, a valve or a notification.
→Product statement
The agent produces a score; a commander decides. A score does not shrink the utility's liability, and once it exists it is discoverable.
Example workflow
One score, input to decision
AgentHuman
1Inputs receivedWeather feed, fuel-moisture reading, sensor telemetry or a laboratory result
2Inputs assembledCircuit and basin records, asset history, terrain and field observations, each with its source
3Score producedScore, confidence and direction of error
4Controls appliedInput-freshness checks, validated-range checks, measured-fact separation and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is switched, notified or declared at any of them — the agent is scoring, and the commander's lane opens at the confidence gate.
5DecisionSplits at the confidence threshold
High confidence
Goes to the incident commander.
Low confidence
Adds a risk-engineering read first.
Commander decision
The score is held with its inputs, its error direction and the confidence.
Accept · Set aside · Send to risk engineering
Accepted — the commander acts▼
6Decision record updatedOnly where write access and approval policy allow it
7Outcome evaluatedScore calibration, set-aside rate, what the commander did instead and what actually happened
Set aside
Every score the commander set aside is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
De-energising any circuit, or restoring one to service.
Issuing a public notification to customers or an agency.
Declaring a system, a circuit or a basin safe.
Deciding that a notification duty is not triggered.
Automation boundaryAgent acts unaided
✓Assemble the inputs behind a score from the sources on file.
✓Produce the score with its confidence and the direction.
✓Surface the measured results and events that duties actually run on.
✓Flag when inputs fall outside the tested range, and hold the score.
Any write happens inside the boundaries agreed at implementation, and never to a switch or a valve.
Changing a risk threshold or a retention rule.
Categorising a service line for the inventory.
Running on when it is outside its validated range.
Changes to the model, the prompt or its configuration.
Example output
One score, annotated
Everything the agent scores is attached to the inputs it was drawn from.
Risk-score output · single circuit segmentIllustrative example
Segment
Score produced
Input age
Error direction
Confidence
Validated range
Wind-exposed feeder
Ignition risk elevated on the upper span, spread footprint wide
22 min
Runs small and slow
71%
Inside the tested range
As receivedTaken from the weather feed, the sensors and the circuit record — nothing here is written by the agent.
Inputs usedFuel-moisture readingWind forecastCircuit inspection record
Why this scoreSpread error is not symmetric — when the model is wrong, it runs small and slow.
ActionAcceptSet asideSend to risk engineering
What the score decidesBelow the configured threshold the score picks up a risk-engineering read first.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every scoreFrom the feeds and sensors
03Scoring
Build the score
Draw on weather feeds, sensor telemetry, circuit and basin records and the thresholds on file.
01Approved path
A score is not a decision
Routine scores and the inputs behind them arrive already assembled.
02Human review
Send the read where the model is
Out-of-range and low-confidence scores are marked, so the commander's read starts where the model is least tested.
04Build an evidence trail
The score, the inputs behind it and the incident commander who acted on it stay on the record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Weather and fire riskNWS · NOAA HRRR RAWS · Synoptic Data
GIS and asset dataEsri ArcGIS · Smallworld Maximo · Copperleaf
Grid sensingSCADA · ADMS Line sensors · weather stations
Agent
Wildfire, storm and water analytics
Reads the inputs Produces the score Holds for the commander
Water systemsSCADA historian · LIMS Service-line inventory · CMMS
Customers on ventilators and oxygen concentrators sit on few segments, and the aggregate never counts them. Nestack reports the set-aside rate by segment and basin, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Segments with medical-baseline load
9.0%
3.2×
Review
Extreme wind and low fuel moisture
5.9%
2.1×
Review
Storm damage estimation
4.5%
1.6×
Watch
Routine seasonal scoring
2.2%
0.8×
Normal
Bar: set-aside-rate lift vs. routine-scoring baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A cycle ends in the suite, not the review
The cycle ends when a case exists in the suite, not when the miss was discussed. That suite is what the next score put to a commander is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Set-aside rate rises on one segment.
02Diagnose
Read the score back against the inputs behind it, segment by segment, until one cause holds.
03Improve
Changes carry a version and the events that prompted them.
04Verify
Release is held until the affected cases pass.
05Learn
The case is kept permanently, and the threshold notes move with it.
Learn → DetectThe return edge. Next season's detection is measured against a longer suite.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, scoring workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Risk-workflow discovery and automation-boundary definition.
02Weather, sensor and GIS source assessment.
03Threshold, circuit-segment and basin definition mapping.
04Input ingestion and normalisation.
05Scoring logic and input binding.
06Confidence scoring and escalation routing.
07Commander decision workflow.
08GIS, sensor and outage-system integration.
09Calibration and notice cases.
10Guardrails and escalation controls.
11Score-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne territory, one seasonProductionProduction risk systemsAdvancedMultiple territories / basins
Introduced at Pilot
Scoring from your data and thresholds✓✓✓
Commander decision✓✓✓
Calibration baseline✓✓✓
Introduced at Production
Reporting by circuit and basin—✓✓
Decision workflow in your systems—✓✓
Approved record write-back—✓✓
GIS and sensor integration—✓✓
Introduced at Advanced
Multi-state and multi-agency rules——✓
Approval chains across teams——✓
High sensor and event volume——✓
Multi-territory risk controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your risk workflow and incident structure→Input ingestion and score assemblyWeek 1
02Representative scored events→Scoring baseline, calibration and input bindingWeek 2
03Your thresholds, segments and basin definitions→Threshold, circuit-segment and basin definition mappingWeek 1
04Access to relevant feeds, sensors or exports→Weather, sensor and GIS assessment, then integration setupWeek 2
05Scores you would not want acted on→Calibration cases and failure-mode testingWeek 4
06What must reach a commander before power is cut→Confidence scoring, escalation routing, guardrails and approval controlsWeek 3
07Named incident commanders to work the pilot→Commander decision workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
The bands follow the actual work, which is why the fifth week doubles rather than pads.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Risk-workflow discovery and the automation boundaryW2Source integration and the scoring baselineW3Scoring workflow, confidence logic and escalation controlsW4Evaluation suite, calibration cases and failure-mode testingW5GIS and sensor integration, pilot scoring and targeted correctionsW6One season scored under the incident team, then handover
Reading the bandA bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6The season closes validation and Agent Care owns the running agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Energy AI agent
Build a risk-analytics agent around your incident process.
Show us your feeds, your thresholds and who commands an incident. Who signs the order to cut power, and what has to reach them first? We draw the boundary around that answer.
