What's New in MAS 9.x

🎯 Who this is for: IT program owners setting the nuclear roadmap — who need a grounded read on what the 9.x era actually delivers for nuclear, what the 9.2 Feature Channel means for change control, and where the product boundaries sit.

Series: Part 7 of 7 — Maximo for Nuclear on MAS 9 (Series Finale) | Read time: 17 minutes

🌐 The 9.x Era for Nuclear

Here is the framing that keeps this finale honest: most of what is "new for nuclear" in MAS 9.x is not nuclear-specific at all. Nuclear inherits the platform advances that arrived for the whole suite. That is not a knock — it is how a Manage industry solution works. Nuclear runs on the platform, so when the platform gains a capability, nuclear gains it too.

What MAS 9.0 (GA June 2024) gave nuclear

9.0 advanceWhy it matters to nuclear
Carbon Design SystemThe modern UI foundation nuclear apps render on
Role-Based Applications begin replacing Work CentersThe persona-based UI model nuclear personas inherit
Reliability Strategies with FMEA managementDirectly relevant to AP-913 maintenance-basis work (Part 4)
watsonx.ai problem-code suggestions on work ordersFaster, more consistent failure coding on nuclear WOs
Platform-stack modernization (OpenShift, containerization)Covered generically in THINK-MAS; the delivery model nuclear ships on

What MAS 9.1 (GA June 2025) added

9.1 advanceWhy it matters to nuclear
Maximo Assistant (generative AI on watsonx.ai)Embedded assistant; covered in depth in the MAS-ASSIST series
Maximo AI Service (licensed integration component)Modeled separately at 10 AppPoints (Part 1); underpins PCC/MCC/FMEA
FMEA Content BuilderAI-generated FMEA content — again relevant to AP-913 basis work
Similarity Tracker / Similar Work OrdersRecurrence detection in historical work orders
Java 17, unified left navigation, OpenID ConnectPlatform modernization nuclear inherits

<aside>

💡 Key insight: The most nuclear-relevant items in these lists are Reliability Strategies and FMEA Content Builder, because they feed the maintenance-basis and AP-913 work of Part 4. When someone asks "what does MAS 9 AI do for our reliability program?", the honest answer is precise: it accelerates FMEA failure-mode work through Reliability Strategies and FMEA Content Builder, and surfaces recurrence through Similarity Tracker. Those are real, inherited platform capabilities — not a nuclear-only feature set, and not a replacement for engineering judgment.

</aside>

One naming caution to carry forward, because analyst decks trip on it: "Maximo Assist" (legacy, discontinued) is not "Maximo Assistant" (the new 9.1 GA). The original Maximo Assist app was discontinued — remote collaboration moved to Mobile/Collaborate — and the new watsonx.ai-powered Assistant is a different thing entirely. Any deck using "Maximo Assist" against MAS 9.x is probably referring to the wrong product.

📅 The 9.2 Feature Channel Timeline

Now MAS 9.2. IBM Support lists a rolling series of Feature Channel releases through 2025–2026:

FC dropDateNotable content
September FCOct 6, 2025Baseline 9.2.0-pre.stable build
October FCOct 30, 2025OpenShift 4.19 support
November FCNov 27, 2025MongoDB v8.0 support
December FCDec 24, 2025CloudPak Data 5.2.0; component builds and fixes
AI ServiceJan 2026 Feature Channelgpt-oss-120b offered for mcc, pcc, fmea, nl2oslc; Granite 3.2 8b Instruct deprecated 25 Nov 2025
February FCFeb 26, 2026Component builds; navigator health-tile fix
March FCMar 26, 20269.2.0-pre.stable baseline

But here is the caveat that changes how a nuclear program must read all of it.

⚠️ The Feature Channel Caveat

<aside>

💡 Key insight: The MAS 9.2 Feature Channel readmes state the channel is for non-production evaluation — early access to new features, offered alongside the normally maintained streams. Note the build identifiers themselves: 9.2.0-pre.stable_{id}. That -pre is not decoration. For nuclear change control, a Feature Channel build is validation and planning input, not automatically production-entitled GA content. Treating a -pre.stable build as production evidence is exactly the kind of change-control error a nuclear program cannot afford.

</aside>

The practical instruction: in the 9.x era, "what version am I on" is a change-control question, not an IT housekeeping detail. A nuclear program needs explicit release-governance language that separates evaluation (Feature Channel), validation (your own testing), and production adoption (a maintained stream you have qualified). Do not let a Feature Channel feature list drive a production commitment without that separation.

There is a documentation nuance worth stating plainly, too: public 9.2 artifacts are primarily Feature Channel and component releases, not a single classic GA announcement letter of the AD-series kind that marked 9.0 (AD24-0483) and 9.1 (AD25-1186). No public single MAS 9.2 GA announcement letter surfaced in research. So a deck that says "MAS 9.2 GA shipped on date X" is over-stating the artifact; the honest statement is "9.2 exists as Feature Channel and component releases, with maintained streams to qualify against."

🤖 The AI Service Model Change

Of everything in the 9.2 stream, one change is called out as the most substantive AI change confirmed in IBM Support — and it touches nuclear reliability and corrective-action work directly.

In the January 2026 Feature Channel, IBM made the gpt-oss-120b model available for four AI Service model templates. IBM's wording is precise and worth quoting, because the precision matters for change control:

"You can now use the gpt-oss-120b model for mcc, pcc, fmea, and nl2oslc model templates. The nl2oslc model template is for the AI assistant. If you are already using a Granite model and need to move to gpt-oss-120b, see Changing to gpt-oss-120b models. IBM Granite 3.2 8b Instruct is deprecated as of 25 November 2025."

Three things in that sentence are easy to get wrong, and an earlier version of this post got two of them wrong:

Commonly statedWhat IBM actually documents
Granite was replaced by GPT-OSS-120B"You can now use" — gpt-oss-120b is an option, with a documented migration path. Existing Granite deployments were not force-switched
It covers three functionsFour templates: mcc (Maintenance Cause Classification), pcc (Predictive Cause-Effect Correlation), fmea, and nl2oslc — the Maximo Assistant itself
Granite is removed in February 2026IBM Granite 3.2 8b Instruct was deprecated as of 25 November 2025 — an earlier date, and deprecation rather than removal

And the detail that matters most under a validation regime: this arrived through the Feature Channel, not through 9.2.0 general availability. IBM's Software Support Lifecycle Policy for versions 9.0+ states plainly that "IBM provides non-production components exclusively through a continuous delivery (CD) stream know [sic] as Feature Channel… allowing early access for non-production environments," and the Feature Channel documentation is scoped "for nonproduction instances of Maximo Application Suite and for production instances of Maximo Application Suite as a Service."

So the honest answer to "when did the model change?" is two different dates depending on how you run MAS:

Deployment modelgpt-oss-120b usable in production from
MAS as a Service (SaaS)January 2026 — IBM operates the environment, so Feature Channel content is live
Customer-managed / self-hosted25 June 2026, at 9.2 general availability

Nearly every nuclear operator is customer-managed. If that is you, the model option reached your production-entitled stream at 9.2 GA — not in January.

Why this matters for nuclear specifically

MCC and FMEA are exactly the functions that touch corrective-action classification and reliability strategies — Part 4 and Part 5 territory. If a program uses AI-assisted cause classification or FMEA generation, the language model underneath it can now be a different one. That is not a cosmetic version bump; it is a change to the engine behind AI-assisted judgments a reliability or CAP program may lean on.

The fact that it is optional cuts both ways for a regulated operator. It means nobody moved your model without asking — but it also means you may not know which model your environment is actually running unless someone checked. Granite being deprecated rather than removed means a Granite-based deployment keeps working while sitting on a clock.

<aside>

💡 Key insight: For a nuclear operator, a model change under the cause-classification and FMEA functions is a validation-posture change, not a free upgrade. If AI-assisted MCC or FMEA output feeds a maintenance-basis or corrective-action decision, moving from Granite to gpt-oss-120b warrants revalidation of that use. Because the move is opt-in, the first question is not "when did IBM change it?" but "which model is my validated environment running right now, and did anyone migrate it?" Ask IBM in writing for the AI Service model bill of materials for the exact version you deploy.

</aside>

The discipline here is the same one Part 4 named: the AI accelerates the work, but the engineer owns the judgment — and when the engine changes, the judgment's basis must be re-checked.

🔒 What This Means for Change Control

Pull the Feature Channel caveat and the AI Service change together and you get a concrete change-control posture for a nuclear program. The core move is to separate three states that the Feature Channel deliberately blurs:

StateWhat it meansWhat you may do with it
EvaluationA Feature Channel -pre.stable buildExplore features, plan; never rely on it for a regulated decision
ValidationYour own testing of a candidate versionQualify behavior against known cases in a controlled environment
Production adoptionA maintained stream you have qualifiedDeploy; use for regulated decisions with the version recorded

Write that separation into release governance so a feature list can never jump straight from "shipped in a Feature Channel" to "in production." For any AI-assisted function used in a regulated decision, add an explicit revalidation trigger tied to component version change — because, as the AI Service transition shows, the version identifier is what tells you whether the model under your MCC or FMEA output is the one you validated.

🔧 Nuclear's Own 9.2 Stream

A common analyst claim is that "nuclear has no separate 9.2 patch stream — it just inherits MAS." That is only partly true, and the correction matters for validation planning.

IBM Support does publish a dedicated page titled "IBM Maximo for Nuclear Power 9.2: released APARs and DTs." That means Nuclear has its own APAR/DT tracking stream on 9.2, distinct from base Manage. The specific content sits behind IBM Support authentication, but the existence of a dedicated nuclear stream is public.

<aside>

💡 Key insight: This is a planning instruction, not just a trivia correction. When you scope nuclear validation for a 9.2-era deployment, pull the nuclear-specific APAR/DT stream directly — do not assume base Manage fix content covers the nuclear solution. The dedicated stream exists precisely because the nuclear industry solution has defects and fixes that base Manage does not track. Validating against only the base Manage fix list leaves a nuclear-solution-shaped gap in your qualification.

</aside>

🧩 A Worked Example: Qualifying a 9.2 Capability for Nuclear Production

Make the change-control posture concrete. A reliability program wants to use AI-assisted Maintenance Cause Classification (MCC) to help code causes in its CAP. Here is the disciplined path, using the documented facts.

  1. Recognize the state. The team sees MCC improvements in a 9.2.0-pre.stable_16717 Feature Channel build. That -pre marks it evaluation only — useful for planning, not for production reliance.
  2. Validate in a controlled environment. They run MCC against a corpus of known, already-classified conditions in a test environment and compare its classifications to the engineering-confirmed answers, measuring where it agrees and where it does not.
  3. Confirm the production component version and the model. Because gpt-oss-120b is an option for mcc while Granite 3.2 8b Instruct sits deprecated, two things must be pinned in writing: the maintained stream they intend to deploy, and which model that stream is actually configured to use. "We are on 9.2" does not answer the second question.
  4. Revalidate if the model changes. Prior validation against a Granite-based build does not transfer to gpt-oss-120b; if they migrate, they revalidate MCC behavior on the gpt-oss-120b configuration they will actually run.
  5. Pull the nuclear APAR/DT stream. They check the dedicated "Maximo for Nuclear Power 9.2: released APARs and DTs" page for any nuclear-solution defects affecting the functions in scope — not just the base Manage fix list.
  6. Record the governance decision. They document the evaluation/validation/production separation, the component version, the revalidation result, and the accountable owner — so the AI-assisted classification is defensible in an audit as a validated, version-pinned use.

<aside>

💡 Key insight: Nothing in that path forbids using MAS 9.x AI in a nuclear program — it just refuses to let a -pre.stable feature list become a production commitment by default. The model swap (Granite → GPT-OSS-120B) is the perfect illustration of why version-pinned revalidation matters: the same feature name can sit on a different model, and for a regulated decision, the model is part of what you validated.

</aside>

🧭 The Nuclear-Versus-Generation Boundary

The last clarification closes a boundary that analyst decks routinely blur: Maximo Nuclear is a separate industry solution from Maximo for Utilities and the newer Maximo Renewables.

SegmentIBM positioningPractical reading
NuclearMaximo Nuclear / Maximo for Nuclear PowerSeparate, active Manage industry solution (this series)
Conventional generation / hydroMaximo Utilities + core MAS/APM capabilitiesNo standalone "Maximo for Power Generation" SKU in public IBM docs
Renewables: wind, solar, BESSMaximo RenewablesA named APM solution for renewables assets, with Manage integration

Two facts to keep straight. First, there is no standalone "Maximo for Power Generation" industry solution in public IBM docs — conventional generation is scoped through Maximo Utilities plus core MAS/APM capabilities. Second, IBM now documents Maximo Renewables as a named APM solution for wind, solar, and battery energy storage — which is not the same as the older "Utilities-only" framing, and definitely not the same as Nuclear.

<aside>

💡 Key insight: For a nuclear program owner, the boundary is simple and worth stating in any cross-portfolio conversation: you are running an industry solution distinct from everything on the generation side. Nuclear's applications, its regulatory drivers, and its licensing posture (Premium, Part 1) are its own. Do not let a portfolio slide fold nuclear into "generation" — the whole point of this series is that nuclear is a separate, regulation-driven solution with its own answer to every question.

</aside>

⚠️ Naming Watch-outs and Edge Cases

A short catalog of the traps that surface in 9.x-era nuclear conversations:

  • "Maximo Assist" versus "Maximo Assistant." Assist is the legacy, discontinued app; Assistant is the 9.1 watsonx.ai product. A deck citing "Maximo Assist" against MAS 9.x is out of date.
  • "MAS 9.2 GA shipped on date X." There is no public single MAS 9.2 GA announcement letter; 9.2 is Feature Channel and component releases. State it that way.
  • "The Feature Channel is the production version." It is explicitly non-production evaluation (-pre.stable). Never adopt it for a regulated decision without qualifying a maintained stream.
  • "AI is a free upgrade." AI Service is a separate 10-AppPoint / 1B-token line (Part 1), and migrating a model (Granite to gpt-oss-120b) is a revalidation trigger, not a free bump.
  • "Nuclear just inherits the base Manage fix stream." Nuclear has its own dedicated 9.2 APAR/DT stream — pull it directly.
  • "Nuclear is part of the generation portfolio." It is a separate industry solution from Utilities and Renewables; do not let a portfolio view collapse it.

🏁 Where the Series Lands

Seven parts in, the nuclear picture is complete and grounded:

  • Nuclear is active and entitled — a Manage industry solution (mfnp) on Continuous Delivery, Premium-tier under part number 5737-M66, not retired and not free (Part 1).
  • Named apps carry the regulatory core — Tech Specs, Surveillance Requirements, LCO Tracking, Configuration Change Management, Condition Reports, Clearances, Purchasing (Nuc) (Parts 2, 3, 5).
  • Configuration carries the rest, honestly — the Maintenance Rule, AP-913, hold points, OPEX, and nuclear e-signature are patterns, not named apps (Parts 3, 4, 5, 6).
  • The 9.x era is mostly inherited, and release governance is a nuclear concern — the Feature Channel's non-production caveat and the AI Service model change are the two things to plan around (this part).

The through-line of the whole series: the regulation is the spec. Read the applications through their regulatory drivers, name the configuration gaps honestly, and treat version selection as a validation activity — and you can scope a nuclear Maximo implementation, and survive the audit that follows, without a single over-claim.

Key Takeaways

  • Nuclear inherits 9.0/9.1 platform advances: Carbon, RBAs, Maximo Assistant, AI Service, Reliability Strategies, FMEA Content Builder — inheritance, not nuclear-specific features.
  • The MAS 9.2 Feature Channel is explicitly non-production evaluation (-pre.stable builds) — not automatically production-entitled evidence for a nuclear change-control process.
  • gpt-oss-120b became available for `mcc`, `pcc`, `fmea` and `nl2oslc` in the January 2026 Feature Channel, with IBM Granite 3.2 8b Instruct deprecated as of 25 November 2025. It is an opt-in migration, not a forced swap — and for customer-managed operators it reached a production-entitled stream only at 9.2 GA on 25 June 2026. Confirm which model your validated environment actually runs.
  • Nuclear has its own dedicated 9.2 APAR/DT stream, distinct from base Manage — pull it directly for validation planning.
  • Maximo Nuclear is a separate industry solution from Maximo for Utilities and the newer Maximo Renewables — do not let a portfolio view fold it into "generation."

References

Series Navigation

Previous:Part 6 — The Regulatory Crosswalk
Next:You have completed the series

Continue Your MAS 9 Journey

You have finished the nuclear-specific series. For the platform-level context this series deliberately left to others:

  • THINK-MAS series — the generic Maximo 7.6-versus-MAS platform delta (architecture, Carbon UI, OpenShift, generic AppPoints, MAS AI)
  • MAS-FEATURES series — feature-by-feature MAS 9 capability walkthroughs
  • MAS MANAGE series — core work management, PMs, job plans, mobile execution
  • [Return to the Series Index](/blog/mas-nuclear-series-index) — revisit any part

About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.

Published by TheMaximoGuys | July 2026