# AIX360's version is a literal in setup.py, and the newest release is three years old

> AIX360 collects explainability algorithms under seven categories and gates each one behind a pip extra that pins its own Python version and, in three cases, tensorflow 1.14. The packaging tells the sharper story than the algorithms: the version is a hardcoded string that rewrites a file inside the package, the newest release is v0.3.0 from 2023-07-01, and the Dockerfile installs from PyPI before cloning the repository over it.

**Trusted-AI/AIX360** — Interpretability and explainability of data and machine learning models

- Repository: https://github.com/Trusted-AI/AIX360
- Website: https://aix360.res.ibm.com/
- Stars: 1,807 · Forks: 326
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/trusted-ai-aix360

## The version is a string literal that rewrites a file in the package

`setup.py` does not read the version from anywhere. It declares it and then writes it into the package as a side effect of the build:

```python
version = "0.3.0"

with open("aix360/version.py", "w") as f:
    f.write('# generated by setup.py\nversion = "{}"\n'.format(version))
```

So `0.3.0` is a literal in the build script, and running the build creates or overwrites `aix360/version.py` inside the source tree. There is no tag lookup and no git describe.

The same number appears in three places, and they have drifted apart in meaning. The README heading is `AI Explainability 360 (v0.3.0)`, the releases page has v0.3.0 published 2023-07-01 as its newest entry, and the default branch `master` was last pushed on 2026-09-05. So the version everyone reads is 0.3.0, that release is a 2023 build, and the branch has moved well past it without a new tag. `pip install aix360` gives you the 2023 artifact; `pip install` from a clone gives you 2026 code that still identifies itself as 0.3.0.

The older tags make the same point: v0.2.1 in 2020 and v0.2.0 in 2019, whose release note is the integration of LIME and SHAP.

## The Dockerfile installs the package, then clones the repository over it

The container recipe is six steps and reads as if it was assembled in the wrong order:

```dockerfile
FROM ubuntu:18.04
FROM python:3.6
```

Two FROM lines, and the second one wins, so `ubuntu:18.04` is discarded and the base is `python:3.6`. That interpreter matches the oldest floor in the extras table rather than the newest.

The order of the next steps is the substantive problem. `RUN pip install aix360` installs the released package from PyPI. The step after it is `RUN git clone https://github.com/Trusted-AI/AIX360.git`, which puts a source checkout in the working directory `/src` on top of a site-packages that already contains an older copy of the same library, and nothing installs that checkout. The final step is `RUN pip install jupyterlab` under a comment that says to run the tutorial inside the container. The comment describes an action the line does not perform, and the file ends without a `CMD` or an `ENTRYPOINT`, so running the image starts nothing.

None of this is dangerous, but all of it misleads: a container that looks like a source build is in fact a PyPI install with an unused checkout beside it.

## Eighteen extras, three Python floors and one missing example

The installation surface is a table of eighteen keywords, and it is the real API of the package. Each keyword pulls a different algorithm group, and the table also records the operating systems and the Python version for that group: `cofrnet`, `dipvae`, `gce`, `ecertify`, `lime`, `matching`, `nncontrastive`, `protodash`, `rbm`, `rule_induction`, `ted`, `tsice`, `tslime` and `tssaliency` all name Python 3.10 on macOS, Ubuntu and Windows. `profwt` and `shap` name Python 3.6, and `contrastive` names 3.7.

One row breaks the operating system pattern: `imd` is listed for macOS and Ubuntu only, with no Windows.

So a single `pip install aix360[profwt]` and a single `pip install aix360[gce]` do not target the same interpreter, and the package will not tell you that constraint during resolution. The default extra is the small one, `numpy`, `pandas`, `scikit-learn` and `matplotlib`, and everything else is opt in per algorithm.

The `examples/` directory has twenty subdirectories, and one of them, `ted`, has no matching extra. There is no examples directory for `ted` while the keyword and its explainer are in the table, so that algorithm is the one you get with the least guidance.

## Three extras pin tensorflow 1.14, and one installs from a git branch

The dependency pins carry comments, and the comments are the interesting part because they explain each conflict rather than hiding it. The `contrastive` extra is the clearest example:

```python
    "contrastive": [
      "keras==2.3.1",
      "tensorflow==1.14",
      "protobuf<3.20",  # TF 1.14's generated _pb2 files reject protobuf 4.x
      "requests",
      "safetensors<0.4",  # GAN weights format; 0.3.x is the last series with Py3.7 wheels
      "scipy>=0.17",
      "scikit-image",
      "torch",
      "h5py<3.0.0",  # to resolve keras error: 'str' object has no attribute 'decode'"
    ],
```

`profwt` and `shap` pin `keras==2.3.1` and `tensorflow==1.14` the same way. Those releases are from 2019, and each one drags a chain of compensating pins: protobuf below 4 because of generated `_pb2` files, safetensors below 0.4 for the GAN weight format, h5py below 3 to avoid a keras decoding error. The `rbm` extra caps `numpy<=1.24.3`, `scikit-learn<1.2.0` and `scipy<=1.10.1`, and `cofrnet` pins `numpy==1.24.2` exactly.

The one that is not a version pin at all is `matching`, which is a single entry: `otoc @ git+https://github.com/IBM/otoc@main#egg=otoc`. That resolves against a branch, not a tag, so two installs of the same aix360 extra can pull different code with no change on the aix360 side. Every other extra is at least pinned to a release.

## ProtoDash sits in two categories, and there are two metrics for all of it

The algorithm inventory is grouped by explanation type, and the grouping is not always exclusive. ProtoDash appears under data explanations and again under local post-hoc explanations. The data explanations group is the thinnest, with ProtoDash and the Disentangled Inferred Prior VAE, and the largest is local post hoc: ProtoDash, the Contrastive Explanations Method and its monotonic attribute variant, an exemplar based variant, grouped conditional expectation, LIME and SHAP.

The remaining groups are time series local post hoc, which is LIME, individual conditional expectation and saliency maps via integrated gradients adapted to sequences; local direct, which is the Hind work on teaching a model to explain its decisions and order constraints in optimal transport; certifying local explanations, with Ecertify; global direct, with interpretable model differencing, CoFrNets, boolean decision rules, generalized linear rule models and Ripper; and global post hoc, with ProfWeight.

Against roughly twenty algorithms across seven categories, the metrics section lists two: faithfulness and monotonicity. Choosing among the algorithms is left to the reader, and the README says so directly, pointing at guidance material on the project site and a taxonomy tree in the repository at `aix360/algorithms/README.md`. The interactive experience at aix360.res.ibm.com walks the same ground through example use cases, and the notebooks under `examples/` are the data scientist route in.

## LLM input attribution is pointed at a different repository

The most prominent line in the README is a pointer away from the package. A banner announces that IBM Research has a new toolkit, In-Context Explainability 360, and describes it as extending explainability to LLMs, specifically in terms of the input given to the LLM.

That is a deliberate division. AIX360's own scope is datasets and models across tabular, text, image and time series data, and the LLM input side is handled elsewhere. Anyone arriving looking for prompt or attribution explanations for a language model is being redirected before they read a single algorithm name.

The rest of the entry points follow the same pattern of staged depth. The project site is the introduction, walking an example use case for different consumer personas. The tutorials and example notebooks under `examples/` are the deeper, data scientist oriented route, and the API reference is available for the rest. Documentation builds through readthedocs, with a `.readthedocs.yml` at the root and a `docs/` directory beside it.

The project also states its own lifecycle in plain words: the library is still in development, it was built with extensibility in mind, and contributions of algorithms, metrics and use cases are invited through a Slack community with contribution instructions in `CONTRIBUTING.md`.

## Apache-2.0 in the metadata, a supplementary licence directory, and a disabled Travis file

Licensing is handled with a pair. Apache-2.0 is the recorded licence, and the root of the tree carries a directory named `supplementary license/` beside the `LICENSE` file. That is the pattern for a project whose code is Apache licensed but whose data or derived material is not, and the split is only discoverable by listing the root, since the README does not mention the directory.

The CI story has the same shape. The README badge points at `.github/actions/workflows/Build.yml`, so continuous integration runs on GitHub Actions, and the root also contains a file named `Not_using_travis.yml`. The leading `Not_` prefix is what keeps it inert, and its presence says the project moved off Travis and left the old configuration in the tree rather than deleting it.

Alongside those sit `MAINTAINERS.md`, `SECURITY.md` and `CONTRIBUTING.md`, and a `tests/` directory beside the `aix360/` package. Nothing in the root tree pins the version, and nothing in the build reads a tag, so the release history on the releases page and the version inside the package are maintained by hand and only agree as long as someone remembers to bump the literal.

## Conclusion

Use AIX360 when you need several families of explainers available in one import and you are willing to install a per algorithm extra, since the choice of explainer is what the extras select. Skip it if you need LLM input attribution, because the maintainers point at a separate toolkit for that, or if you need a package whose dependencies resolve on a current Python, because the extras pin old interpreters and tensorflow 1.14. Before you install, decide whether you want the released 0.3.0 from PyPI or a build from the branch, and check the extra you pick for pins that pull from a git branch rather than a fixed version.

## FAQ

### What is AIX360 and what does it cover?

The AI Explainability 360 toolkit is an open source library for interpretability and explainability of datasets and machine learning models, supporting tabular, text, image and time series data. Its algorithms are grouped into data explanations, local post hoc, time series local post hoc, local direct, certifying local explanations, global direct and global post hoc.

### How do I install AIX360 with a specific explainer?

With a pip extra named after the algorithm group, for example cofrnet, contrastive, dipvae, gce, ecertify, imd, lime, matching, nncontrastive, profwt, protodash, rbm, rule_induction, shap, ted, tsice, tslime or tssaliency. The default extra is only numpy, pandas, scikit-learn and matplotlib, and the README's table records the Python version each extra targets.

### Which Python versions does AIX360 support?

It depends on the extra. The table lists Python 3.10 for most groups, 3.6 for profwt and shap, and 3.7 for contrastive, with macOS, Ubuntu and Windows throughout except imd, which lists macOS and Ubuntu only.

### What is the current version of AIX360?

0.3.0, and it is a hardcoded string in setup.py that also writes aix360/version.py when the build runs. That release was published on 2023-07-01 while the default branch was last pushed on 2026-09-05, so installing from PyPI and installing from source give different code under the same version number.

### Does AIX360 explain LLM inputs?

The README directs that to a separate IBM Research toolkit, In-Context Explainability 360, which extends explainability to LLMs in terms of the input given to the model. AIX360's own scope is datasets and models across tabular, text, image and time series data.

### Which explainability metrics does AIX360 measure with?

Two: faithfulness, following Alvarez-Melis and Jaakkola, and monotonicity, following Luss and colleagues. That is a small metric set against roughly twenty algorithms spread over seven explanation categories, which is why the README points at guidance material and a taxonomy tree for choosing between them.

## Sources

- [License: Apache-2.0](https://github.com/Trusted-AI/AIX360/blob/master/LICENSE)
- [Project website](https://aix360.res.ibm.com/)
- [README](https://github.com/Trusted-AI/AIX360/blob/master/README.md)
- [Releases](https://github.com/Trusted-AI/AIX360/releases)
- [Trusted-AI/AIX360 on GitHub](https://github.com/Trusted-AI/AIX360)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trusted-ai-aix360