# Data-quality checks that open review items instead of silently passing

> Scheduled data-quality checks, reports with human sign-off, governed ad-hoc analysis, and pipeline triage runbooks — agents that complement your warehouse, not replace it.

- Canonical: https://www.brahmalabs.io/use-cases/data-analytics/
- Department: Data & Analytics
- All departments: https://www.brahmalabs.io/use-cases/

## The reality in most data teams

Data quality gets checked when someone notices a dashboard looks wrong. Freshness alerts cover the big tables; the long tail of feeds is validated by whoever happens to query them. Recurring reports consume analyst mornings — the same joins, the same formatting, the same distribution list. Ad-hoc requests arrive in DMs, get answered from a hurried query, and leave no record of what was run or what it cost. When a pipeline fails at 2 a.m., the runbook is a doc someone wrote two reorgs ago.

None of this is a gap in the warehouse. The warehouse is fine. The gap is the recurring, judgment-adjacent work around it — checking, drafting, triaging — too routine for an analyst's full attention, too consequential to skip.

## What changes with governed agents

Brahmalabs runs that work as scheduled, auditable workflows. Checks run on a cadence whether or not anyone remembers them. Every anomaly becomes a review item in a Data Table — a queue with an owner, not a Slack message that scrolls away. Report drafts are staged as versioned artifacts and park durably on their approval; a run waiting for sign-off burns no compute. Ad-hoc questions become governed runs with a spend ceiling and a per-run cost shown as a labeled estimate, so a "quick question" has a visible price. Agents query inside sandboxed containers with network egress pinned to an allowlist, and credentials arrive from the vault as short-lived scoped references — a prompt never holds a warehouse password.

The boundary, stated plainly: this complements your warehouse and BI stack. Modeling stays where it lives today; dashboards stay in your BI tool. Brahmalabs handles the agent work around them, with a record.

## What stays human

Every workflow here has a named gate. An engineer confirms or dismisses each anomaly. A lead approves each report before distribution — the agent cannot send on its own. An analyst reviews ad-hoc answers and the queries behind them. On-call decides every remediation; agents diagnose and propose. The append-only audit log records who approved what, and when. Agents propose; humans decide.

## The workflows

### 1. Scheduled data-quality checks

- **Trigger:** A schedule fires per feed or table on its expected cadence, with overlap policies so a late run does not stack behind the next one.
- **Flow:** An agent in a sandboxed data container queries the source and runs freshness, volume, and null-rate checks against declared expectations, classifying each result as pass or anomaly.
- **Human gate:** Anomalies open review items in a Data Table queue for a data engineer to confirm, annotate, or dismiss — nothing silently passes.
- **Output:** A row per check in the Data Table with status, metrics, and a link to the run trace; anomalies carry an open review item.

### 2. Recurring reports with sign-off before distribution

- **Trigger:** A weekly or monthly schedule starts a run for each recurring report.
- **Flow:** The agent pulls the period's figures from approved sources, drafts the report with each number's origin attached, flags deltas beyond set thresholds, and stages the draft as a versioned artifact.
- **Human gate:** The analytics lead reviews the draft in the approval inbox and must approve before distribution; rejection returns it with notes while the run waits durably.
- **Output:** An approved, versioned report artifact sent to its recipients, with the sign-off recorded in the audit log.

### 3. Ad-hoc analysis requests as governed runs

- **Trigger:** A stakeholder submits a question through a form or a Slack message.
- **Flow:** The agent scopes the question, queries approved sources inside an egress-controlled sandbox under the workflow's spend ceiling, and drafts an answer with the queries it ran attached.
- **Human gate:** An analyst reviews the draft answer and the queries behind it before anything goes back to the requester.
- **Output:** A reviewed answer delivered with its supporting queries and a per-run cost shown as a labeled estimate.

### 4. Pipeline-failure triage runbooks

- **Trigger:** A failure webhook from your orchestrator opens a triage run, deduplicated by idempotency key so retries do not fan out.
- **Flow:** The agent searches the runbook knowledge base with search_kb, pulls the failing job's logs, matches the error against known failure modes, and drafts a diagnosis citing the runbook passage it used.
- **Human gate:** The on-call engineer decides the fix — the agent proposes diagnosis and remediation steps but executes nothing against production.
- **Output:** A triage row in a Data Table with diagnosis, cited runbook source, and log excerpts, ready for the on-call decision.

## Platform pieces this leans on

- Data Tables
- Durable runs + schedules with overlap policies
- HITL approvals with reviewer inbox
- Vector knowledge base + search_kb
- Egress-controlled sandboxes
- Spend ceilings per workflow
- Per-run cost as a labeled estimate
- Append-only audit log

---

Brahmalabs — the AgentOps platform for production AI agents. https://www.brahmalabs.io