---

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