Condition-based work for the maintenance system you already run
MaximaLabs finds what is degrading, why, and what it is worth. Limble, Maximo or SAP PM decides who goes and when. The request carries the evidence — and the completed job comes back as value measured on the plant.
Limble · IBM Maximo · SAP S/4HANA PM — no rip and replace
Three directions, one loop
Most analytics stop at a dashboard someone has to remember to read. This ends in a work order — and keeps going until the plant shows whether the work paid.
1 · A finding becomes a work request
An exchanger past its economic cleaning interval, a remaining-life estimate heading for its limit, a sticking control valve, a monitor in alert: each is raised in your maintenance system on the asset id it already uses, with the evidence, the due date, the priority, the value and a link back to the analysis. A person raises it, after seeing the exact request.
2 · The work comes back as measured value
Every half hour the open requests are read back: status, dates, problem–cause–remedy codes, cost and labour. When the work is done, the analysis that raised it re-runs on fresh plant data and the value ledger shows what the plant actually got — beside what was predicted and what the work cost.
3 · Your work history becomes training data
Closed corrective work on the mapped assets becomes failure events, and the plant data before each is labelled pre-failure, normal or excluded. That labelled corpus is what a supervised failure model needs — and it already lives in your maintenance system, nowhere else.
What becomes work, and when it is due
Each source sets the due date, the value and the indicator the work is checked against from its own analysis — not from a fixed interval.
Exchanger fouling
Due when cleaning starts to pay (the cycle-cost optimum); valued at what the fouling costs per day at today's resistance; verified on the fouling resistance after the cleaning.
Remaining useful life
Due at the early end of the forecast range (P10), not its median — planned to the date it could reach the limit; verified on the indicator against its level after the last reset.
Control loops
A loop the screen flags — suspected valve stiction, saturation, manual — raised for the valve or the tuning; verified on the loop's control error after the work.
Performance monitors
A monitor in alert, valued at its annualized loss against target; verified on the gap to target over the periods after the work.
A worked example: one cleaning, measured
On the demonstration's E-102 feed/concentrate interchanger, with a Maximo work order standing in for the site's.
- The finding. The fouling check puts E-102 past the point where cleaning pays, costing about $227 a day at today's fouling resistance — $83k a year if left.
- The request. A work order on the site's asset, due on the date the cleaning optimum gives, with the fouling resistance, the economics and a link back to the check in its description.
- The work. Maintenance cleans the bundle and closes the order: problem FOUL, remedy chemical clean, $3,100.
- The measurement. The fouling check re-runs on the fresh data: fouling resistance falls from 7.3×10⁻⁴ to 1.8×10⁻⁴ m²K/W over the two weeks either side — 75 % of the gap to clean closed, so $62k a year realized of the $83k predicted, against $3,100 of work.
Numbers from the solver-generated demonstration record, produced by the same code your workspace runs. Illustrative prices.
Supported maintenance systems
Field names follow each vendor's published defaults; a customised instance overrides any of them in its configuration.
| System | Interface | What is sent and read back |
|---|---|---|
| Limble | REST v2 · tasks | Basic authentication with the client id and secret; the task carries the asset, location, priority and due date. |
| IBM Maximo | OSLC / REST · mxapiwo | API key header; a work order on the site and asset, with the evidence in the long description and the failure report read back. |
| SAP S/4HANA PM | OData · API_MAINTNOTIFICATION | A maintenance notification on the technical object; the CSRF token and session are fetched before every write, as the service requires. |
Why not just another CMMS?
Because yours already holds what matters: the asset register, years of work history, and the link to purchasing and finance. Replacing it would cost a site more than any insight is worth. Adding evidence to it costs nothing it already has.
A person decides what becomes work
Raising a request needs a workspace owner or admin, after a preview of the exact vendor request. The AI agent has no tool that raises one.
No credential is stored
The configuration names a server environment variable that the operator binds to the workspace. The key is read at the moment of the call; responses, the database and the audit trail carry only its name.
One guarded way out
Every call goes through the same network guard as the historian connectors: no internal addresses, no redirects, capped responses, and errors reduced to a status.
Nothing invented
Where a vendor does not carry a figure on the record that is read — SAP keeps cost on the order, not the notification — it is shown as missing, not estimated. Work that did not move the indicator realizes nothing, and says so.
Every request links back to the analysis that raised it.
Frequently asked questions
Is MaximaLabs a CMMS?
No, and it is not trying to become one. Your maintenance system runs the work — scheduling, technicians, parts, purchasing and the history behind them. MaximaLabs works out what is degrading, when it will matter and what it is worth, and sends that to the system you already run as a work request.
Which maintenance systems are supported?
Limble (REST v2), IBM Maximo (the mxapiwo object structure) and SAP S/4HANA Plant Maintenance (the API_MAINTNOTIFICATION OData service). Each adapter uses the vendor's published field names by default; a site whose instance is customised overrides a field name in its configuration rather than waiting for a code change.
How is the value of a completed job measured?
The analysis that raised the request is re-run on plant data after the work. The indicator it was raised on — fouling resistance, a gap to target, a control error — is compared over the two weeks before the request and the two weeks after completion. The share of the gap to healthy that the work closed scales the predicted value into the realized one.
What does the work-history import do?
It reads closed work on the assets you have mapped, keeps the corrective work (a failure being fixed, not planned maintenance), and turns it into failure events with their problem, cause and remedy codes. Plant data is then labelled per timestamp: the days before each failure as pre-failure, the repair and restart as excluded, the rest as normal.
Can the AI agent raise work orders on its own?
No. Raising a request is a route a workspace owner or admin calls, after a preview. The agent can point at a finding; a person decides it becomes work.
Where does the credential live?
In the server's environment, set by whoever runs the deployment, and bound to the workspaces allowed to use it. The workspace configuration only names it, so it never appears in a response, the database or the audit trail.