Can an AI decision model triage Australia's ageing power poles?

With the advent of AI decision model Jev in September 2026, the world rushed to identify use cases for a model that could only choose between a set of options you gave it. Common use cases: approving or escalating maintenance work orders, scoring sales leads from 0 to 100, sorting customer complaints by urgency, flagging freight invoices that don't match the contract. But we immediately at Beyond Data saw the potential to evolve our decision systems with Jev by providing fast, cost-efficient, and risk-weighted AI-generated decisions for the everyday decisions that are made at high volume.

Our clients and partners regularly speak to us about the tidal wave of maintenance costs coming for the utility sector as the poles are aging rapidly. It's not financially feasible to perform repairs on the entire asset portfolio every year. This creates a complex problem, but nonetheless a data problem: to identify which poles should be replaced, which should be maintained, which ones can have maintenance deferred, and which ones require a closer look by an engineer.

This assessment is unique because there are millions of power poles and the condition of them has criteria which can be interpreted subjectively by humans. We saw this as a perfect opportunity to test but also showcase the power of Jev models. Given that the state of Australia's energy infrastructure is sensitive data and may have important national implications, we opted to use Australia's very own Maincode Matilda Jev model (to keep the data in Australia and because their Jev model topped the Jev Decision Index). We ran it in an Australian data centre.

The below video demonstrates the prototype we built. The prototype we built analyses real pole photos, real inspection records and pole locations from public datasets, but we've paired them together synthetically for the purpose of the demo.

How it works

We collated a dataset of images of power poles as well as the known asset data (such as its location, bushfire risk, number of customers served, its age, and its maintenance history: three inspections of shell thickness and ground-line wood ten years apart, and how long it's been since it was last serviced). We collated all of this data together to create one single record per pole. We then passed the image of the pole into the Matilda Jev model and had it provide an assessment of the following attributes:

• Lean: straight, leaning, or cannot assess
• Crossarm: straight, tilted, or not visible
• Vegetation near the wires: clear, encroaching, or not visible
• Overall visible condition: critical, poor, fair, good, or as new

A decision model doesn't write any text. It returns a probability for every option you give it, in one pass, which is why it is so fast and cheap to run. Reading a photo took about half a second (547 milliseconds, median).

This is the raw output for the pole in the screenshot further down, trimmed to the probabilities. The first block is the photo read. The second is the decision step described next. Health is scored from 0 (critical) to 4 (as new).

// 1. Reading the photo (539 ms)
{
  "lean":       { "straight": 0.6223, "leaning": 0.1310, "cannot_assess": 0.2467 },
  "crossarm":   { "straight": 0.5775, "tilted": 0.4107, "not_visible": 0.0117 },
  "vegetation": { "clear": 0.8122, "encroaching": 0.1795, "not_visible": 0.0083 },
  "health":     { "0": 0.0051, "1": 0.0282, "2": 0.4109, "3": 0.5504, "4": 0.0054 }
}

// 2. The decision, with the asset record and the policy (546 ms)
{
  "action":          { "replace": 0.7182, "maintain": 0.1306, "defer": 0.0205, "reinspect": 0.1306 },
  "safety_risk_now": 0.8584
}

These attributes, the photo and the pole's record were then passed back into Matilda Jev together with our maintenance policy, written in plain English: public safety first, a lower threshold to act for poles in high bushfire zones or supplying a critical customer such as a hospital, and defer only when a pole is safe to leave until its next inspection. The model recommended one action for each pole, replace, maintain, defer or reinspect, along with the probability that the pole is a public safety risk. Because the policy is plain text in the request, a network can change what the model weighs by editing a paragraph, without needing a data scientist to spend months retraining it.

In the example above, the photo shows a straight pole in good condition, but the model still recommends replacing it. The inspection record shows the pole is 93 years old and its shell has thinned by 21% in ten years, and the policy puts more weight on that than on how the pole looks. The demo's Flip view tests this by pairing the same photo with two different inspection records, and the model makes a different decision for each one.

As you can see the model operates extremely quickly and is extremely cost-efficient, allowing it to be used at scale across millions of poles within a state or national network. Each pole took 1.1 seconds (1,096 milliseconds) of model time, photo read and decision together. That is about 3,285 poles an hour on a single GPU, at USD 0.48 (AUD 0.74) per 1,000 poles in GPU time, or roughly USD 480 for a million poles.

When the model isn't sure, an engineer decides

We didn't want the model deciding every pole. When Matilda Jev's top recommendation was less than 60% confident, when it couldn't assess the lean from the photo, or when it asked for a reinspection, the pole went to an engineer work queue instead of being decided automatically. 130 of the 400 poles went to the queue, and the other 270 were decided by the model.

The queue is sorted lowest confidence first, so an engineer starts with the poles the model was least sure about. Each card shows the photo, the action the model leaned towards, its confidence, and why the pole was held back. The engineers' time goes on the third of poles that need their judgement, rather than on every pole in the network.

The 60% line only works if the model's confidence means something. On vegetation, the gap between how confident the model was and how often it was right averaged about 2 percentage points.

How accurate is it?

We ran Matilda Jev as a completely vanilla installation. It was not trained on power poles and was not given any specific instructions beyond each question and its options. Scored against the field labels that come with the photos, it read lean correctly 82.9% of the time, vegetation 70.2% and the crossarm 68.1%. From the inspection record alone, it matched the inspector's own five-level condition rating 69% of the time.

There are many ways we could improve that accuracy: training the model on a network's own labelled photos, refining the questions and options, giving it photos of each pole from more than one angle, and setting the confidence threshold against decisions engineers have already made. The photos in this prototype are mostly of concrete poles in India, while much of Australia's ageing fleet is timber, so a production version would start from the network's own photos and records.

We believe this is just the start for decision models in asset heavy critical industries. An automated analysis like this could feed automatically into a maintenance crew scheduling tool, which batches crew assignments and optimises to minimise travel time and downtime risk. If you would like to explore the possibilities of how an AI decision model could optimise the high volume decisions in your business, we'd love to hear from you.

Will Turner