Monitors

Data quality in AIMO is expressed as monitors: named checks tied to a table, usually to one or more columns. Each monitor type is a small, well-defined building block. The agent does not run arbitrary SQL from the UI; it runs structured monitor definitions that compile into a known family of aggregate queries. Which monitor types apply to a table, and with what arguments, is determined by AIMO during onboarding—not chosen from a catalog in the UI.

Violations and outlier baselines

Many monitors emit counts or aggregates per time window (nulls, duplicates, out-of-range values). Outlier detection flags unusual changes in those series. If violations are common but stable, the model adapts; alerts usually appear when levels shift, not merely because violations exist every period. See Outlier detection.

Why a strict set of monitor types matters

AIMO uses a closed set of monitor classes:

• Predictable database access — Each monitor maps to a constrained pattern: aggregates and conditional counts from reflected columns, not an open SQL console.
• Controlled commands — SQL is generated from monitor definitions, with grouping by time block and optional dimensions—reviewable shapes, not ad-hoc automation strings.
• Schema-backed definitions — Definitions must conform to each monitor type’s schema. Custom SQL appears only in SQLQueryMonitor, under strict shape rules: a single aggregate in a fixed outer query; no arbitrary multi-statement batches.

That fixed vocabulary is the only query shape the platform generates for monitoring.

Assignment and validation

1. Assignment — For each table, AIMO chooses monitor types, names, column bindings, and arguments (bounds, allowed values, patterns). RowCountMonitor is always part of the baseline volume picture.

2. Validation — Before monitors are production-ready, the agent can run Validate monitor artifacts. It checks time-block expressions and dimensions and, where relevant, runs the same grouped query shape as production with a minimal read so SQLQueryMonitor fragments and other artifacts are proven against your schema (and at least one row when required).

AIMO assigns, the type system constrains, and your database confirms executability.

What appears in charts

Raw row payloads are not sent to AIMO for monitoring; the product works from aggregates per time window and optional dimensions. SQLQueryMonitor returns the single aggregate defined for that monitor, still within the grouped shell. To inspect individual rows, query your database on your side.

Monitor types

Names match the implementation; configuration uses monitor_type.

NullMonitor

Per window, counts rows with NULL in the chosen column (via total minus non-null). Useful for missingness spikes when pipelines or defaults change.

RowCountMonitor

Total row count for the table—the volume baseline. Drops often indicate failed or partial loads; sharp growth may indicate duplication or runaway inserts.

UniqueMonitor

How far the column departs from uniqueness: count of non-unique values (non-null total minus distinct non-null). Strong on identifier-like columns; noisy on natural dimensions—AIMO applies it where it fits the table’s shape.

RangeMonitor

Counts values outside a numeric or literal range (range_min, range_max). Bounds are constants (including fixed date/time strings where appropriate)—not dynamic SQL in the bound fields. Relative-time checks belong in SQLQueryMonitor if the product assigns one.

CategoricalSetMonitor

Counts values not in an allowed closed set of strings for low-cardinality fields.

PatternMonitor

Counts values whose text does not match a regular expression—format consistency; semantics are not validated. Behavior follows your database’s regex dialect.

SQLQueryMonitor

Evaluates one custom aggregate expression as SQL, embedded in the same grouped monitoring query as other monitors. Typical outer shape: SELECT <aggregate> AS monitor_result FROM … GROUP BY time block [and dimensions]. Use for cross-column logic, conditional counts, KPI-style aggregates, or time-relative predicates inside the aggregate when fixed monitor fields are insufficient.

Guardrails — The expression must be a valid single-column aggregate for your dialect—not a full SELECT, CTE, join graph, or multiple aggregates. The product enforces a single aggregate and rejects invalid fragments. This is not an open SQL shell: one approved slot in a fixed outer shape, with static validation on the agent when artifacts are validated.

Summary

Monitor	In brief
NullMonitor	Missing values per column
RowCountMonitor	Table size (volume baseline)
UniqueMonitor	Departure from uniqueness / duplicates
RangeMonitor	Values outside literal min/max bounds
CategoricalSetMonitor	Values outside an allowed label set
PatternMonitor	Text not matching a regex
SQLQueryMonitor	One custom aggregate in the fixed shell

For job types that execute these definitions, see Operations.