What-If Tool: A No-Code Probe for Black-Box Classifiers and Regressors

The Gap It Fills: Inspecting a Model You Cannot Read

Once a classifier is trained and served, the people who need to reason about its behaviour are often not the people who wrote it. The README frames the purpose plainly: the tool gives people a way to interact with a trained model over a dataset through a visual interface with no code required. That is a narrower claim than 'model interpretability', and a more useful one. The interface performs inference on a large set of examples and renders the results, so the review loop is: pick a dataset, look at predictions, change an input, look again. The audience is anyone doing model review or fairness review who can be handed a browser tab instead of a Python session. The repository topics name the intended scope directly: ml-fairness, visualization, tensorboard, jupyterlab-extension.

What Actually Runs When You Open the Interface

The tool is a front end. It does not train, and it does not load a checkpoint file directly. In the TensorBoard path, the README states that only the model server host and port need to be provided, served through TensorFlow Serving, and the tool queries that server over gRPC rather than REST. The docker image for TensorFlow Serving exposes the gRPC API on port 8500, so that is the port value the tool expects in that setup. The model can implement the Classification, Regression, or Predict API. If it uses Predict, inputs must be serialized tf.Example or tf.SequenceExample protos, and outputs must be shaped to the tool's expectation: a 2D float tensor of class probabilities per example for classification, or a single float regression score per example. In a notebook, the same interface can attach to a TensorFlow Estimator taking Example or SequenceExample protos, to an AI Platform Prediction-hosted model, or to a custom prediction function. That last option is the escape hatch: the README notes it lets you load any model, including non-TensorFlow models that do not use Example protos, provided the custom function's input and output specifications are correct. The interface renders attribution values per input feature when the model supplies them; the age-prediction demo returns vanilla gradients specifically to demonstrate that display.

Getting a Demo or a Notebook Session Running

The repository ships four web demos, each a classifier or regressor over a public dataset: UCI Census salary prediction, CelebA smile detection, UCI Iris multiclass, and UCI Census age regression. Each is built with Bazel. The census salary demo runs with bazel run wit_dashboard/demo:demoserver and is then reachable at http://localhost:6006/wit-dashboard/demo.html. The image demo uses bazel run wit_dashboard/demo:imagedemoserver and serves http://localhost:6006/wit-dashboard/image_demo.html. Iris uses bazel run wit_dashboard/demo:irisdemoserver at http://localhost:6006/wit-dashboard/iris_demo.html, and age uses bazel run wit_dashboard/demo:agedemoserver at http://localhost:6006/wit-dashboard/age_demo.html. For the notebook route, the README points at What_If_Tool_Notebook_Usage.ipynb, which starts from a CSV file, converts rows to tf.Example protos, trains a classifier, and then hands that classifier to the tool. That notebook is the fastest way to see the whole path end to end, because it produces the exact input format the tool consumes rather than assuming you already have protos on disk.

The Input Contract Is the Real Cost

The friction in this project is not the UI, it is the proto requirement. Anything routed through the Predict API has to arrive as serialized tf.Example or tf.SequenceExample, and the output tensors have to match the expected shapes exactly. A model that returns a dict of named scores, or a list of labels, or logits without a softmax, does not fit without a wrapper. The custom prediction function path removes the model-framework constraint but not the specification constraint: the README is explicit that it works as long as the function's input and output specifications are correct, which puts the burden of shape and type correctness on you. There is also an operational constraint that is easy to miss when reading quickly: the TensorBoard integration talks gRPC, so a model exposed only through a REST endpoint will not connect. If your serving stack fronts the model with a REST gateway and no gRPC listener, this tool is the wrong instrument until you add one.

Release Cadence and What Maintenance Looks Like

The version history is short and slowing. v1.7.0 landed in June 2020, v1.8.0 in January 2021, and v1.8.1 in October 2021. The repository shows a push in June 2026, so activity has not stopped, but the last tagged release is more than four years old. For an adopter this matters in a specific way: the TensorFlow Serving APIs and the Estimator API that the README builds on have moved on, and the documentation here still describes the Estimator-based saved model workflow. You should treat the tagged release as the stable surface and the master branch as unversioned. The licence is Apache-2.0, which permits commercial and modified use and includes a patent grant; it also requires that you preserve notices and state changes, and it does not grant trademark rights. That is a summary of the licence text, not legal advice, and any redistribution decision should go through whoever handles licensing at your organisation.

Where It Stops Being the Right Tool

This is an interactive inspection surface, not a reporting system. It has no notion of scheduled evaluation, no regression gate, and no output artifact you can diff between model versions. If your requirement is 'alert me when subgroup accuracy drops after a retrain', the tool will let a human find that by hand and will not do it for you. The dataset sizes it handles are described only as 'a large set of examples', with no figure given, so capacity planning has to come from your own trial rather than from documentation. And the whole approach presumes you have a served model to point at. A research checkpoint sitting in a directory, with no serving container and no prediction function written, is not something this project will open for you. The README's own framing is a visual interface over a model, which means the serving work is upstream of the tool and remains yours.

The Alternative: Fairness Toolkits You Import

The clearest contrast is with library-based fairness and evaluation packages such as Fairlearn or the TensorFlow Model Analysis suite. Those are code you call: you pass a model and a dataset into an API and get back metrics, slices, and plots you can assert on in a test. The What-If Tool inverts that relationship. The model stays behind a serving boundary, the analysis happens in a browser, and the output is a visual state rather than a returned object. The practical consequence is that a library fits into continuous integration and the What-If Tool does not, while the What-If Tool lets a reviewer who cannot write the evaluation code still change an input and watch the prediction move. If your only need is a numeric fairness metric per slice in a pipeline, reaching for this project adds a serving dependency for something a metrics library does directly. If your need is a shared room where a product owner, a data scientist, and a compliance reviewer look at the same prediction and argue about it, the library does not give you that and this does.

Who Should Take It and What to Check First

The tool fits teams already inside the TensorFlow Serving or AI Platform Prediction world, with models that emit Example protos and whose outputs can be shaped to the required tensors. It fits notebooks, where the Colab usage notebook shows the CSV-to-proto-to-classifier path in one file. It does not fit teams whose models live only behind a REST endpoint, or whose checkpoints have no serving wrapper, or whose review process needs machine-checkable output rather than a UI. Two things to verify before you invest: first, that your serving process exposes gRPC on the port you plan to enter, since the tool will not use the RESTful API; second, that your Predict API output is either the 2D class-probability tensor or the single regression score, because anything else needs a custom prediction function and a correctly specified input and output contract on your side. The four Bazel demo targets are the cheapest way to confirm the interface works in your environment before you wire up a real model.

Editorial conclusion

Adopt the What-If Tool if you already serve a TensorFlow Estimator or an AI Platform Prediction model and you need a shared, no-code surface for reviewing predictions and slicing performance by subgroup. Do not adopt it if your model is a PyTorch checkpoint with no serving layer, or if you need a maintained release cadence: the latest tagged release is v1.8.1 from October 2021, and the repository's most recent push is June 2026. Before committing, verify that your serving endpoint speaks gRPC on the port you intend to configure, and confirm that your model's output matches the 2D probability tensor or single regression score shape the Predict API path requires.

Official sources

1. License: Apache-2.0
2. PAIR-code/what-if-tool on GitHub
3. Project website
4. README
5. Releases