Manufacturing & Industrial
Utility Asset Risk API
Your network has several hundred thousand assets, a replacement budget that covers a fraction of a percent each year, and a regulator asking how you chose.
- Utility network operators
- Asset management software vendors
- Engineering consultancies
- Insurers
- Regulators and auditors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Utility networks fail asset by asset across a very large population. A distribution transformer, a pole, a section of water main or a switchgear unit each has its own age, duty, environment and maintenance history, and the operator has to decide which few thousand of several hundred thousand to intervene on this year. Age-based replacement is the default and it is a poor discriminator, because two assets installed the same week in different soil conditions deteriorate at very different rates.
Weather is the other half of the picture and it interacts with condition. A pole that would last another decade in still air fails in the first serious wind event after its crossarm degrades. Flooding affects ground-mounted equipment selectively by elevation. Thermal cycling drives transformer ageing in a way that load data captures and installation dates do not. Exposure and condition have to be modelled together, because either alone misranks the population.
The specific difficulty in this sector is failure data. Networks record outages well, because outages are reportable, but attributing an outage to a specific asset and a specific failure mechanism is often done loosely or not at all. Condition assessments exist for a sampled subset. So the honest model is usually a hybrid: physical deterioration where the engineering is understood, statistics where the failure records support it, and a clear statement about which parts of the network are being ranked on evidence and which on assumption.
Who buys this
Utility network operators, Asset management software vendors, Engineering consultancies, Insurers, Regulators and auditors
What the API returns
What comes back
- Deterioration and condition scoring per asset with the drivers behind it
- Failure probability over planning horizons, with intervals rather than point estimates
- Weather exposure scoring for wind, flood, thermal, lightning and vegetation risk
- Consequence modelling: customers affected, criticality and regulatory penalty exposure
- Intervention ranking combining probability and consequence against a stated budget
- Scenario analysis for budget levels, intervention strategies and climate projections
- Confidence and evidence basis per asset class, separating modelled from assumed
- Geographic rollups for feeder, district and region-level planning
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/assets/score | Score a batch of assets for condition and failure risk |
| GET | /v1/assets/{id}/risk | Full risk profile with drivers and evidence basis |
| GET | /v1/exposure/weather | Weather exposure scoring across the asset population |
| POST | /v1/interventions/rank | Rank interventions against a stated budget and objective |
| POST | /v1/scenarios | Compare budget levels, strategies or climate projections |
| GET | /v1/regions/{id}/summary | Aggregate risk and intervention need by region |
Request and response
illustrativeRequest
{
"asset_class": "distribution_transformer",
"assets": [
{ "asset_id": "tx_118204", "installed": "1987-06", "rating_kva": 500,
"location": { "lat": 53.0124, "lon": -2.1788, "elevation_m": 68 },
"load_factor_mean": 0.61, "last_condition_assessment": "2022-04",
"condition_grade": 3 }
],
"horizons_years": [1, 5, 10],
"weather": { "include": ["flood", "thermal"], "climate_scenario": "baseline" },
"consequence": { "customers_downstream": 412, "includes_critical_load": true }
}Response
{
"asset_class": "distribution_transformer",
"scored_at": "2026-10-21T16:34:00Z",
"assets": [
{
"asset_id": "tx_118204",
"condition_score": 34,
"condition_band": "poor",
"failure_probability": [
{ "horizon_years": 1, "probability": 0.021, "ci": [0.011, 0.038] },
{ "horizon_years": 5, "probability": 0.142, "ci": [0.088, 0.221] },
{ "horizon_years": 10, "probability": 0.361, "ci": [0.241, 0.498] }
],
"drivers": [
{ "driver": "age_39y_vs_class_median_28y", "effect": 0.38 },
{ "driver": "thermal_duty_high_load_factor", "effect": 0.24 },
{ "driver": "condition_assessment_grade_3", "effect": 0.21 },
{ "driver": "flood_exposure_1in100", "effect": 0.11 }
],
"consequence": { "customers_affected": 412, "critical_load": true,
"estimated_penalty_exposure": "high" },
"risk_rank_in_class": 142,
"evidence_basis": {
"failure_records_in_class": 2184,
"condition_assessment_age_years": 4.5,
"basis": "statistical_with_physical_prior"
},
"recommendation": { "action": "condition_reassessment",
"window": "within 12 months" }
}
],
"class_note": "Transformer failure records are dense. Pole and switchgear classes are ranked on physical models with sparser validation."
}Where the data comes from
| Your asset register | Installation dates, ratings, materials, locations and configuration — the foundation, and often less complete than assumed |
| Condition assessment records | Inspection and test results, typically covering a sampled subset rather than the whole population |
| Outage and failure records | Historical failures with asset attribution where it exists; the attribution quality varies sharply by asset class |
| Load and operational data | Loading history and duty, which drive thermal ageing in a way installation date cannot capture |
| Weather and climate data | Historical observations and published climate projections, used for exposure and scenario analysis |
| Terrain, soil and flood mapping | Elevation, soil corrosivity and flood extent, which explain much of the variation between identically-aged assets |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Hybrid modelling by asset class: physical deterioration models where the mechanism is well understood, survival statistics where failure records support them, and the basis stated per class rather than hidden
- Thermal ageing models for transformers driven by loading history, which separates two identically-aged units with different duty
- Weather exposure computed at asset location from terrain, elevation and historical event data rather than applied as a regional average
- Condition assessment ageing, since a four-year-old inspection grade is weaker evidence than a recent one and should be weighted accordingly
- Consequence modelling from network topology, so customers affected reflects actual downstream connectivity rather than a nominal count
- Intervention ranking as constrained optimisation against budget, crew capacity and outage windows, not just a sorted risk list
- Validation on held-out failure history per class, with the uncomfortable result reported where a class cannot be predicted better than age alone
- Register data quality reporting, because missing installation dates and wrong locations are endemic and they limit everything downstream
What it changes for the business
Budget allocated on evidence
Ranking by probability and consequence replaces age-based replacement with something defensible to a regulator.
Inspection effort targeted
Assets whose risk is uncertain rather than high get reassessed first, which is where inspection money earns most.
Climate scenarios quantified
Exposure scoring under projections turns adaptation planning into numbers rather than narrative.
Register gaps exposed
Data quality reporting surfaces the missing asset information that silently caps every other analysis.
How it fits into your product
How it embeds
- Asset register ingestion from your asset management system or GIS, on a schedule
- Risk scores written back against the asset record for use in existing planning screens
- Intervention rankings exported as candidate work programmes for your planning cycle
- Scenario endpoints for budget cases, strategy comparison and regulatory submissions
- On-premise deployment, which is usual where network and topology data cannot leave
- Geographic and regional scoping for operators planning by district or licence area
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How well can you predict an individual asset failure?
Not well, and that is not the right question to design around. Individual failure of a transformer or a pole is close to a random event conditioned on degraded state. What these models do reliably is rank a population, so that the worst few thousand of several hundred thousand are identified for intervention. Over a population the expected failure counts are reasonably calibrated. For a single named asset the honest output is a probability with a wide interval, which is what the API returns.
What if our failure records have poor asset attribution?
Then statistical modelling is limited for the affected classes, and we would say which ones. Transformers and cables often have dense attributable records. Poles, joints and switchgear frequently do not, because an outage gets recorded against a feeder rather than a component. For those classes we lean on physical deterioration models with engineering priors and report the weaker validation explicitly, rather than presenting a statistically-validated-looking score that is not.
Can this support a regulatory submission?
It can supply the analysis and the audit trail — inputs, method, validation results and the ranking logic, reproducible later. Whether a particular regulator accepts a given methodology is a matter between you and them, and we would build to whatever they have specified rather than assume our approach qualifies.
How much does the asset register need to be cleaned first?
More than most operators expect. Missing installation dates, wrong coordinates and assets that were replaced without the record being updated are endemic, and they cap the achievable accuracy regardless of modelling. We measure register quality during discovery and report it as a finding. Sometimes the honest first project is register remediation, and we would rather say that than build a ranking on top of unreliable data.
Do the climate projections make long-horizon numbers reliable?
They make them scenario-conditional, which is different from reliable. A ten-year exposure figure under a published projection is a useful planning input and carries real model uncertainty on top of the asset uncertainty. We return scenarios separately rather than blending them into one number, so a planner can see how much of the answer depends on which projection was chosen.
Related blueprints
Predictive Maintenance API
Failure probabilities, anomaly scores and maintenance recommendations for industrial equipment, served to your CMMS or plant software.
Carbon Reporting Intelligence API
Emissions calculations, supplier-level estimates and audit-ready reporting inputs for manufacturers with disclosure obligations.
Industrial Parts Matching API
Cross-references equivalent components across manufacturers using part numbers, dimensions and technical specifications.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.