Inspiration
Cities already collect thousands of maintenance work orders, but important patterns can easily get buried inside years of records and crew notes.
We were inspired by a simple idea: cities may already have the information they need to spot repeated maintenance problems — they just need a better way to find and use it.
Our goal was to turn that hidden maintenance history into something useful for maintenance teams: a smaller, evidence-based list of cases that may need attention before the same problem happens again.
What it does
Our project looks through work-order history to identify possible recurring maintenance problems.
Instead of asking a manager to search through thousands of records, our workflow narrows the data down to a smaller group of high-priority cases.
Our process follows four main steps:
Detect → Validate → Explain → Act
We also keep the original work orders connected to every result, so the evidence can always be checked.
AI is used only after a case has already been identified. It helps summarize and explain the supporting evidence, but it does not decide whether a problem is recurring.
How we built it
We started by cleaning and organizing the work-order data.
Then, we grouped work orders by asset and time and searched the maintenance notes for signs of:
- problems or failures,
- repair activity,
- and language showing that an issue had happened before.
We also added extra checks for broad asset identifiers and cases where the evidence was too weak.
Another important part of our process was testing different time windows for grouping related work orders. We used 180 days for our main analysis, but we treated it as an assumption rather than a perfect rule.
After our checks, we had 195 qualified candidates.
We then used human review to improve the ranking and applied a provisional threshold of 0.680.
Only 11 cases, or about 5.6%, stood out as high-priority cases for further review.
Challenges we ran into
One of our biggest challenges was that real maintenance data can be messy.
Work-order notes are written in different ways, some records contain very little detail, and some asset identifiers are broad enough to combine unrelated work.
We also learned that simply counting repairs can be misleading. An asset can have several work orders without actually having the same problem happen again.
Another challenge was deciding how to group work orders over time. Different time windows can change the results, which is why we do not treat our 180-day setting as a perfect rule.
We also had to be careful not to make claims that the data could not support. Our goal was to separate what the records actually showed from what we might only assume.
Accomplishments that we're proud of
We are proud that our project does more than simply count work orders.
We built a workflow that:
- keeps the original evidence connected to every result,
- uses human review to improve the ranking,
- separates observed facts from possible explanations,
- reduces a large candidate list into a smaller group that managers can actually review,
- and uses AI to support human decisions instead of replacing them.
We narrowed 195 qualified candidates down to 11 high-priority cases, helping managers focus on the cases that stand out the most.
We are also proud that when we found weaknesses in our first approach, we did not ignore them. We used what we learned to improve the project.
Example Evidence
One high-priority case, ADDRESSES|22356, included six work orders over about 190 days.
WorkOrder IDs: 103252, 107679, 110286, 111025, 114388, and 114954.
Observation: The work-order history shows repeated water-service repairs and meter changes. One note stated that the “line stopped up again,” which gave us direct evidence that the issue had happened before.
Hypothesis / Next Action: The records do not prove the exact root cause. Instead of guessing, we recommend that the maintenance team inspect the water-service line and related components before another reactive repair is needed.
This is an important part of our approach: we use the records to support what we know, and we clearly separate that from what still needs to be investigated.
What we learned
One of the biggest things we learned was that more repairs do not always mean the same problem is repeating.
We prepared 50 cases for review and manually checked 10 using the real work-order records.
Out of those 10 cases, 3 showed a repeated pattern and 7 did not.
This was one of the most useful parts of the project because it showed us that repair activity alone was not enough.
The cases we confirmed had clearer language showing that the problem had happened before. Because of that, we changed our ranking to give more importance to that type of evidence.
After the change, the three confirmed cases ranked higher than all seven rejected cases in our small review sample.
We also learned that data quality matters just as much as the model or scoring method. Broad asset names, incomplete notes, and weak evidence can make a case look more important than it really is.
Most importantly, we learned that AI works best when it is supported by real evidence and human judgment.
AI can help make information easier to understand, but the original work orders and human review still matter.
Limitations
Our project is an exploratory decision-support workflow, not a finished production system.
Some important limitations are:
- work-order notes can be incomplete or inconsistent,
- the 180-day episode window is an assumption,
- only 10 cases were manually reviewed,
- the 0.680 threshold is provisional,
- broad asset identifiers still require caution,
- and the detector score should not be treated as the probability that an asset will fail.
Because our human-review sample was small, we do not claim that our system is 100% accurate.
More expert-reviewed data would be needed before using the workflow in a real production environment.
What's next for Iconic Pair
If we continued this project, our next step would be to work with maintenance experts and review a much larger set of cases.
We would also like to:
- create different settings for different asset types,
- improve the maintenance-language rules,
- add information such as cost, safety, and asset condition,
- test the workflow on a larger expert-reviewed dataset,
- track whether preventive action actually reduces future work orders,
- and continue improving the AI summary process while keeping it connected to the original evidence.
Our goal is not to replace maintenance experts or claim that AI can predict every failure.
Our goal is to help maintenance teams find repeated problems earlier, verify the real evidence, and make better preventive-maintenance decisions.
Log in or sign up for Devpost to join the conversation.