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.

Every monitor on a table compiles into one bounded query: a single aggregate column per monitor, grouped by time block. SQLQueryMonitor is the only free-text slot, and even it is one approved aggregate inside the same fixed shell.

The diagram captures the central idea: a closed vocabulary of monitor types on the left becomes one grouped aggregate query on the right. Each active monitor contributes exactly one aggregate column; the query groups by a time block (and optional dimensions) over a subquery of your table. The only place free text enters is SQLQueryMonitor, and it is still a single aggregate dropped into the same shape. The query runs under read-only database credentials and returns aggregates per time window—never raw rows.

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.

Counting the complement (invert)

Most count-based monitors accept an invert flag that counts the complement instead—present values rather than nulls, distinct rather than duplicate, in-range rather than out-of-range, in-set rather than out-of-set, matching rather than non-matching. This is useful for very sparse columns, where tracking the small number of meaningful values is clearer than tracking the large number that pass. A few monitors (RangeMonitor, CategoricalSetMonitor) can also be refined from your database—AIMO seeds bounds or the allowed set from the column’s actual values.

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.

The authoritative protection is that the agent connects with read-only database credentials, so a malformed expression cannot write or drop data—see Security. As defense in depth on top of that role, the agent rejects any expression containing statement separators (;), SQL comments, or DDL/DML/admin keywords (DROP, DELETE, UPDATE, CREATE, …) before it ever reaches your database.

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.