Module dependency
The Module dependency view describes how a selected model module behaves across values of its input features.
Use it to inspect the relationship between module feature values and attribution, understand how a module changes across sampled input space, and identify the rules or partitions associated with those changes.
When to use
Generate the view
Generate the Module dependency view from a deployed model.
The request needs view_type set to MODULE_DEPENDENCY and module_features set to the module features to inspect.
The Module dependency view does not support feature groups.
Output
The response follows the shared Response structure format.
The Module dependency view returns a single dataframe in view_data.
Interpret the result
The Module dependency view is easiest to read as a sampled behaviour table: start with the selected feature values, then inspect attribution changes and the rules associated with those regions.
Start with sampled feature values
Use input_feature.<feature_name> columns to read the sampled values for each selected module feature.
For a single-feature module, the table can be used to plot attribution against that feature. For an interaction module, the table can be used to inspect how attribution changes across combinations of module feature values.
Inspect attribution values
Use attribution.<target_name> to see the attribution associated with each sampled row.
Use attribution_normalized.<target_name> when you need a normalized value for comparison or visualisation.
If attribution_delta.<target_name> is present, use it to understand how attribution changes between sampled points or relative regions.
Connect changes to partitions
Use module_partition_index, rule_id, and condition_expr_friendly to understand which partition or rule produced a row.
This helps explain why attribution changes across the sampled feature values. When a dependency plot changes sharply, these fields help identify the partition boundary responsible for that change.
Use the output for dependency plots
The Module dependency view is commonly used to build plots.
For a single selected feature, plot input_feature.<feature_name> on the x-axis and attribution.<target_name> on the y-axis. For multiple selected features, use the feature columns to build grouped, faceted, or surface-style visualisations.
Add diagnostic overlays
Use include_saw or include_anomalies when you want diagnostic context alongside the dependency table.
These options can help identify whether parts of a module’s behaviour are strong, uncertain, or associated with anomalous data regions.
Options
The Module dependency view requires module_features and supports options for sampling and enrichment.
Module features
Use module_features to identify the module behaviour to inspect.
The selected features should correspond to a module in the deployed model. Single-feature modules produce a one-dimensional dependency table. Interaction modules can produce rows across multiple feature columns.
Module data
Use module_data when you want the dependency view to be generated from specific input data rather than sampled only from the query context.
This is useful when you want the dependency table to reflect a particular dataset, segment, or scenario.
Sampling controls
Use max_samples, random_seed, and batch_size to control how the dependency table is generated.
max_samples controls the size of the output table. random_seed helps make sampling reproducible. batch_size controls how many query items are processed at once.
Categorical features
Use include_all_categories to control whether all categorical value combinations are included.
Including all categories can make the dependency table more complete, but it can also increase the number of rows when categorical features have many values.
Diagnostics
Use include_saw to include strength and weakness columns.
Use include_anomalies to include anomaly flags. These columns are useful when you want to annotate module dependency plots with uncertainty, strength, or data quality context.
Field reference
The Module dependency view returns a dataframe, so individual columns are not documented as standalone API schema properties. Some columns are dynamic and depend on the selected module features, target names, and selected options.
Core fields
Optional fields
These fields appear when optional enrichment is requested.