The transaction line drops sharply. Did customers stop buying, or did the data stop arriving? The numbers alone cannot answer that. A data-quality annotation puts a known problem beside the values it affects, so the reader can investigate before interpreting the drop as a change in the business.
Why this matters
A dashboard and its data pipeline are often checked in different places. The person reading the dashboard may never see a failed freshness check. Semiotic's data-quality bridge reads dbt and Great Expectations results and turns supported checks into chart annotations, preserving the system and run that reported them.
Read the drop with its context
This synthetic example has fourteen daily readings. The vertical threshold marks the last recorded load; the horizontal band marks the expected range of 800–1,200 transactions. Toggle the annotations to compare the line on its own with the line and those qualifications. The data stays the same.
The vertical marker identifies the last load. The shaded band spans 800 to 1,200 transactions. A duplicate-ID check is listed below the chart.
2 annotations shown. The source checks report a stale feed and a value outside the expected range. The drop alone cannot establish why either condition occurred.
Checks without a chart coordinate
- custom check on "id" has no single chart coordinate; surface it as a chart-level status badge or a row-level mark in your UI
How the alert stays attached to its source
Each annotation carries provenance: who reported the check, its basis, and an available run identifier. Lifecycle metadata records a proposed status and a time-to-live hint. CallingapplyAnnotationLifecycle with a later time changes the treatment of an aging note. The host must refresh that time; the metadata does not start a clock by itself. This demo fixes the clock so its historical sample remains reproducible.
A failed rule is evidence about that rule, not proof of the cause of a business change. The bridge also does not run checks, repair data, or write back to either quality system. Those responsibilities remain with the pipeline and its owner.
Some failures belong beside the chart
A duplicate-ID check has no single time or value to point to. The bridge returns it in unplaced, with a reason, instead of inventing a coordinate. The demo shows that warning in text below the plot. A complete host should display these results too; an empty annotation list does not mean the source passed every check.
Wiring it up
import { fromDbtArtifacts, fromGreatExpectations, applyAnnotationLifecycle, } from "semiotic/ai" const dbt = fromDbtArtifacts({ sources }, { ttlHint: "P2D" }) const ge = fromGreatExpectations(validation, { ttlHint: "P2D" }) const annotations = applyAnnotationLifecycle( [...dbt.annotations, ...ge.annotations], { now: Date.now() }, ) const unplaced = [...dbt.unplaced, ...ge.unplaced] // Pass annotations to the chart; show unplaced as text alongside it.When to reach for it
Use the bridge when a known quality result helps a reader interpret a dashboard or report. Check that its time and value fields match the chart's accessors. For a result that describes the whole dataset, use a visible status message or table. Keep your existing data-quality system to define and execute the tests.
Other places this helps
A delayed sensor, a failed financial reconciliation, and a laboratory value awaiting review all change how a number should be read. A dated, attributable note lets the next reader see the qualification even when they were not present for the original check.