AI Explainability 360: One Package, Sixteen Installation Extras, and No Default Install
Interpretability and explainability of data and machine learning models
At a glance
- What is it?
- IBM Research's AIX360 gathers data, model, local, global and time series explainers under a single Apache-2.0 repository, but the setup table ties each algorithm to its own Python version, so the first real decision is which extra to install.
- Who is it for?
- AIX360 suits teams that already know which kind of explanation they need and want a research-backed implementation of it: pick the extra whose row in the setup table matches your Python version, for example pip install aix360[protodash] on Python 3.10 or pip install aix360[contrastive] on 3.7, and check that the algorithm you need appears in the supported algorithms list before committing.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AIX360 addresses: there is no single correct explainability method
The README states the premise directly: no single approach to explainability works best, and explanations differ along axes such as data versus model, directly interpretable versus post hoc, and local versus global. That is a documentation problem as much as a code problem. A data scientist who needs to justify a credit model has to choose among methods whose names (ProtoDash, CEM, GLRM, Ripper, ProfWeight) carry no hint of which question they answer. AIX360's response is to ship many algorithms in one Python package and to pair them with guidance material and a taxonomy tree under aix360/algorithms/README.md. The audience is therefore not the engineer who wants a single explain() call. It is the practitioner who has a specific explanatory question and needs to know which published method answers it, plus a reference implementation to run. The toolkit covers tabular, text, image and time series data, and it also ships proxy explainability metrics, which matters because the package is aimed at people who intend to measure an explanation rather than merely display one.
How the algorithms are organised: data, local, global, and the direct versus post hoc split
The supported algorithms list is grouped into six buckets, and the grouping is the actual architecture of the project. Data explanations hold ProtoDash and Disentangled Inferred Prior VAE. Local post-hoc explanations hold ProtoDash again, Contrastive Explanations Method, its Monotonic Attribute Functions variant, an exemplar-based CEM, Grouped Conditional Expectation, LIME and SHAP. Time series local post-hoc explanations hold saliency maps via Integrated Gradients, a time series LIME, and a time series ICE. Local direct explanations hold Teaching AI to Explain its Decisions and Order Constraints in Optimal Transport. Global direct explanations hold Interpretable Model Differencing, CoFrNets, Boolean Decision Rules via Column Generation (Light Edition), Generalized Linear Rule Models and Ripper. Global post-hoc explanations hold ProfWeight. One entry sits outside those buckets: Ecertify, listed under certifying local explanations, which the README attributes to Trust Regions for Explanations via Black-Box Probabilistic Certification. Each algorithm carries a citation, and several link to their own upstream repository, which tells you the package is partly an integration layer: LIME and SHAP arrive from their authors' own projects, while CEM, ProtoDash, ProfWeight and the rule learners are IBM Research contributions. The metrics section is deliberately small, listing only Faithfulness and Monotonicity, so the measurement surface is much narrower than the algorithm surface.
Installation is per-explainer, and the setup table is the real constraint
The README does not present a single installation command. It presents a table mapping an installation keyword to the explainer or explainers it provides, the operating systems, and a Python version. So the extra name is not always the algorithm name: the rbm keyword provides both brcg and glrm, the rule_induction keyword provides ripper, and the nncontrastive keyword provides nncontrastive. The Python column is where the friction lives. Most rows list 3.10, including cofrnet, dipvae, gce, ecertify, imd, lime, matching, nncontrastive, protodash, rbm, rule_induction and ted. Three rows are pinned elsewhere: contrastive (cem, cem_maf), profwt and shap all list 3.6 or 3.7. That means a modern interpreter cannot run the contrastive explainers or the packaged SHAP extra on the same environment as the 3.10 algorithms without separate environments. The imd row also lists macOS and Ubuntu only, with no Windows, which is the one platform gap in the table. The README also notes the tsice row for time series ICE, though the supplied table text is cut off at that row, so the Python version and OS support for tsice cannot be confirmed from this material. The package is published on PyPI, and the README carries a Read the Docs badge pointing at aix360.readthedocs.io, so the full API reference lives outside the repository. Beyond installation, the README points to example notebooks under ./examples and to an interactive experience at aix360.res.ibm.com that walks through a use case for different consumer personas.
Where AIX360 stops being the right tool
The most concrete limitation is the one IBM states itself. The README opens with a pointer to In-Context Explainability 360 (ICX360), described as extending explainability to LLMs in terms of the input given to the LLM. That is an admission that AIX360's methods do not cover that case. If your model is a large language model and your question is about its input, AIX360 is the wrong repository. The second limitation is environmental: because the setup table assigns different Python versions to different extras, a single environment cannot hold cem alongside protodash or gce unless you accept an older interpreter for everything. The third is maturity, and this one comes from the project's own wording. The README says the library is still in development and encourages contributions of algorithms, metrics and use cases. The release history is consistent with that: v0.2.0 in December 2019 integrated LIME and SHAP, v0.2.1 in October 2020, and v0.3.0 in July 2023 added algorithms and time series support. A roughly three-year gap between minor releases is a signal about how fast fixes arrive. The fourth limitation is scope of metrics: with only Faithfulness and Monotonicity listed, you cannot expect the package to score most explanations it produces. And the fifth is the taxonomy itself. The README says the taxonomy tree can be consulted to figure out which algorithms suit a use case, which means the choice is left to you. There is no auto-selection and no single entry point that picks a method for a given model.
What to compare it against, and how the approach differs
The obvious comparison is a single-method library, and the README makes that comparison easy because it names two of them as dependencies rather than rivals. LIME arrives from marcotcr/lime and SHAP from slundberg/shap, both cited with their GitHub links in the algorithm list. The difference in approach is breadth versus depth. A LIME-only or SHAP-only install gives you one family of local post-hoc explanations with its own API, its own release cadence and no Python-version split, because you install one project. AIX360 gives you that same LIME and SHAP plus contrastive methods, rule learners, prototype selection, a VAE-based data explainer, time series variants and two metrics, at the cost of a per-extra install matrix and an interpreter version that depends on which method you picked. The other comparison is against IBM's own follow-up, ICX360, which the README positions as the LLM-oriented successor for input-side explanation. So the honest framing is not that AIX360 replaces a LIME install. It is that AIX360 is the place to look when your question is not the one LIME or SHAP answers, for instance when you need contrastive explanations with pertinent negatives, or a directly interpretable rule model rather than a post hoc attribution.
Maintenance, releases, and the Apache-2.0 terms
The repository is not archived and the last push recorded is 2026-09-05, so commits continue even though the most recent tagged release is v0.3.0 from July 2023. That split matters for planning: if you depend on a tagged PyPI version, your upgrade path is the release cadence, and the cadence has been slow, with three minor releases across roughly four years. If you track master, you inherit whatever is on the default branch. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, and it requires that you preserve copyright and licence notices and state significant changes. Apache-2.0 does not require you to publish your own source. This is a description of the licence text, not legal advice; if you are embedding the toolkit in a product, have counsel read the NOTICE and attribution requirements. One practical licensing wrinkle is worth naming: the README lists LIME and SHAP as algorithms inside the package and links to their upstream repositories, so if you install those extras you are also depending on code that originated outside IBM Research. Check the upstream licences for those two projects separately rather than assuming the Apache-2.0 grant on AIX360 covers everything you end up importing.
Who should adopt it, and what to confirm before you do
Adopt AIX360 when your explanatory question is already specific and it is not the question LIME or SHAP answers. The candidates are contrastive explanations with pertinent negatives, directly interpretable rule models via the rbm or rule_induction extras, prototype-based data explanations through ProtoDash, and time series explanations through the tsice, time series LIME or saliency map entries. Also adopt it if you need Faithfulness or Monotonicity as a metric and want the implementation that sits next to the algorithms. Do not adopt it if you want one install that covers every method, because the setup table does not offer that. Do not adopt it on Python 3.11 or later, since the highest version listed anywhere in the table is 3.10. Do not adopt it for LLM input explanation, since the README redirects that case to ICX360. And do not adopt it expecting an automatic choice of method, because the taxonomy tree is guidance, not a selector. Before installing, do three things: find your algorithm in the supported algorithms list, find its installation keyword and Python version in the setup table (noting that the keyword is sometimes not the algorithm name, as with rbm for brcg and glrm), and confirm the operating system row includes yours, since imd omits Windows. Then install only that extra, for example pip install aix360[protodash] on Python 3.10, and confirm the version of Python you are using matches the row before you write any code against the API.
Editorial conclusion
AIX360 suits teams that already know which kind of explanation they need and want a research-backed implementation of it: pick the extra whose row in the setup table matches your Python version, for example pip install aix360[protodash] on Python 3.10 or pip install aix360[contrastive] on 3.7, and check that the algorithm you need appears in the supported algorithms list before committing. It is the wrong tool if you want one install that covers everything, if you are on Python 3.11 or newer, or if your model is a large language model, since the README points to IBM's separate ICX360 toolkit for that case. Verify first that the extra you need exists for your interpreter version and that the algorithm is not marked as a work in progress in the taxonomy tree.
Community notes