> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.umnai.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.umnai.com/_mcp/server.

# Identifying and addressing low data coverage

Low data coverage occurs when some regions of the problem space have too little training data.

These sparse regions can make model behaviour harder to trust. A model may perform well overall while still being unreliable in areas where the training data is scarce.

## Why low data coverage matters

Areas of low data coverage can create several modelling and explanation challenges.

| Challenge                      | Description                                                                                                             |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| Poor generalisation            | Models trained on sparse data may not generalise well to new queries in low-coverage regions.                           |
| Overfitting                    | With limited data, the model may overfit to noise or specific patterns in the available data.                           |
| Bias                           | Sparse regions may lead the model to learn skewed patterns that do not represent the broader population.                |
| High variance                  | Predictions in low-coverage areas can be more variable and uncertain.                                                   |
| Misleading metrics             | Overall evaluation metrics may look good while performance is poor in sparse regions.                                   |
| Difficulty detecting anomalies | Sparse data makes it harder to establish what normal behaviour looks like, which can make anomalies harder to identify. |

## Identifying low data coverage

Umnai provides two main ways to identify low data coverage: [histograms](../explanations/global-explanations/dataset#histograms) and [activations](../explanations/local-explanations/predictions-and-attributions#activations).

### Histograms

Histograms visualise the distribution of data across one or more features.

By inspecting histograms, sparse regions can be identified and compared with real-world knowledge and expectations.

For example, sparse data coverage in the `30-40` age group may be an issue that needs to be addressed. Similar coverage in the `80+` age group may be less concerning if it is consistent with population demographics.

### Activations

Aggregated activations show the distribution of data across the [partitions](../explainable-neural-net-xnn#partition) of each [module](../explainable-neural-net-xnn#module).

This is similar to using histograms, but with an important difference: the [bins](../explainable-neural-net-xnn#bins) are defined by partition boundaries learned during induction.

Inspecting activations across each module and comparing them with real-world knowledge can identify partitions with low data coverage.

## Addressing low data coverage

The most direct response to low data coverage is to collect or generate more data for the sparse region.

This is not always possible, especially in the short term. In those cases, activations provide another route for review.

Once a low-coverage partition has been identified, its behaviour can be inspected using [module dependency plots](../explanations/global-explanations/module-dependency-plot) and [rules](../explainable-neural-net-xnn#rule). This helps determine whether the partition [conforms to real-world expectations](./model-behaviour#conformance-to-expected-behaviour).

If the partition behaviour appears dubious or untrustworthy, a [decision workflow](../decision-space) can be built to handle queries that activate that partition.

## Corrective actions

Any query that activates a low-coverage or untrusted partition can be identified from its [activation data](../explanations/local-explanations/predictions-and-attributions#activations).

Once identified, corrective action can be taken.

| Action                                 | Description                                                                     |
| -------------------------------------- | ------------------------------------------------------------------------------- |
| Collect or generate more data          | Improve coverage in the sparse region.                                          |
| Inspect partition behaviour            | Use MDPs and rules to decide whether the low-coverage region behaves plausibly. |
| Adjust attribution through a workflow  | Automatically correct or adjust the attribution from the affected partition.    |
| De-automate to human review            | Route affected decisions to a human when automation is not appropriate.         |
| Apply an application-specific response | Use the response that best fits the risk, policy, and operational context.      |