Quality Guardian

How it works

Test it, investigate it, fix it.

Your warehouse

Data-entry tests fail

dbt tests one owner per test Snowflake · BigQuery

Per failing record

The agent investigates

2a read-only SQL 2b web search 2c step budget

Always

A verdict with a confidence score

high medium low

High confidence, own data

Fix written to the source system

fill a field create a row

Everything else

Action card to the test owner

Slack Issue · Found · Action · Where

Product tour

The dashboard, page by page.

Screenshots from the current version, captured 14 September 2026 on our John's Cleaning demo client: a cleaning company whose operations portal, Exact Online, HubSpot, Nmbrs payroll and Mollie all have to agree with each other.

Latest run

One run, one verdict per record

The run header shows the scope it used. Five verdict counters split the records: Ready to fix, New row ready, Possible match, No match, Incomplete. Each row names the object, the proposed fix, whether it was written, and links to the record in its source system.

·Pre-run confirmation states how many records and which tests a run will touch, and whether write-back is on.
·Live progress: every queued record is visible from the first second and fills in as it finishes.
·A running run can be terminated; what finished is kept.
·Export the run as a branded PDF, records needing manual action first.

quality-guardian · johns-cleaningclick to enlarge

Quality Guardian Latest run page: a completed run of three overdue invoices, each ready to fix with the status written back

quality-guardian · johns-cleaning · configclick to enlarge

Manual Config

Every test, every owner, every switch

Tests are grouped per source system, each with its failing count, pass rate and owner, and a link to the failing records. Tick the tests a run should cover, set how many issues to resolve and how many investigation steps each record may take, and choose a random sample or the most recent failures.

·Agent features: model choice (Claude Sonnet 5 by default), one write-back switch per system, web search, Slack reports.
·Settings are stored server-side and shared by everyone who signs in.
·Blank fields fall back to the deployment defaults, so nothing has to be filled in to start.

Schedule

Runs by itself, every morning

Create jobs that run daily, weekly or monthly at an hour you pick, shown in your local time. Each job carries its own run settings, so a nightly sweep can cover every test while a Monday job focuses on invoices only. A scheduled run is labelled with its job name in the logs.

·One job per time slot, checked when you save, so two jobs never silently collide.
·Disable a job to park it without losing its settings.

quality-guardian · johns-cleaning · scheduling · nightly-sweepclick to enlarge

Quality Guardian scheduled job Nightly Sweep, daily at 09:00: its own run settings, entry tests per source system with owners and pass rates, and agent feature toggles

quality-guardian · johns-cleaning · logsclick to enlarge

Logs

What the agent did, step by step

Every run is kept. Pick one and see its model, the number of agent steps, tool calls and tool errors, and how many records were written back. Each record carries two labelled chips: the verdict the investigation reached, with its confidence, and the write-back state: written, dry-run, failed, not configured, skipped as duplicate, or not attempted.

·Expand a record for the full trace: every query it ran, what came back, and the reasoning behind the conclusion.
·Raw JSON of any run is one click away.
·The period report collapses runs over a date range into distinct open issues, with how often each was seen, as a PDF.

After every run

The Slack report: fixed, and to be fixed by whom.

Posted to a channel of your choice after each run. The layout is fixed on purpose: the same four labels on every card, so a test owner can act on it, or paste it into their own assistant.

#data-quality

Quality Guardian APP Today at 9:04 AM

3 fixed automatically · 2 require test owner action

John's Cleaning · 14 Sep 2026, 09:04 · 5 records · Open logs

FIXED ENTRY ISSUES (3)

DET_012 · Invoice INV-2026-05498 · Status set to Overdue · written to John's Portal

DET_012 · Invoice INV-2026-04360 · Status set to Overdue · written to John's Portal

DET_012 · Invoice INV-2026-05718 · Status set to Overdue · written to John's Portal

REQUIRES TEST OWNER ACTION — Marieke de Jong (2)

DET_021-1 · Cleaner Fleur Jansen · Verify, then set

Issue Employed cleaner is not linked to an Nmbrs payroll employee.

Found One Nmbrs employee "F. Jansen" with the same start date and email domain; no employee id stored on the cleaner.

Action Confirm it is the same person, then set nmbrs_employee_id to 10482.

Where John's Portal › Cleaner › cln_7f3a… · Open record

DET_024-1 · Customer Bakkerij De Molen · Create the row

Issue Active commercial customer has no HubSpot company.

Found No HubSpot company matches the name, domain or Exact account code. Customer is active with three jobs this month.

Action Create the HubSpot company with name, domain demolen.nl and the Exact account code 1042.

Where John's Portal › Customer › cus_2b91… · Open record

Your assistant can work from this section as-is, using your own access to the named systems.

Layout as shipped on 14 September 2026. Record details in this example are illustrative.

In production

Freeday runs it every morning.

Freeday builds AI digital employees for customer service and finance teams. Maxq runs their analytics stack: Airbyte, dbt and Cube on Snowflake.

The problem

Freeday's customer data lives in three systems that have to agree: HubSpot for companies and deals, Airtable for operations and the digital employees, Exact Online for invoicing. A company sold in HubSpot but missing in Airtable, or a customer without its Exact account code, means a digital employee that cannot be provisioned or an invoice that cannot be sent. The data-entry tests in their dbt project catch these every morning. Fixing them by hand did not scale.

What the guardian does for them

·Creates the missing Airtable row for a digital employee sold in HubSpot, with the fields taken from the curated warehouse tables.
·Fills the Exact Online account code on a company once it finds the matching account, and knows that internal test companies map to Freeday's own account.
·Proposes an industry for HubSpot companies that have none, looked up on the web, and leaves that one for a human to confirm rather than writing it.

source systems kept in step: HubSpot, Airtable, Exact Online

data-entry tests run every morning, on HubSpot and Airtable entities

daily

scheduled run, with write-back to Airtable and HubSpot switched on

What you get

Everything in the current version.

Entry tests with owners

Plain-language tests per object and source system, each with a named test owner, failing count and pass rate. Defined once in your dbt project; the guardian reads the failures.

Scored investigations

Read-only SQL over curated tables, web search as fallback, a step budget per record, and a verdict with high, medium or low confidence every time. Only candidates from your own data qualify for an automatic fix.

Guarded write-back

Field fills and row creation in Airtable, HubSpot or your operations database. Off by default, one switch per system, dry-run reporting while off, duplicate check before any create, and the outcome stored on every record.

Slack action list per owner

After each run: what was fixed, and a section per test owner with Issue, Found, Action and Where per record. Fixed labels, a link to the record, and a deep link to the run's logs.

Scheduled jobs

Daily, weekly or monthly jobs at the hour you choose, each with its own run settings. One job per slot, enforced when you save. Runs show which job triggered them.

Full trace and audit trail

Every run is kept with its model, steps, tool calls and errors. Per record: the verdict, the write-back state, and the complete investigation trace. Raw JSON on request.

PDF reports

A branded PDF per run, manual-action records first. A period report over any date range that collapses repeated failures into distinct open issues, with how often each was seen.

Login and users

Email and password sign-in for your team, invite links to add colleagues, and a user list to remove them. Nothing is reachable without a session.

Under the hood

Safe by construction.

The model reasons and concludes. Code decides what gets written, and to where.

Warehouse access

Read-only, end to end. A SQL guard limits the agent to single SELECT statements over a fixed allow-list of curated tables, with a row limit appended automatically. Snowflake and BigQuery are supported.

Model

Claude Sonnet 5 by default, Sonnet 4.6 selectable, routed through the Vercel AI Gateway. No static API keys in the deployment.

Writes and notifications

The model has no working write or messaging tool. Write-back and the Slack report are separate, code-controlled steps that run after the conclusion, each behind its own switch.

Hosting and storage

Next.js on Vercel, fully managed. Run history, settings, jobs and accounts live in Vercel Blob storage with versioned keys. No database to run, nothing to install on your side.

Scheduling

Hourly cron ticks, each checking which job is due. The cron endpoint is protected by its own secret and is the only route that bypasses the login.

Concurrency and limits

Up to three records investigated in parallel, each with its own warehouse connection. Configurable record limit and step cap per record, with one reserved step so a capped record still ends with a verdict.

Who it's for

The right fit.

Operations and finance teams whose numbers depend on several systems agreeing with each other: an operations portal, the accounting package, the CRM, payroll, the payment provider. When a customer is missing in one of them, or a status was never updated, the invoice is wrong, the report is wrong, or the automation breaks.

It works best when data-entry tests already exist or can be written quickly, and when there is a named owner per test. The guardian does the investigating and the safe fixes; the owner keeps the judgement calls, with the homework done.

Roadmap

What's coming next.

Next up

Owners addressed directly in Slack

Each owner's section delivered as a thread, mention or direct message instead of one channel post, and a "resolved since last run" count in the header once the previous run's records are re-checked against the tests.

In design

Remediation instructions and revert

Per-test remediation instructions from your data model become the leading input for how a fix is made. And an applied fix can be reverted from the dashboard, because a high-confidence verdict can still be wrong.

Coming later

Fix-rate analytics

Records and fixes aggregated per week, month or quarter, and the share of investigations that led to a fix. Plus a dedicated client domain and several jobs running in parallel.

Pricing

Implementation plus managed service.

Two components. An implementation fee covers writing the data-entry tests for your systems, connecting the warehouse and the source systems, and setting up write-back, Slack and the schedule. An ongoing licence covers hosting, model usage and keeping the tests and the agent maintained.

The licence scales with the number of tests under watch, so a focused setup on invoices and customers pays less than coverage across every system. We scope the exact structure together based on your context.

Implementation fee

Tests, connections, write-back and Slack setup.

Licence fee

Hosting, model usage and maintenance, scaled by tests under watch.

Get a scope

Built and maintained by

The people behind the Quality Guardian.

Philip Boontje

Product Owner

Founder · Maxq Analytics

Philip built the Quality Guardian: the investigation agent, the guarded write-back, the scheduling and the Slack report. He shapes the product around the data-quality problems he sees at Maxq's clients, and runs the demo client it is developed against.

Valentin Cathelain

Developer & Maintainer

Medior Data Engineer · Maxq Analytics

Valentin develops the Quality Guardian with Philip, from test configuration to client-side implementation across environments.