Smart Volume Assertion Anomaly Model: Bulk-Resolving False Positives and Understanding the Training Window – DataHub Customer Support Portal

Area: Observability Issues

Sub-Area: Smart Assertions / Anomaly Detection

Issue

After enabling Smart Volume Assertions on datasets, users may observe poor-quality forecasts — specifically, predicted bands that are shifted or misaligned relative to actual data trends — resulting in a large number of false positive anomalies. This commonly occurs when assertions are evaluated before sufficient historical data has accumulated (the minimum recommended training window is 30 days), or when the model was trained on a short history that included noisy or unrepresentative data points. Because failed checks are logged as anomalies and anomalies are excluded from training until explicitly marked as normal, the model can fail to self-correct without manual intervention. Additionally, when false positives span many datasets and time ranges, marking each anomaly individually through the UI is impractical at scale.

You Might Be Asking

Why are my Smart Volume Assertion forecasts shifted or projecting higher/lower than my actual data trend?
How long does the anomaly model need to train before producing reliable forecasts?
Will retraining the model discard my historical data?
Is there a way to bulk-resolve hundreds of false positive anomalies without clicking each one individually in the UI?
After I mark anomalies as normal, will the model automatically retrain and correct itself?
Does a model update require a full platform upgrade?

Solution

Understand the minimum training window.
Smart Volume Assertions require at least 30 days of historical data to reliably learn trend and seasonality patterns. On older releases of the anomaly model, alerting could begin after as few as 7 days of history. Newer releases enforce a minimum 14-day window before alerting starts, and 30–60 days of clean data is recommended for high-quality forecasts. If your assertions were created recently, forecast quality will improve naturally as more data accumulates.
Understand why false positives compound.
Failed assertion checks are logged as anomalies, and anomalies are automatically excluded from model training until a user explicitly marks them as normal. This means that once the model begins producing false positives, it cannot self-correct without intervention — the excluded periods create a feedback loop that keeps the forecast band misaligned.
Use the Tune Predictions dialog to exclude noisy training data.
Open the Tune Predictions dialog for the affected assertion. Use the drag-to-exclude feature to highlight any noisy or unrepresentative early data points (e.g., an isolated spike during an abnormal period). Then select Include Metrics to mark a range as normal, or use the exclusion window controls at the bottom of the dialog for recurring periods such as weekends or maintenance windows. Exclusion windows are non-destructive — they act as filters applied at training time and do not permanently delete historical data.
Retrain the model — your historical data is preserved.
Retraining re-fits the model using the full stored history, respecting any exclusion windows you have configured. No historical data is discarded. After retraining, assertion checks that previously failed should begin passing once the forecast band aligns with your actual data trend.
Bulk-resolve false positives using the UI drag-select method (recommended for visual review).
In the Tune Predictions dialog, drag your cursor across the red (failed) range and click Include Metrics. This marks the entire selected range as normal and triggers a retrain in a single action — one drag operation per assertion. This approach lets you visually verify whether each range represents a true failure or a poor forecast before resolving it.
Bulk-resolve false positives programmatically using the GraphQL API (for large-scale automation).
If you need to resolve anomalies across many assertions without UI interaction, use the bulkUpdateAnomalies GraphQL mutation. This accepts a monitor URN, assertion URN, a time range (as Unix milliseconds), and a feedback state. Set state: REJECTED to mark anomalies as false positives (not an anomaly). This can be scripted to iterate over multiple assertions.

Send a POST request to your DataHub GraphQL endpoint:
```
POST https://<your-instance>.acryl.io/api/graphql
Authorization: Bearer <your-api-token>
Content-Type: application/json

{
  "query": "mutation BulkRejectAnomalies($input: BulkUpdateAnomaliesInput!) { bulkUpdateAnomalies(input: $input) { timestampMillis } }",
  "variables": {
    "input": {
      "monitorUrn": "urn:li:monitor:(urn:li:dataset:(urn:li:dataPlatform:<platform>,<dataset-name>,PROD),urn:li:assertion:<assertion-id>)",
      "assertionUrn": "urn:li:assertion:<assertion-id>",
      "startTimeMillis": <start-epoch-ms>,
      "endTimeMillis": <end-epoch-ms>,
      "state": "REJECTED"
    }
  }
}
```
Replace the following placeholders:
- <your-instance> — your DataHub Cloud instance subdomain
- <your-api-token> — a valid DataHub personal access token
- <platform> — the data platform (e.g., bigquery, snowflake)
- <dataset-name> — the fully qualified dataset name
- <assertion-id> — the UUID of the assertion (found in the assertion URN in the UI or via API)
- <start-epoch-ms> and <end-epoch-ms> — the time range of false positives to resolve, in Unix milliseconds
To script this across many assertions, retrieve all assertion URNs for your datasets first using a GraphQL dataset query, then loop through each, calling bulkUpdateAnomalies with the appropriate time range.
Verify the model retrains after marking anomalies as normal.
After marking false positives as normal (either via the UI or the GraphQL mutation), the model will retrain at its next scheduled training cycle. Subsequent assertion checks should pass once the model has been re-fitted on the corrected training data. You can confirm the fix is working by monitoring assertion results in the DataHub UI after the next scheduled check.
Obtain model improvements via a platform version upgrade.
Improvements to the anomaly detection model (such as the 14-day minimum alerting window, more accurate growth-rate projection, and tighter default bounds) are bundled with DataHub Cloud platform releases — they cannot be applied independently. When your instance is upgraded to the current release, existing assertions will carry over their history and previously marked normal points, and will pick up the new model behavior at their next scheduled training cycle rather than starting from scratch. New assertions created after the upgrade will wait 14 days before beginning to alert.

Additional Notes

The bulkUpdateAnomalies GraphQL mutation is the only programmatic path for bulk anomaly feedback at this time; a dedicated bulk method is not yet available in the DataHub Python SDK. The UI drag-to-include approach in the Tune Predictions dialog is the recommended method when you want to visually inspect each time range before resolving. Using state: REJECTED marks anomalies as false positives (not an anomaly); use state: RESOLVED if you want to acknowledge a true anomaly as addressed. Model retraining behavior and training window requirements may vary between DataHub Cloud releases — consult your DataHub representative for the specific behavior on your instance version.

Issue

You Might Be Asking

Solution

Additional Notes

Related Documentation