Use cases · Data & Analytics

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

Workflows 4 patterns
Human oversight built into every one
All departments /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
01

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.
02

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.
03

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.
04

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

Start with one workflow. The free tier is enough to run a real one — agents propose, your team decides.

Other departments