Maximo Predict, one full example: from a Jupyter notebook to a predicted failure date

1. What Predict is, in one picture

Predict has almost no screen of its own. It is a small API server plus a Python library, and it borrows everything else from its neighbours.

2. Where Predict keeps its data

A fair question when you first see a table called MAS_INSTDB2_PREDICT.PMITENANT: does Predict have its own database? On this system, no. It has its own schemas inside the same Db2 database that Manage and Monitor use. Predict was bound to the suite's system JDBC configuration at install time, so it landed next to them.

3. Before the first cell: three fixes

Predict creates a Watson Studio project with IBM's notebooks, sample CSV files and a README. Three things in it did not match the system.

3.1 The runtime must be Python 3.12

The README says Python 3.10. The default notebook environment is 3.11. The library ships a compiled part built for 3.12, so on anything else the install fails:

Create an environment template on Runtime 25.1 on Python 3.12 (Manage › Environments › Templates › New template; 4 vCPU and 16 GB is enough), then give it to each notebook from the project's Assets list: row menu › Change environment. The runtime must be stopped first.

3.2 Tell the notebook where Monitor is

The notebooks read the Monitor address from an environment variable that nothing sets, and stop with a TypeError a few cells later. Add one cell before the cell that reads Predict_Envs.json:

import os
os.environ['API_BASEURL'] = 'https://<workspace>.api.monitor.<instance>.<cluster domain>'

3.3 Put pmlib.zip in the project

The project lists a data asset called pmlib.zip, but the file behind it was missing. Download it once from the Predict API into the project's data folder (196 MB); every notebook then installs from the local copy:

!curl -sk -o /project_data/data_asset/pmlib.zip \
  "${APM_API_BASEURL}/ibm/pmi/service/rest/ds/${APM_ID}/${APM_API_KEY}/lib/download?filename=pmlib"

The last prerequisite is the file Predict_Envs.json: three values (APM_ID, APM_API_BASEURL, APM_API_KEY) that you copy from Health and Predict and save in the project.

4. Step 1: load the sample data

Notebook: FastStart2021Loader-New. It runs 46 cells and builds the whole scenario.

The sample data is from 2008 onwards. The loader shifts every date forward so the history ends near today; here the shift was 6,553 days and the readings ended on 3 August 2026.

5. Step 2: train the model

Notebook: PMI - Predicted Failure Date. The cell that matters describes the model in one Python dictionary: which readings to use, how to summarise them, and what to predict.

group = TimeToFailureAssetGroupPipeline(
    asset_group_id=asset_group_id,                      # NEW_AFMGRP
    model_pipeline={
        "features": ['Pump_AFM:velocityx', 'Pump_AFM:velocityy', 'Pump_AFM:velocityz'],
        "features_resampled": {'Pump_AFM': {'${freqency}': '1D',
            'velocityx': {'mean': None}, 'velocityy': {'mean': None}, 'velocityz': {'mean': None}}},
        "predictions": ['predicted_time_to_failure', 'predicted_failure_date'],
    })
df = group.execute()

In plain words: take the three vibration readings, average them per day, join them with each pump's installation and failure dates, and learn how long a pump with that vibration pattern has left. Training took about one minute.

df now holds 1,186 predictions: one per pump per day.

6. Step 3: register and schedule

model_instance_id = group.register()
group.enable(enabled=True, schedule={"starting_at": "05:00:01", "every": "5min"})

register() stores the model files in Watson Machine Learning, writes one row in Predict's MODEL_TEMPLATE and one in ASSET_GROUP_MODEL_INSTANCE, and creates the two output items in Monitor. enable() asks Monitor to run the model on a schedule.

The model is then visible in Manage under Health and Predict › Prediction settings:

7. Step 4: get the scores

This is where the run stopped being smooth. register() is meant to save the first predictions to Monitor. It reported success and saved nothing: both result tables had zero rows. The cause is problem 5 in the log below. With a two-line patch in the notebook, the write went through:

from pmlib import api as _api
_t = _api.get_new_monitor_table_name_for_prediction_result
_api.get_new_monitor_table_name_for_prediction_result = lambda db, name, cols: _t(db, asset_group_id, cols)
group._write(df)

The database confirms it: 2,372 rows in each of the two result tables in Monitor's schema (1,186 timestamps × 2 outputs; one table for the raw output, one for the daily summary). The latest score for each pump:

select ENTITY_ID, KEY, VALUE_N, VALUE_T, TIMESTAMP
from WSP_MAM.DM_DEVICE_TYPE_NEW_AFMGRP_3_0L
where KEY in ('predicted_time_to_failure', 'predicted_failure_date')
order by ENTITY_ID, TIMESTAMP desc;

Monitor result tables are tall: one row per asset, timestamp and output name, with the value in VALUE_N (number) or VALUE_T (date).

8. Step 5: what Health and Predict shows

The honest state at the end of this run:

So on this build the example gets from a notebook to scores in the database, and stops one step short of the card a reliability engineer would look at. I am publishing it at that point on purpose: the last two rows are product defects, confirmed in the logs and in the library source, and they belong in a support case rather than in more workarounds.

9. The field log: seven problems, in order

Problem 4 in detail: a restored database remembers its old home

Predict integrates with Monitor once, stores the result in PMITENANT, and marks it COMPLETE. A background job looks only for rows marked PENDING. After a restore from another environment, the row is complete and wrong. Predict's own log says what to do (it suggests changing the status to PENDING). Take a copy first:

create table CRBKP.PREDICT_PMITENANT_BAK as (select * from MAS_INSTDB2_PREDICT.PMITENANT) with data;
update MAS_INSTDB2_PREDICT.PMITENANT set MAS_INTG_STATUS = 'PENDING' where PMI_TENANT_ID = 1;

Within half a minute the row carried this cluster's Monitor address and was back to COMPLETE.

How I confirmed problems 5 and 6

Both are in the library you already downloaded. Unzip pmlib.zip and read pmlib/persist.py (the split on "_") and pmlib/pipeline.py (search for "when resampling is used"). For problem 6, the log of the failed job pod in the Monitor namespace ends with the same sentence. Reading the source took ten minutes and saved guessing.

10. A checklist for your own run

1. Monitor, Health and Predict are active, and Predict's PMITENANT row shows your Monitor address.
2. The notebook environment is Runtime 25.1 / Python 3.12.
3. Predict_Envs.json and pmlib.zip are both in the project's data assets.
4. The cell that sets API_BASEURL is in each notebook.
5. Run the loader notebook fully before any model notebook.
6. After register(), count the rows in the group's DM_DEVICE_TYPE_… tables. Zero means the first write failed silently.
7. After enable(), look at the newest <workspace>.g1.… job pod in the Monitor namespace. Its log tells you in one line whether scoring ran.
8. Keep the API key out of notebook output, and rotate it when you finish.

Written from a single run on a demo system on 3 October 2026. Versions and behaviour may differ on your build; the defects described here are as observed with pmlib 9.2.6.dev10800 and are not official IBM statements.