For teams who must prove their data is fit to use

AI-native data quality.
Human-governed by design.

VigilDQ profiles your warehouse, lets an AI agent draft the quality rules your data actually needs, and structurally refuses to run anything a named human hasn't approved — with the masked pipeline and audit trail to prove it.

Request a demo Download the brochure
0–100one defensible score, six quality dimensions
100%of rules approved by a named human — never the AI
0raw values leave your warehouse — masked at the boundary
2 + 1engines validated live (Postgres, Databricks) · SQL Server next
The VigilDQ scorecard: overall quality 96.0 with six dimension gauges and per-rule results
The problem

AI can draft data-quality rules. It cannot approve its own controls.

In pharma, banking, insurance, healthcare and the public sector, data quality isn't a dashboard — it's a certified control. Hand-writing rules for thousands of tables doesn't scale, and an unguarded LLM fails the first compliance review: hallucinated columns, unaccountable approvals, prompts posing as controls.

An unguarded LLM

Hallucinates columns that don't exist. Slips a write into "read-only" SQL. Approves its own work. Its safety net is a prompt — which is advice, not a control.

VigilDQ's design

Guardrails in the architecture, not the prompt. Every AI proposal is checked against the live catalog, screened for writes, dry-run on the real engine — and can only be activated by a named human.

How it works

From raw table to certified dataset

1 · Profilestatistics + masked samples, computed in-warehouse
2 · Proposethe AI drafts rules, each with a rationale
3 · Reviewa named human approves, edits or rejects
4 · Runread-only SQL, executed inside your warehouse
5 · Score0–100 across six quality dimensions
6 · Evidencefailing rows captured in your own database
Why it's different

Controls, not conveniences

Read-only SQL, always

Every rule compiles to a single read-only query that runs in your warehouse. Lexical screening on top of read-only sessions — rules cannot write. Ever.

Human approval, enforced

The lifecycle state machine only accepts a human approver, identified by their login — never a request payload. AI self-approval is structurally impossible.

Guardrails in code

Live schema check, write screen, dry run on your real engine — every AI proposal passes four gates before it can even be saved as a draft.

Audit trail, complete

Every mutation appended with before/after snapshots and the human behind it. The audit log once rebuilt an entire rule store after an operational incident.

Masking, provable

PII is masked before the AI or the browser sees a value — and a test captures the AI's exact prompt to assert zero raw values. Redact, partial, hash or nullify.

Evidence, target-side

Failing rows are captured into a DQ schema in your own warehouse — capped, fail-soft, masked on display. The auditor's favourite question, pre-answered.

The product, unretouched

What your team actually sees

Every screenshot is the live product — not a mock-up.

Scorecard: overall 96.0, six dimension gauges, per-rule results

The scorecard

One 0–100 score across completeness, uniqueness, validity, consistency, timeliness and accuracy — decomposable to the exact rule and the exact failed count. A rule that errors scores zero, loudly. Nothing is silently skipped.

WHY IT MATTERSA number a steering committee can track, with a drill-down an auditor can defend.
Review queue with AI-drafted rules awaiting human approval

The review queue

AI proposals arrive as drafts, each with a rationale grounded in your data's profile. Approve, edit or reject — and the platform records the named human behind every activation.

WHY IT MATTERSChange control is built in, not bolted on: nothing runs without a human's name on it.
Rule editor showing compiled SQL and raw-SQL override

The rule editor

View the compiled SQL for any rule, per engine dialect. Edit the definition — or override with raw SQL for edge cases. Any logic change is re-vetted by the guardrails and reset to draft for re-approval.

WHY IT MATTERSNo black boxes: your DBAs can read every control, and edits can't bypass review.
Audit log with before/after snapshots for every change

The audit log

Logins, approvals, edits, configuration changes — every mutating action is appended with before/after snapshots and its actor. Append-only at the service boundary; a failed audit write never breaks the request.

WHY IT MATTERSWhen the auditor asks "who approved this control and when?", the answer is one filter away.
Quality score trend over time with anomaly baselines

Trends & alerts

Every load is scored and recorded. Drift rules — row count, null ratio, schema — judge each run against a median baseline; score alerts email your team and webhooks feed your pipeline when quality slips.

WHY IT MATTERSRegressions show up as a bend in a chart — not as a surprise in production.
Security & governance

Built so the answer to "where does my data go?" is "nowhere"

Trust is the product. This is the section your security team will read first — so it goes first in the conversation too.

Data flow

Profiling and rule execution are pushed down into your warehouse as read-only SQL. What VigilDQ stores: scores, rule definitions, masked profile metadata. What it never stores: your rows.

Failing-row evidence

Written to a DQ schema in your own warehouse by a separate, schema-scoped writer grant — never to VigilDQ's store, never to a vendor cloud.

What the AI sees

A masked profile only. Boundary masking has no unmasked code path, and a test captures the AI's actual prompt to prove zero raw values reach it.

Secrets & sessions

Connection credentials Fernet-encrypted at rest; API keys stored only as hashes; JWT sessions with hourly expiry; roles per tenant (admin / reviewer / viewer).

Deployment options

Your VM, your VPC, or fully air-gapped — with a local OpenAI-compatible LLM, nothing leaves your network at all. No SaaS dependency in the architecture.

Roadmap, stated honestly

SSO/OIDC and Postgres row-level security are in active development; SOC 2 groundwork is part of the current plan. Ask us — we'd rather you knew.

Failing-row evidence table with masked names, stored in the customer's own database

The compliance money-shot

Failing rows, captured in your database, PII masked on display — those B*** names are the masking at work. This single screen answers the question that stalls most AI-tooling procurements.

WHY IT MATTERS"Show me the failing rows" — answered without a single value leaving your estate.
Commercial options

Engage the way your procurement works

Pilot

The standard entry: fixed fee, fixed scope, success criteria agreed up front — typically two datasets, six weeks, your environment or ours.

Licensed source

Source-code licensing and escrow available — the regulated-industry answer to vendor-risk and continuity questions.

In-house customisation

Warehouse-native architecture with one dialect seam per engine — extensions and integrations land cleanly, by us or by your team.

Partnering & OEM

Catalog vendors, consultancies and platform teams: talk to us about embedding guardrailed AI data quality in your offering.

Watch it catch bad data — live.

Thirty minutes on our demo warehouse: the agent proposes rules against a real schema, a guardrail refuses a bad rule, and a quality gate stops a bad load. Nothing to install, no access to your systems needed.

Book a 30-minute demo Get the technical review pack

Prefer email? [email protected]