Matlab Interpret Machine Learning Model

---
name: matlab-interpret-machine-learning-model
description: Interpret and explain a trained tabular machine-learning model (classification or regression) in MATLAB. Find which predictors, features, or columns matter most; explain why the model made a specific prediction, including diagnosing predictions it got wrong; show how a predictor affects the output; and compare how the model behaves across cohorts or subgroups. Uses model-agnostic techniques and model-native measures, and works on custom models (such as a dlnetwork) through a prediction function handle. Use for model interpretability, explainability, and feature-importance questions on tabular data, not for training, tuning, feature selection, deploying models, or models trained on image, text, signal, or other non-tabular data.
license: https://www.mathworks.com/content/dam/mathworks/license/pmrl/license.md
metadata:
  author: MathWorks
  version: "1.0"
---

# Interpret a Trained Tabular Model

Interpret a trained tabular model — a built-in Statistics and Machine Learning Toolbox (SMLT) classifier or regressor, or a custom model reached through a prediction function handle — by matching the user's intent to the right techniques, handling the custom-model case correctly, and avoiding the failure modes agents fall into on this workflow. This skill bundles the workflow in `references/` (per-technique procedures and branch tables read on-demand) and `scripts/` (the `functionHandleMap` helper). Do not invoke files in `references/` as separate skills — they are only read when the corresponding step runs.

## When to Use

- "Which predictors matter / feature importance / what drives the model"
- "Why did the model predict X for this case / explain this prediction"
- "What shape is the effect of predictor P / partial dependence / how does the prediction change with P"
- "Why did the model get these cases wrong / diagnose these errors / what would flip this"
- "Does the model behave differently for group Y / segment / cohort"
- Any of the above over a **custom / non-SMLT model** (a `dlnetwork` or a prediction function handle)

## When NOT to Use

- Training, tuning, hyperparameter search, or feature selection (this skill interprets an already-trained model)
- Deployment or code generation (downstream)
- Models trained on image, text, signal, or other non-tabular data
- Multi-response regression or multilabel classification (a model with more than one response variable); the interpretability functions here assume a single response
- A **partitioned / cross-validated model** (`ClassificationPartitionedModel`, `RegressionPartitionedModel`, or any object from `crossval` / a `KFold`/`Holdout`/`CVPartition`/`CrossVal` option); it holds K fold-models rather than one fitted model, so there is no single model to interpret
- The user wants to work in the Classification Learner or Regression Learner **app** → use `matlab-use-machine-learning-apps`
- Acting on a diagnosis (retraining, collecting data); this skill produces the diagnosis only

## Communication Style While Running This Skill

How you talk to the user matters as much as the analysis. These rules apply from the first message to the last.

- **Talk about their model and results, never the skill's machinery.** The user does not know this skill has sections, steps, references, or rules — do not mention them. Never say "the skill says," "the skill is clear that," "per the routing," "Decision 2," "the native gate," "the level," or "global vs cohort" — these are internal framing. State the reasoning as your own ("cohorts should come from you, so tell me which") and name what you are *doing* ("comparing the groups"), not the skill's name for it. The test: if a sentence only makes sense to someone who has read this skill's files, rephrase it. Domain terminology that stands on its own in a sentence is fine. **The exception:** if a real problem appears, name it plainly, and only then is it fine to point at the internal file where the fix belongs.
- **Read reference and support files silently — the STEP: heading is the only thing you announce.** Never narrate a file read. Any sentence that opens with "Let me read…", "Let me check…", "Let me pull up…", "Now let me read…", or "let me look at the … approach/reference/routing" is banned — delete it. The reads that prepare a phase happen silently *under* that phase's STEP: heading; do not emit a line between headings that describes reading, checking, or pulling up a file. The user does not know these files exist. After a read, the next thing you say is a fact about their model or the plan, never what you just read.
- **Announce each phase once, on entry, as a `STEP:` heading — not on every step within it.** As you begin a phase, mark it with a short heading of the form **STEP: phase name** on its own line, so the user can see at a glance where things stand. The phases: *STEP: Establishing inputs → STEP: Clarifying scope and intent → STEP: Confirming the plan → STEP: Creating and validating the function handle* (only when a custom model needs one) *→ STEP: Running the analysis → STEP: Results and summary.* Emit the heading a single time on entry; do not re-stamp it on each MATLAB call or sub-step inside the phase.
- **Facts only until the plan.** While establishing inputs and clarifying scope, report what is there — model kind, task, predictors, data — and nothing about technique. Do not pre-announce routing ("this will run agnostically through a prediction handle," "the model has no native measures," "this opens up …"). The routing rationale is the plan's job; stating it early commits you before scope is even chosen.
- **Format for scanning.** Put each heading or item label on its own line, with its explanation on the next — never a bold label with a long sentence trailing inline. One idea per sentence. A multi-part finding (a number, a caveat, a metric) is several lines or bullets, not one packed paragraph. **Any warning, caveat, or explicit note gets its own line** — never buried inside a sentence, since that is exactly what a user skims past. The reader should be able to skim the labels alone and know what happened.

## STEP: Establishing inputs

Before scoping the question, inventory what is available and **state it back** using relevant fields below, then **ask the user to confirm or correct it before scoping**. This is the first thing reported. Report **facts only**: do not pre-announce or hint at routing (native vs agnostic, which technique, "opens up …"); the routing rationale belongs in Confirming the plan, after Decisions 1 and 2 have run.

Load and inspect the model in MATLAB, then report:

- **Model** — run `class(Mdl)` and report it; if only a function handle is provided with no model, report it as "function handle". The class string may be namespaced (e.g. `classreg.learning.classif.ClassificationEnsemble`); report the kind from the trailing class name, not a leading prefix. Model determines whether native measures exist at all (a `dlnetwork` or function handle has none) and feeds the native gate in Decision 2. If `class(Mdl)` is a **partitioned model** (the class name contains `Partitioned`, e.g. `ClassificationPartitionedModel`), stop and tell the user this skill cannot interpret it: it holds K cross-validation fold-models, not one fitted model, so there is no single model to attribute. Do not proceed with an analysis.

- **Task** — classification or regression, and the response name. For an SMLT model, `Mdl.ResponseName` gives the response — it errors on `dlnetwork`. For a **classifier**, `Mdl.ClassNames` gives the classes (its count is binary vs multiclass); `ClassNames` exists on classifiers only.

- **Predictors** — count, names, and which are categorical. SMLT models: `Mdl.PredictorNames`; categoricals from `Mdl.CategoricalPredictors` or `Mdl.VariableInfo.IsCategorical` (`LinearModel` / GLM, which have no `CategoricalPredictors`).

- **Training data** — carried in the model, provided separately, or none; and its size. Full SMLT models usually carry it (`Mdl.X`/`Mdl.Y`, or `Mdl.Variables` for `LinearModel`/GLM); compact models and handles do not.

- **Test data** — provided or none, and its size.

**A `dlnetwork` or a function handle carries none of this metadata** — `ResponseName`, `ClassNames`, `PredictorNames`, and `CategoricalPredictors` all error, and a `dlnetwork`'s only readable width (`net.Layers(1).InputSize`) is the post-encoding channel count, not the predictor count. Because the object embeds no data, the user must supply a training and/or test set for these models — read the predictor names and count from that data's variable names, and which predictors are categorical from its column types. The task and response name are not recoverable from the object; confirm them with the user if not clear from the data.

The available data constrains which techniques are possible. **State the inventory back and ask the user to confirm or correct it before scoping** — call out any missing data especially. **No test set** (training only): without it, results reflect training behavior rather than generalization — proceed on training data with that caveat if the user confirms none. **No data at all**: this limits which interpretability functions can run, so ask whether any data can be provided before falling back. If the user has data, have them load it. Carry the confirmed inventory into Decision 2 and the setup rules.

## STEP: Clarifying scope and intent

If the user's prompt already makes the intent clear, read it off (Decision 1) and do not ask. If the skill was invoked bare, or the ask is vague, present this menu **once**, verbatim. Present this menu **only after inputs are established** (the inventory has been stated back) — never in the same message to help identify inputs.

> What do you want to learn about this trained model?
> 1. **Which predictors matter** — rank the predictors by how much each drives the model, across the whole dataset.
> 2. **Shape of a predictor's effect** — how the prediction changes as one or two predictors vary.
> 3. **Why a specific case was predicted** — a per-observation explanation for one or more rows, including diagnosing cases the model got wrong.
> 4. **Cohort differences** — rank the predictors within each cohort (a subgroup you name) and compare, to see what drives the model differently from one cohort to the next.

Treat a free-text answer, or more than one number, as one or more intents and resolve each in Decision 1. If the answer names cases or a subgroup, capture which ones.

## Decision 1: What Is the User Asking?

| Intent                                                  | Level            |
| ------------------------------------------------------- | ---------------- |
| Which predictors drive the model (magnitude, direction)     | global           |
| Shape of one or two predictors' effect                      | global or cohort |
| Why the model predicted Y for this case                     | per-observation  |
| Does behavior differ across cohorts (importance per cohort) | cohort           |

**Level follows from intent.** Importance is split by level across two menu items — "which predictors matter" is **global**, "cohort differences" is **cohort** — so neither asks; picking both just runs each. "Why the model predicted Y" is **per-observation**. Only **effect shape** has an open level: ask once — *"Across the whole dataset (global), or within a specific cohort? If a cohort, tell me which."* A cohort named anywhere in the request resolves this without asking.

There is no standalone "interaction detection" intent: two-predictor interactions are visualize-only inside effect-shape (2-D PDP, Shapley 2nd-predictor coloring).

A request can carry **more than one intent** (the prompt asks for more than one). Handle each intent on its own, unless the answers must be **read together or compared** — then keep the whole set on one consistent technique so the results line up (Decision 2 explains why a mixed native/agnostic set cannot be compared). A custom model is always all-agnostic.

## Decision 2: Which Technique?

When a request spans intents that must be **compared** (see Decision 1), keep them all agnostic: native measures are not on a common scale across families or measures, so a mixed native/agnostic set cannot be lined up side by side.

**Step 1 — Native gate.** Go native only when one of the below holds, or when the user explicitly asks for the model's own native measure; otherwise use agnostic (Step 2).

- **Local explanation + the model is a GAM** → `plotLocalEffects(mdl, queryPoint)`: the model's **exact** additive decomposition, not an approximation. Prefer over agnostic Shapley/LIME.
- **Effect shape + the model is a LinearModel** → `plotAdjustedResponse` (one predictor) / `plotInteraction` (a pair; needs the interaction term in the model formula, otherwise it can't show it): the effect is closed-form and free, whereas agnostic PDP recomputes the same curve at far higher cost. (GLM has no such plot — use agnostic.) **`plotAdjustedResponse` is not defined on a `CompactLinearModel`** (only the full `LinearModel`); on a compact model use agnostic PDP for the one-predictor effect, though `plotInteraction` still works for a pair.
- **Importance with no test set** → use a native measure that reads from the fitted model. Out-of-bag permutation importance is honest even with only training data (no held-out set needed) for a **bagged ensemble** (`ClassificationBaggedEnsemble` / `RegressionBaggedEnsemble`) or a **`TreeBagger`**; the access differs by object, see [native-importance-measures.md](references/native-importance-measures.md). For every other family, native is the fallback only when there is **no data at all** (with any data, training or test, agnostic is preferred).

Native measures are not on a common scale across families, and each is valid only under its training precondition, which cannot be always checked programmatically: compute the native measure, then warn the user that its validity rests on the assumption specified in the trigger above (for importance, see [native-importance-measures.md](references/native-importance-measures.md)).

**Step 2 — Agnostic technique.** No native condition fired: use the agnostic technique for the intent and read its reference. 

Run `functionHandleMap(mdl)` here (it ships in `scripts/`; see the Scripts section for the call): a `"not supported"` value **reroutes selection** (e.g. a custom model has no `permutationImportance` — fall back to `shapley` importance); a `"yes"` value means the chosen technique runs through a prediction handle to resolve before implementing (Before You Compute → Rule 1). 

Reading a reference below happens in two passes: now, read its **intro, data rule, and decision rule** to select the sub-technique — data availability rules out techniques first, then the decision rule picks among what remains; at implementation, once `Mdl` is resolved, read its **data rule and implementation** to write the call.

| Intent                                  | Agnostic technique                                                                    | Reference                                                                 |
| --------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Which predictors drive the model        | `permutationImportance`, global `shapley`                                             | [agnostic-global-importance.md](references/agnostic-global-importance.md) |
| Shape of one or two predictors' effect  | PDP / ICE (`partialDependence`), Shapley dependence                                   | [agnostic-effect-shape.md](references/agnostic-effect-shape.md)           |
| Why the model predicted Y for this case | local `shapley`, `lime`, `counterfactuals`                                            | [agnostic-local-explanation.md](references/agnostic-local-explanation.md) |
| Does behavior differ across cohorts     | per-cohort `permutationImportance` or `shapley`, then compare each predictor's rank, magnitude (and `shapley` direction) across cohorts | [cohort-analysis.md](references/cohort-analysis.md)                       |

Model support is **per-function**: `functionHandleMap(mdl)` reports, for each function, whether this model is used directly (`"no"`), needs a prediction handle (`"yes"`), or is unsupported (`"not supported"`). "Custom" is a property of the (model, function) pair, not the model alone. How to act on a `"yes"` is Before You Compute → Rule 1.

## STEP: Confirming the plan

Before resolving `Mdl` or computing anything, present the plan to the user and get approval. This is an always-on gate, not the conditional Clarifying scope and intent ask: it confirms the concrete work, not just the level of analysis.

Show, for the request:

- **The intents to be addressed** (from Decision 1), including any the prompt raised that are out of scope.
- **The function(s) to be run per intent** (from Decision 2): name the **actual MATLAB function** to be called, not the statistical concept behind it (say `shapley` / `plotPartialDependence`, not "SHAP / partial-dependence plot"), and why native or agnostic. Where a default was picked over a viable alternative, state it so the user can switch:
  - **Local explanation** — `shapley` (more accurate, no surrogate model). **Alternative:** `lime` (surrogate-based).
  - **Global importance** — `permutationImportance` (default). **Alternative:** `shapley`.
- **Which functions need a prediction handle** — *only if any do* (`functionHandleMap` marked `"yes"`): name them so the user knows a handle will be built and validated. If every routed function runs on the model directly, say **nothing** about handles — do not report that no handle is needed; the user should not have to think about handles that aren't there.
- **A slow-run warning — *when a run will actually be slow***. Two independent triggers: **(a)** the routed technique is inherently slow — `counterfactuals`, or `shapley` on its **kernelSHAP** fallback — which warn whenever routed, regardless of data size; or **(b)** an **expensive model** meets a dataset **over 1000 observations and 5 predictors** (see [agnostic-global-importance.md](references/agnostic-global-importance.md)). Say in one line that it may run for a while, and **offer** the way to shrink it (a query-point subset for `shapley`; the observation / predictor / permutation levers for `permutationImportance`). This is a user choice made at the plan stop, **never** a silent shrink. If nothing routed hits either trigger, say **nothing** about runtime.
- **Which data the analysis will run on** — *only when the user hasn't already said which to use*. When both train and test are available: using **test** (name the actual variable, e.g. `Xtest` — reflects generalization). **Alternative:** the training set (name it too, e.g. `Xtrain`). When only training data is available, don't offer a choice — state that results reflect **training behavior, not generalization**. Skip this line for a technique that takes no data (a native measure with no dataset), or when the user already specified the dataset — just use what they asked for.

**CONFIRM — this is an explicit go/no-go on the plan itself. Stop and wait for the user to approve the plan before resolving `Mdl` or computing anything.** You may collect run settings at this same stop (for example, for a LIME explanation, `k` — how many top predictors the local explanation should report), but the user answering those settings is **not** plan approval — still require a clear "proceed" on the plan before continuing. The approved set is the **confirmed set** that Before You Compute resolves `Mdl` for. If the user changes an intent or a technique, revise the list and re-confirm before proceeding.

## Before You Compute: Two Setup Rules

1. **Resolve `Mdl`, once, for the whole confirmed set of interpretability functions to run.** `Mdl` is what gets passed to every interpretability function: the model object, or a validated prediction handle. After the technique set is confirmed (Confirming the plan), read the `functionHandleMap` rows for the functions to be run. If every routed function is `"no"`, pass the model object as `Mdl` directly. If any is `"yes"`, build a **single** prediction handle for the union of those functions before implementing anything, and pass it as `Mdl`; give it per-function output adapters where the functions demand different outputs, then validate it reproduces the model's own known predictions. If the user supplied a handle, vet it against the same contract and tell them what to correct rather than adapting it silently. See [custom-model-wrapper.md](references/custom-model-wrapper.md) for the create-and-validate procedure. A `"not supported"` function has no handle path — reroute per Decision 2. Resolve `Mdl` before running any reference snippet; a hand-rolled encoding produced a confidently reported, silently wrong attribution in testing, so the validate step is not optional.
2. **Background and data convention.** Use `Xtrain` as the Shapley/LIME background; never place the query point in its own reference set. Run importance, effect, and query points on the **data confirmed at the plan stop** (test by default; see CONFIRM). The background stays `Xtrain` regardless of that train/test choice — the choice governs what gets *scored/queried*, not the reference set.

## STEP: Running the analysis

**Then compute.** With `Mdl` resolved, return to the routed reference and run its **data rule + implementation** (the second pass) to write and execute the call. Apply the **Core Idioms** as you write it (they prevent the most common failures), and check **Key Functions** for the release floor of any function not yet confirmed available in the running release. Verify the output against what the intent asked for before reporting.

## STEP: Results and summary

Report the finding in the user's terms — what the analysis said about their model, tied back to the intent that was asked. Surface any caveat or assumption on its own line.

## Core Idioms

- **Reach for the built-in, do not hand-roll.** `permutationImportance`, `shapley`, `plotPartialDependence(...,Conditional=...)` for ICE, `lime` all exist. Hand-rolling them is the most common failure.
- **Batch `shapley`; build the explainer once.** Pass a `QueryPoints` matrix (or construct once and `fit` per point) instead of reconstructing the explainer each iteration. Batching gives `MeanAbsoluteShapley` (the values) **and its built-in views for free: `plot(explainer)` is the mean\|Shapley\| bar, `swarmchart(explainer)` the signed summary. Render the summary with these — do not read `MeanAbsoluteShapley` and hand-build a `bar` chart from it.** Use `swarmchart` / `boxchart` for multi-observation and cohort views. Control cost with `NumObservationsToSample` on the background (**default 100**), **not** by silently dropping query points — *lower* it (e.g. 50) to reduce runtime; larger values or `"all"` increase it. Do not raise it above 100 and call it "keeping it tractable."
  - Method-name split (verified): `plot(explainer, ClassNames=...)` is **plural**; `swarmchart` / `boxchart(explainer, ClassName=...)` are **singular**. Plural on swarm/box errors.
- **`lime` is one point per explainer.** Call `lime(Mdl, Xtrain)` once, then `fit(explainer, queryPoint, k)` per point (`k` is the 3rd positional `NumImportantPredictors`). The constructor fits a surrogate only if **both** `QueryPoint` and `NumImportantPredictors` are given; otherwise `SimpleModel` is empty. Ask the user for `k`; report the surrogate's fidelity (its agreement with the model at the fitted point), and if the fit is poor suggest raising `k` or switching `SimpleModelType` linear→tree.
- **Native preconditions are silent traps.** Curvature splits, standardization, and linear DiscrimType are not enforced by the function and cannot be read back from the fitted model; compute the native measure, then warn the user its validity rests on the training-time assumption (see Decision 2).
- **Render plots in the visible MATLAB UI.** Figures appear in the user's MATLAB desktop; do not create them with `Visible="off"`. If a saved image is also wanted, `exportgraphics` it *in addition*, without hiding or closing the live figure. The user is watching MATLAB; a file on disk is not a substitute for a figure they can see.
- **Set expectations before a slow operation.** Before a long-running call, tell the user in one sentence what is running and that it may take a while; don't leave them watching a silent stall. Runtime is worst on **expensive models** (a handle that runs a network, a GP, a GAM, a large ensemble) and grows with the size of the work: for `shapley`, the **number of query points times the per-prediction cost** (worst when it falls back to **kernelSHAP**); for `permutationImportance`, the **observations × predictors** re-scored each permutation. `counterfactuals` is also typically slow. When a run will be slow, say so and **offer an explicit way to shrink it** — a representative subset of query points for `shapley` (or lower `NumObservationsToSample` for its background, which has a default value of 100), the observation/predictor/permutation levers for `permutationImportance` (see [agnostic-global-importance.md](references/agnostic-global-importance.md)). This is a user choice, **never** a silent drop to fake tractability. And never sell a technique as **fast or cheap**: the honest register is a slowness warning when one is warranted and silence otherwise. Comparative/reduction language is fine ("lower this to cut runtime," "the exact tree/linear path avoids sampling") — an absolute "this is fast/cheap" is not.
- **Keep expensive objects and results in the workspace; do not overwrite them.** A batched `shapley` explainer, a `counterfactuals` result, a fitted `lime` explainer, and `permutationImportance` tables are costly to recompute — assign each to its own named variable and leave it in the workspace. Do not reuse one variable name across runs or intents; that silently destroys a prior result. Overwrite only when a run was erroneous and a corrected run supersedes it — otherwise keep both, so results stay comparable.

## Key Functions

| Function                                                                                                                                                          | Purpose                                                                                                                  | Toolbox                                 | Available From |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | --------------------------------------- | -------------- |
| `shapley` (+ `fit`, `plot`, `swarmchart`, `boxchart`, `MeanAbsoluteShapley`)                                                                                      | Agnostic local + global attribution; batched query points                                                                | Statistics and Machine Learning Toolbox | R2021a         |
| `plotDependence` (a `shapley` object function)                                                                                                                    | Shapley dependence view: a predictor's contribution vs its value                                                         | Statistics and Machine Learning Toolbox | R2024b         |
| `lime` (+ `fit`)                                                                                                                                                  | Agnostic sparse local surrogate (top-k reasons)                                                                          | Statistics and Machine Learning Toolbox | R2020b         |
| `permutationImportance`                                                                                                                                           | Agnostic global importance by accuracy drop; no function-handle path                                                     | Statistics and Machine Learning Toolbox | R2024a         |
| `partialDependence` / `plotPartialDependence` (`Conditional=` for ICE)                                                                                            | Agnostic effect/shape; accepts function handles                                                                          | Statistics and Machine Learning Toolbox | R2020b         |
| `predictorImportance`, `oobPermutedPredictorImportance` (or `TreeBagger` `OOBPermuted*` properties), `DeltaPredictor`, `Coefficients`, `Beta`, `plotLocalEffects` | Native tree/ensemble/discriminant/linear/GAM measures                                                                    | Statistics and Machine Learning Toolbox | R2021a         |
| `plotAdjustedResponse`, `plotInteraction` (`LinearModel` object functions)                                                                                        | Native closed-form effect shape for a `LinearModel`: one predictor / a pair                                              | Statistics and Machine Learning Toolbox | R2012a         |
| `counterfactuals`                                                                                                                                                 | Minimal actionable change to flip a prediction (binary classification only; slow, verbose)                               | Statistics and Machine Learning Toolbox | R2026a         |
| `minibatchpredict`, `scores2label`                                                                                                                                | Correct `dlnetwork` encoding and score-to-label conversion for the custom-model handle (example only)                    | Deep Learning Toolbox                   | R2024a         |

Gate `counterfactuals` by the running release; the core agnostic surface is long-standing.

## Scripts

Shipped with this skill in `scripts/`. Derive `SKILL_DIR` from the location of this SKILL.md and call via the MATLAB MCP server with `project_path` set to `SKILL_DIR/scripts`.

| Script | Input | Output | Purpose |
|--------|-------|--------|---------|
| `functionHandleMap(mdl)` | a model object or a prediction function handle | table with `Function` and `NeedsFunctionHandle` (`no` / `yes` / `not supported`) per interpretability function | Decide the handle question per function when selecting the technique (Decision 2, Step 2), without trial-and-error. |

Example call: `functionHandleMap(mdl)` with `project_path` = `SKILL_DIR/scripts`.

## Reference Index

- [custom-model-wrapper.md](references/custom-model-wrapper.md) — correctness-critical procedure for interpreting a custom / non-SMLT model through a prediction function handle; worked `dlnetwork` example. Load whenever `functionHandleMap` marks a routed function `yes` (a prediction handle is needed).
- [agnostic-global-importance.md](references/agnostic-global-importance.md) — `permutationImportance` vs `shapley` importance, bar vs summary view, and the data-availability ladder. Load for "which predictors matter."
- [agnostic-local-explanation.md](references/agnostic-local-explanation.md) — local `shapley` vs `lime`, construct-once/fit-per-point, fidelity-driven k. Load for "why this prediction."
- [agnostic-effect-shape.md](references/agnostic-effect-shape.md) — PDP, ICE, Shapley dependence, and two-predictor views. Load for "shape of the effect."
- [native-importance-measures.md](references/native-importance-measures.md) — model-native importance measures per family, with their training preconditions. Load only for the Decision 2 Step 1 importance-with-no-data trigger.
- [cohort-analysis.md](references/cohort-analysis.md) — per-cohort Shapley and shift-sensitive comparison. Load for "how does behavior differ across groups."

----

Copyright 2026 The MathWorks, Inc.

----