Issue intelligence is the application of machine learning to the commissioning issue log: a risk score on every open issue, a predicted close date, silence detection, duplicate clustering by meaning, and recalled fixes from similar past issues. The model reads and points. People judge, decide and close.
On a commissioning project, the issue log is the only honest scoreboard you have. The schedule can say one thing and the slide deck another, but the issue log records what actually broke, who found it, and what it took to fix. A good engineer reads the list and feels the project long before any report tells them how it is going. The problem is not that the list is wrong. The problem is that it gets written once and then read almost never. Thousands of issues get raised on a single build, every one eventually closed by a person who diagnosed it, fixed it, and wrote down what happened. That person moves on, the entry goes cold, and all of that hard-won experience sits in a database teaching nobody. Every project keeps this record under a different name, the issues log, the punch list in the US, the snag list in the UK, the deficiency or observation log in commissioning specs, but it is the same list, and everything here applies to all of them.
So we asked a simple question: what if the list could be read the way a twenty-five year veteran reads it, on every issue, every day, at machine scale? We call the answer issue intelligence. It is not a replacement for the people who run the site. It is a way to give their attention somewhere useful to point.
What we trained, and how honestly
The models behind this are not a language model asked for an opinion. They are gradient-boosted trees trained on more than 130,000 closed commissioning issues from real data center programs, each issue replayed at several ages so the model learns how risk evolves over an issue's life. Each issue is read three ways at once: the text of the description through a sentence encoder, the context around it such as equipment, level, discipline and who is assigned, and the quiet signals of age and activity over time.
One methodological point matters more than any capability claim. We validate leave-project-out: the model is always tested on projects it has never seen. A random shuffle of the same data inflates the headline metric dramatically, because the model learns to recognise projects instead of issues, and we reject that number on principle. Held out honestly, the model's top-ranked issues are about 1.5 times more likely to close slow than the baseline, and its read sharpens as an issue ages. That is not an oracle. It is a triage lens that never gets tired, and it is measured the hard way.
From that training, five capabilities fall out.
1. Risk, scored on every open issue
Every open issue gets a single number: the learned probability that it will take more than 30 days to close. Not a category, a probability, recomputed as the issue ages. A missing label on an isolation valve reads low. A points mapping error buried in a BMS graphic, the kind that looks cosmetic and behaves like a landmine, reads high. Above 0.70 the module calls it high risk: chase now. The list stops being a gut call at six in the evening and starts ranking itself.
Risk ranking · open issuesFig. 1. The same three issues a human would eventually rank correctly, ranked instantly, on all of them at once.
One training result surprised even us: the strongest signal is what the description says, not the priority label a person attached. Priorities record what somebody believed on the day the issue was raised. The description records what the issue actually is.
2. A predicted close date, not a hoped-for one
A second model predicts how long each issue will take to close, as a range rather than a point, learned from how similar issues actually behaved rather than from what anyone promised. That changes the conversation before an integrated test. When a transfer timing issue is forecast to clear in three to four weeks and your Level 5 window opens in six, you can breathe. When the next one is forecast to run past the window, you know weeks early, while there is still time to move people or move the date.
Fig. 2. This one clears the window. The point is that you know that now, in advance, instead of finding out during the test.
3. It hears the silence
Of everything the model reads, one of the strongest warnings of a slow close is the simplest: the issue went quiet. In our training corpus, issues that were still silent a week after being raised went on to close slow 66 percent of the time. Issues with activity by day seven closed slow 43 percent of the time. The same issue, scored on the day it was raised, might read 0.58. A week later with three comments it drops toward 0.51. A week later with none it climbs to 0.74 and turns red. Veterans call this a feeling in their gut. The model calls it a feature in the data. Both are right, and now the feeling has a number attached to it.
Fig. 3. Activity stops. Risk does not. The gap between the two is the early warning.
4. The same problem, written three different ways
The model reads meaning rather than matching text, so it catches duplicates that a keyword search will always miss. One engineer writes drain pan overflow, another writes condensate backing up, a third writes water at CRAH base. To a search box those are three unrelated tickets. To the model they are one problem logged three times and fixed once, which means two of those three fixes were wasted effort chasing a ghost. And when a cluster of near-identical issues sits on the same equipment type, the module flags it as systemic, because a defect that recurs is not a quick known-fix item. In our corpus, recurring issues took roughly twice as long to close as their one-off peers. The technique has proof outside construction too: a 2022 Amazon study applied text similarity to equipment commissioning audit checklists across its warehouse network and found 17 percent of the checks were duplicates or near-duplicates.
Fig. 4. String matching sees three tickets. Meaning matching sees one weak system, which is the thing worth fixing.
5. What fixed it last time, handed to you today
When a new issue lands, the system searches every closed issue for its nearest relatives and surfaces how they were actually resolved, the lesson rather than just the paperwork. A generator failing to reach rated voltage on a load step today looks a lot like two issues that closed quickly last quarter. One was an AVR sensing fuse, the other a governor droop setting. So instead of a blank page, the engineer starts with a suggested first move: check the AVR sensing circuit before you replace any hardware, because two prior issues closed exactly that way. The newest person on site gets the oldest engineer's memory, on day one.
Fig. 5. The model does not decide the fix. It hands the engineer the two most relevant memories and lets them decide.
The anatomy of a slow-close issue
Put those five signals together and a pattern appears that every commissioning manager will recognise. Long-stay issues almost never announce themselves. They start looking exactly like the ones that close fast, and then they quietly slide through four stages while nobody is watching the slide. Issue intelligence exists to catch the slide at stage two, not stage four.
Fig. 6. The gap between the green line and the red line is roughly two weeks of warning that used to go unused.
Stage one is healthy. The issue is active, the owner is posting, and the model leaves it alone. Stage two is where the story is decided, because the updates thin out and the owner drifts to louder problems, yet nothing on the dashboard has turned red. Stage three is the silence we described earlier, days of no activity while the risk score climbs. By stage four the issue is a long-stay, it is past its forecast, and it has become a threat to the integrated test window. A person usually catches it at stage three or four. The model catches it at stage two, which is the difference between moving an owner and moving a date.
Two more patterns from the corpus are worth naming, because they cut against instinct. First, the issues caught earliest are often closed latest: factory and delivery snags logged at Level 1 lingered around six times longer than pre-functional issues, parked behind vendor returns while the project looked forward. Second, an issue nobody classified is an issue nobody owns. In the training corpus, issues raised with no priority set took more than twice the median time to close. Data hygiene is a leading indicator, not paperwork.
Why generic construction AI misses commissioning
Machine learning on construction issues is not new. Autodesk reported back in 2019 that its Construction IQ models had learned from more than 150 million construction issues and checklist observations across nearly 30,000 projects, and tools like it have been flagging risky subcontractors and unsafe conditions ever since. If your project runs on a large construction platform, some issue intelligence already exists around it.
Look at what those models mean by high risk, though: the risk of a fall, a water hazard, a pending safety inspection, an overdue action item. Commissioning issues fail differently. They live at the integration points, a transfer timing issue on an ATS, a points mapping error between a BMS and its graphics, a witness test that cannot be rescheduled without moving three trades, and their cost is not measured in jobsite incidents but in a date: the integrated systems test window the whole program converges on. A model trained on general construction issues has never seen that failure mode. Issue intelligence for commissioning has to be trained on commissioning issues, which is exactly what the corpus behind this module is.
What issue intelligence cannot do
It is easy to read those five capabilities and quietly promote the model to something it is not. So we want to be plain about the edge of what it can do, because a tool that oversells itself becomes dangerous the first time someone trusts it past its range.
The model does not close issues. It does not assign blame. It does not overrule the engineer standing in the plant room with a meter in their hand. It reads patterns in what has already happened, which means it is confident exactly where it has seen enough history and blind exactly where it has not. A brand new failure mode on a first-of-its-kind system is precisely the situation where the data is thin and the human judgment matters most. The model can tell you an issue looks like trouble. It cannot tell you the site is being rewired tomorrow, that the client changed the sequence last night, or that the number in the log is simply wrong because someone was in a hurry. Context that never got written down is context the model never gets to see.
The model carries
- Reading every open issue, every day, without fatigue
- Scoring risk consistently at six in the evening and six in the morning
- Remembering how more than 130,000 past issues actually closed
- Spotting the same problem written three different ways
- Noticing the quiet issue nobody flagged
The human keeps
- Deciding what actually gets fixed, and in what order
- Judging the first-of-its-kind failure with no history behind it
- Knowing the site facts that never made it into the log
- Owning the sign-off and the accountability that comes with it
- Overruling the model when the model is wrong
Two columns, one job. Neither column is a nice-to-have.
How they augment each other
Put the two columns next to each other and the relationship stops being a competition. The model is very good at the work that punishes human attention: the endless, repetitive, never quite finished reading of a list that grows faster than anyone can keep up with. Humans are very good at exactly the work the model cannot touch: the judgment call, the site knowledge, the accountability of a signature. The failure of most tools is that they try to move the second column into the first. This one does the opposite. It clears the bookkeeping so that human attention lands where only human attention will do.
Fig. 7. The loop: the model clears the bookkeeping, the engineer spends judgment where only judgment works, and every signed closure sharpens the model's read on the issues still open.
This is the same rule behind everything we build at ODUM AI, and it is not a slogan, it is a safety design. Keep the human on the judgment and the accountability, and the model can be as capable as it likes without ever becoming a single point of failure. Move the human off that seat and even a brilliant model becomes a liability the day it meets something it has never seen.
From keeping the list to hearing what it says
Once you accept that split, the issue log changes shape. It stops being a chore you maintain and becomes an instrument you read. Every closed issue turns into a reading on the health of the program. Clusters point at the systems that keep failing. Ageing points at the owners who are stuck. Silence points at the surprises waiting for you in next month's integrated test. The list was always saying these things. Until now, nobody had the hours to listen on every line.
That is why this matters for readiness in particular. Issues are the friction between the progress that gets reported and the progress that is real. Read them well and the readiness gap becomes visible weeks before the test, while there is still time to act, instead of on the morning the test fails. The future of commissioning is not a machine that runs the project. It is a team whose attention is finally pointed at the right issues, backed by a memory of every project that came before. Issue Intelligence is an upcoming module of CxSTAT IQ: it will read the issue log where it already lives, working alongside the Cx Risk Engine's program-level view.
Frequently asked questions
What is issue intelligence in commissioning?
A machine-learning layer that reads the commissioning issue log the way an experienced engineer would. It scores the risk of a slow close on every open issue, forecasts likely close dates, detects silence and duplicates, and recalls how similar past issues were resolved. It supports commissioning issue management, it does not replace the engineer.
Can AI close commissioning issues on its own?
No. The model reads, scores and surfaces, but it does not close issues, assign blame, or overrule the person on site. It points, people decide. That boundary is the design, not a limitation waiting to be removed.
What is a slow-close issue, and why does it matter?
A slow-close, or long-stay, issue is one that takes more than 30 days to resolve, far longer than its peers. It slides through four stages: active, slowing, silent, and long-stay. Caught at the slowing stage, it costs an owner a nudge. Caught at long-stay, it costs you the integrated systems test window.
How is a risk score different from a priority label?
A priority label records what a person believed when the issue was raised. The risk score is a learned probability that the issue will close slow, recomputed as it ages. In training, the strongest signal turned out to be what the description says and how the issue behaves over time, not the priority a human attached.
How accurate is AI issue risk scoring?
Validated leave-project-out, meaning the model is always tested on projects it has never seen, the top-ranked issues are about 1.5 times more likely to close slow than the baseline, and the read sharpens as an issue ages. Random-shuffle validation inflates that metric, and ODUM AI rejects it on principle.
Does issue intelligence work with a punch list or snag list?
Yes. Issue log, punch list, snag list, deficiency list and observation log are different names for the same record: open items with a description, an owner and a status. Issue intelligence reads any of them, and risk scoring, silence detection and duplicate clustering apply the same way.
Model training corpus, silence and slow-close statistics, level and priority patterns: ODUM AI internal analysis of anonymised commissioning issue data from completed data center programs. Validation is leave-project-out. Issue examples in figures are fictional demonstration data.
Autodesk, Construction IQ digs into data to combat construction project risk, 2019. Halawa, F., Abdul, M. and Mohammed, R., Applying Machine Learning for Duplicate Detection, Throttling and Prioritization of Equipment Commissioning Audits at Fulfillment Network, Proceedings of the IISE Annual Conference and Expo, 2022.
