The TM1 Fitness Rating grades an IBM Planning Analytics (TM1) instance from A to G, the way an energy label grades a building. It is built from Pulse monitoring data and answers two questions: how well does the instance run, and how lean is the model behind it?
instance in peak shape
instance in poor shape
An energy label shows both energy use and CO2 emissions. The fitness rating works the same way: one scale for how the instance behaves today, and one for how easy the model is to look after tomorrow.
How well the instance runs day to day. This is what your planners feel: is it up, is it fast, do the overnight loads finish, is the data protected.
How lean and maintainable the model is. This is what your developers feel: how much dead code they step around, and how risky each change is.
Runtime carries more weight because it affects every user every day. Model fitness decides how quickly and safely the instance can change.
Each criterion is worth 10 points and is scored against fixed bands, so two instances measured the same way get the same score. R stands for Runtime fitness, M for Model fitness.
| Criterion | What it checks and why it matters | Full marks when |
|---|
Some extra checks are already defined for a later version: a bonus for source control with migration packages and chained chores, and a penalty for patterns such as calling an external program once per row. They are not scored yet.
Runtime points out of 60, model points out of 40. For example 24 of 60 is 40%.
The same thresholds apply to both scales.
A runtime C with a model E is rated E. The weakest side sets the rating, so it can't hide behind the stronger one.
If any red flag is active, the rating cannot be better than E.
Move the sliders to see how the two scores and a red flag combine into one letter.
Some problems put the instance or its data at risk no matter how well everything else scores. Any one of these keeps the rating at E or below until it is fixed.
The server's daily memory peak reaches 95% of its RAM. One large load or a feeder change can then stop the instance.
A night in the window has no recorded backup. Data entered that day could not be restored with certainty.
The instance was down for more than about 3.4 hours in 14 days. Planners notice that.
This sample instance is fast and almost always up, yet it is rated E. Here is how the rating was reached.
40%, a D on its own
35%, an E on its own
Memory peak 95.1% of RAM, and 6 nights without a recorded backup
The worse scale is E, and the red flags cap it at E as well
Its strengths were 100% uptime (R1, full marks) and good use of standard libraries (M1, 7 of 10). Its rating page lists each fix with who does it and the effort, and shows that the two red flags plus a small clean-up of test processes would move it to D.
Every instance has its own path, and its rating page lists the exact actions. Most instances follow a similar order: protect first, then stabilise, then tidy, then tune.
The A to G rating with both scale scores and any red flags, in the energy-label format.
The reasons behind the rating, each with the measured evidence.
All ten criteria ranked by lost points, with the main cause of each.
Actions grouped by letter, with the points each one adds, the effort, who does it and the smallest set of actions that unlocks each letter.
No. It uses Pulse monitoring information about the instance: performance figures, process runs, alerts and the object inventory. The rating reads TurboIntegrator (TI) process code and rules to find broken references, but no cube values. All checks are read-only and change nothing on the server.
Pulse monitoring the instance, ideally with at least 14 days of history and source control enabled so the full object inventory is available.
No. The rating measures how healthy and maintainable the instance is. It does not test business logic, calculations or data quality.
The rating is a snapshot of a 14-day window. Re-rate after a round of fixes, after a major release, or every quarter to track progress.
Speed is only one runtime criterion. Memory close to the limit, missing backups or a model full of broken references and dead code all carry real risk, even when users see quick response times today.
This page describes criteria version 1. Each rating page states its criteria version, so ratings are only compared on the same version.