You're on DQLabs (PRIZM): It Ranks Every Issue by Business Impact. Data Workers Ships the Verified Fix
PRIZM by DQLabs finds data quality issues and ranks them by business impact. Data Workers diagnoses, fixes and verifies the cause across your stack, with approval.
Your data quality program runs on PRIZM by DQLabs. Prizm profiles every critical asset, generates rules, and runs freshness, volume, schema, distribution and statistics metrics on a schedule. Enterprise Context gives those assets domains, data products, a glossary and a criticality score that decides where monitoring goes deepest. When a metric drifts, Prizm clusters the alerts into one issue, ranks it by lineage and business impact, maps it to the KPIs it touches, binds it to an SLA and opens a ServiceNow incident for the owner. AI Stewardship risk-scores every action Prizm's agents take. Prizm ranks the issue. Data Workers ships the verified fix: it diagnoses the cause across the source, the pipeline, the lakehouse and the catalog, fixes it behind an approval and proves it held. In this category's language, DQLabs is the smoke alarm, a very well-organized one, and Data Workers is the crew.
Key takeaways
- •Prizm keeps its job. Metrics, rules, scores, issues, SLAs, Enterprise Context and the Stewardship hub stay where your stewards set them up.
- •Prizm's actions change Prizm. Its docs define an action as a change to metadata, quality rules, metrics, schemas, lineage or policy, and list autonomous remediation as advisory only. Data Workers carries the fix into the pipeline that caused the issue.
- •The right fix needs the definition. Data Workers checks every proposed repair against the governed business definition, so a quick quarantine never hides valid data a report needs.
- •One approval, one receipt. A named steward approves the repair in Spellbook. Data Workers queues the rerun through Azure Data Factory, verifies the result and records who approved what and how to undo it.
- •Autonomy per domain. Each domain climbs from L0 manual to L4 autonomous at the pace your team sets.
Prizm ranks the issue. Data Workers ships the verified fix.
Here is a Monday at a property and casualty insurer on Azure: Guidewire ClaimCenter for claims, an Azure Data Factory pipeline landing transactions in ADLS Gen2, Azure Databricks building Delta tables in Unity Catalog, Microsoft Purview holding the business glossary, and a Power BI Loss Ratio report the CFO reviews at 9 a.m. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Fri 23:00 | Guidewire ClaimCenter | A configuration release starts posting subrogation and salvage recoveries to the payment transaction table as negative amounts with txn_type = 'RECOVERY' |
| Mon 01:00 | Azure Data Factory | The claims_nightly pipeline copies the weekend's transactions into ADLS Gen2 |
| 01:40 | Azure Databricks | The notebook activity builds claims.silver.payment_txn and claims.gold.paid_loss_daily; 412 recovery rows worth -$2.1M flow into paid loss and the job succeeds |
| 03:15 | PRIZM by DQLabs | The distribution metric on paid_amount flags negative values rising from 0% to 3.8% and the statistics metric flags the daily sum down 9%; Prizm clusters both into one High issue |
| 03:16 | PRIZM by DQLabs | The Business Impact Visualizer maps the issue to the Loss Ratio KPI; the ServiceNow integration opens an incident for the claims data steward |
| 03:20 | PRIZM by DQLabs | AI Recommended Actions: quarantine records with negative paid_amount, then re-run the job |
| 03:22 | Data Workers | Reads the issue over Prizm's API, traces lineage through the ADF copy activity to ClaimCenter, and finds all 412 rows are RECOVERY rows first seen after Friday's release |
| 03:26 | Data Workers | Maps the blast radius: paid_loss_daily, the reserve adequacy model, the Loss Ratio semantic model and the weekly reinsurance bordereau extract |
| 03:30 | Data Workers | Checks the business rule the steward recorded from the Purview glossary term: Paid Loss is gross of recoveries, which report in claims.gold.recoveries_daily. Quarantine would drop $2.1M of valid recoveries from that report |
| 03:41 | Data Workers | Proposes the repair in Spellbook: a notebook diff routing RECOVERY rows to recoveries_daily, an accepted-values check on txn_type, a rerun of claims_nightly and a note to the ClaimCenter owner. A Teams card posts the finding; the approval request reaches the steward by email |
| 07:45 | Spellbook | The steward reviews the diff, the definition and the blast radius, and approves; the data engineering lead merges the notebook change in the Databricks Git folder |
| 07:55 | Azure Data Factory | Data Workers queues the claims_nightly rerun |
| 08:20 | Azure Databricks | The monitor_metrics baselines show both gold tables on time and paid loss back in range; the owner's query matches paid loss to ClaimCenter gross payments and finds 412 rows worth $2.1M in recoveries_daily |
| 08:25 | PRIZM by DQLabs | The next metric run is back in band; the steward resolves the ServiceNow incident with the receipt link, and Prizm imports the resolution and closes the issue |
Prizm did its job well. It caught a change no test was written for, on a column it had flagged as critical, tied it to the KPI the CFO reads and named the owner. Its recommendation was sensible for a column that suddenly holds negative payments. What Data Workers added was the cause (a ClaimCenter release no Prizm metric records), the one fact that made quarantine wrong (the Purview definition of Paid Loss), one approved change set and a 9 a.m. report with the right number and recoveries where finance expects them.
| Job | What Prizm does | What Data Workers does |
|---|---|---|
| Detection | Freshness, volume, schema, distribution and statistics metrics, AI-generated rules and drift detection | Watches freshness, volume and schema across sources and pipelines |
| Prioritization | Clusters alerts into issues, ranks them by lineage, usage and criticality, maps them to KPIs | Joins the issue to history with get_incident_history, so a repeat break arrives with the last fix attached |
| Root cause | Walks lineage inside the assets Prizm catalogs, including Airflow runs and merged GitHub changes | Traces past the lakehouse into the pipeline and the source application, and checks the fix against the governed definition |
| The fix | Recommends next steps such as re-running a job, a default value or quarantine | Proposes the complete repair: the code diff, the guard check, the rerun and the upstream change for its owner, with blast radius |
| Running it | Your engineers apply the change | A named steward approves in Spellbook; Data Workers queues the rerun through Azure Data Factory |
| Verification | The next metric run returns to band | Checks freshness, volume, totals and quality on every table the fix touched |
| The record | The issue with reason code, resolution note, SLA history and the Stewardship audit log | A receipt: the cause, the diff, who approved it, what it touched, how it was verified and how to undo it |
Why doesn't DQLabs just do this itself?
Because DQLabs drew a clear line around where its agents act, and it is the right line for a quality platform. Prizm's AI Stewardship page defines an action as "a change to metadata, quality rules, metrics, schemas, lineage, or policy." Each action is risk-scored by its sensitivity times the asset's criticality before it runs or waits for a steward. On remediation, the platform overview lists autonomous remediation as "advisory only," and the AI capabilities page describes Autonomous Issue Resolution as a recommendation validated in staging first. Self-healing pipelines sit in DQLabs' Multi-Agent Agentic AI Data Management item, marked Private Beta with a public waitlist.
DQLabs speaks a language close to ours, a swarm of specialized agents with automation set per domain, and we respect that. The difference is scope. Prizm governs the actions it takes on its own model of your data. Monday's fix needed a Databricks notebook change, an ADF rerun, a Purview definition, a note to the ClaimCenter team and a check on a reinsurance extract, each owned by someone else. Acting across those systems takes blast-radius scoping, an owner's approval, an undo written before anything runs and a record an auditor can read. For a quality platform pointed at every critical table, taking on that liability would change what it is. Data Workers is built for exactly that job.
Every tool owns a slice. Data Workers covers the whole lifecycle
DQLabs owns data quality and observability, and goes deep on both. Each point tool adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on Prizm where your stewards already look.
| Stage | Data Workers | DQLabs | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 7 | Enterprise Context gives Prizm domains, products, a glossary and criticality scores. Data Workers keeps one governed context graph across every platform and catalog. |
| Analytics & Insights | 8 | 4 | Converse and dashboards answer questions about data health. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 9 | DQLabs' home stage: AI-generated rules, profiling, distribution and statistics metrics, and quality scoring by asset. Data Workers also runs and repairs checks across every platform. |
| Observability & Incidents | 8.5 | 9 | DQLabs' home stage: drift detection, alert clustering, Airflow pipeline RCA and the Business Impact Visualizer. Data Workers fixes the data across systems with approval and verifies it. |
| Pipelines & Ingestion | 8.5 | 4 | Prizm catalogs Airflow pipelines and its circuit breaker can stop a DAG. Data Workers queues reruns through your orchestrator and proposes the code or source change for its owner. |
| Schema & Migration | 8 | 4 | Schema metrics catch structural drift. Data Workers catches schema changes at the source, scores their blast radius and plans migrations in waves. |
| Governance & Access | 8.5 | 5 | Domains, stewardship modes and RBAC govern Prizm's own actions. Data Workers runs the warehouse access request queue with time-bound, approved grants. |
| Security & Privacy | 8 | 5 | PII classification is a governed Prizm action, and MCP tokens are scoped by tool. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 3 | Credits and usage metrics show consumption. Data Workers attributes warehouse spend and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 3 | Drift monitoring protects model inputs. Data Workers keeps the data under your models fresh and correct. |
DQLabs leads on its two home stages, as it should. For the category view, read how Data Workers differs from data observability and beyond data observability: autonomous resolution.
How DQLabs and Data Workers work together
Prizm stays on top, where metrics run, issues are raised and stewards are assigned. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, who approved it and how to roll it back. Underneath, Data Context Wizard keeps one governed context graph across Databricks, ADF and the rest of the estate, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor runs each fix end to end: detect, diagnose, fix, review, verify, remember.
Prizm to Data Workers. DQLabs connects over its API or MCP server today: your team's assistant reads issues, alerts, metrics and lineage side by side with Data Workers, whose own checks rest on ADLS, Azure Data Factory and dbt. It reads ADLS and Azure Data Factory natively and applies Unity Catalog grants; Microsoft Purview, Guidewire and Power BI connect over their APIs today. A new Prizm issue starts a diagnosis: diagnose_incident and get_root_cause work the evidence, trace_cross_platform_lineage follows the failure past the Delta table to the source, blast_radius_analysis maps everything downstream, explain_table pulls each table's definition and documentation, and get_incident_history checks for repeats. The repair runs through remediate: code changes go to the owner as a diff to merge, and reruns are queued through Azure Data Factory. monitor_metrics baselines and the DQLabs checks verify, and every step lands in get_audit_trail.
Data Workers treats each Prizm recommendation as a hypothesis and tests it against the estate and the governed definition. Prizm keeps the issue, the SLA and the ServiceNow link.
Side by side in one client. Prizm issues MCP access tokens from Settings, Organization, Access Tokens; each carries an expiry and the Prizm tools it may call, and copying it returns a ready mcpServers entry. Add Data Workers beside it using the documented path in the client setup guide: clone the open-source repo and add one start-agent.sh entry per agent. Example for Cursor's .cursor/mcp.json, with the Prizm entry in the form DQLabs documents:
{
"mcpServers": {
"prizm-ai": {
"command": "/bin/bash",
"args": ["-c", "while true; do npx mcp-remote https://<your-prizm-host>/mcp/ --header 'Authorization: Basic <MCP_JWT>'; sleep 10; done"]
},
"dw-context-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
"dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
"dw-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] }
}
}Ask "why did paid loss drop overnight, and what does the fix touch?" and the client calls both: Prizm returns the drifted metrics and the lineage it holds; Data Workers returns the ClaimCenter cause, the Paid Loss definition and a proposed repair with its blast radius. Scope the Prizm token to read tools such as search_assets and get_lineage. For a shared endpoint, the Data Workers remote server serves /mcp with an API key (bearer) or OAuth tokens from your identity provider, such as Entra ID, verified through JWKS.
One Prizm issue, L0 to L4, set per domain.
- •L0 manual. An engineer applies the quarantine and finds out on Tuesday that recoveries are missing.
- •L1 observe. Data Workers posts the diagnosis: the release, the 412 rows, the definition conflict, everything downstream. Nothing changes.
- •L2 propose. Data Workers proposes the diff, the guard check and the rerun; nothing runs until the steward approves.
- •L3 act reversibly. For change classes with a proven record, such as a rerun after a merged fix, Data Workers queues the step, verifies it and records the receipt.
- •L4 autonomous. In a scoped domain with a long clean record, Data Workers handles the repeatable steps end to end; code changes still go to their owner.
Prizm's own levels (Human to AI Completed) govern changes inside Prizm; the Data Workers ladder governs changes to the data and pipelines. Read is it safe to let AI agents change production data and how approvals work. On where data lives: the agents run in your infrastructure, your data stays in your systems, and the hosted Conductor sees workflow metadata only.
What changes for your team
Prizm gave every critical asset a score, an owner and an SLA. Data Workers gives those owners a crew for the fix.
- •Incidents. A Prizm issue gets a cross-system diagnosis, a blast radius and a proposed fix, and closes with a receipt.
- •Data quality. Each fix leaves a guard check in the step that broke, and Prizm's metrics confirm it held.
- •Cloud spend. Warehouse spend is attributed to the jobs behind it, and fixes go to their owners drafted.
- •Access. A lakehouse access request becomes a scoped, time-boxed grant the owner approves; in Unity Catalog the approved grant is applied for you.
- •Audits. Prizm logs its own actions; Data Workers records what changed in the data, who approved it and how to undo it.
- •Migrations. A move off a legacy warehouse runs in approved waves, with parity checks planned and tracked per wave.
The steward changes most: one proposal to review at 7:45 a.m., evidence attached, instead of a morning chasing three teams through a ServiceNow thread. See who owns the agents.
Keep DQLabs, or consolidate?
Keep DQLabs if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most Prizm teams keep it; what they consolidate is the work around it: hand-written fix scripts, a runbook wiki, a second monitor alerting on the same break. If you are weighing building the fix layer yourself on Prizm's MCP server and a coding agent, read build it ourselves with Claude Code and MCP servers: the MCP calls are the easy part; the context graph, approvals and rollback are the work. The same pattern holds in you're on Monte Carlo, you're on Bigeye and you're on Ataccama. For this stack, see you're on ServiceNow, Data Workers on Databricks and Data Workers integrations.
The case for your CFO
The outcome: loss ratio, reserves and reinsurance reporting come from claims data Prizm already watches. Data Workers turns each Prizm issue on that data into a diagnosis on arrival and a complete fix with one approval, checked against the definitions finance signed off, so the number is right before anyone presents it.
The risk story is plain. At L1 Data Workers only reads; at L2 it changes nothing until a named person approves; at L3 it applies changes it can undo. Code changes go to their owner as a diff. An unanswered approval expires and escalates, never auto-grants. No agent can promote its own work. Every change carries a receipt: the cause, the diff, the approver, what it touched, how it was verified and how to undo it. An org-wide stop halts all autonomous dispatch. Zero migration: Prizm, ClaimCenter, ADF, Databricks, Purview, Power BI and ServiceNow stay where they are.
Why now: Prizm already finds the issue and ranks it by business impact, so detection is no longer the slow part. The fix is. The first win is read-only: every Prizm issue in one domain, such as claims, gets a cross-system diagnosis and a blast radius. What stays the same: your metrics, scores, stewards, SLAs, Git review and Unity Catalog permissions. See the ROI of agentic data operations.
The sentence to repeat upstairs: "Prizm tells us which claims data broke and what it touches; Data Workers fixes the cause in the pipeline, checked against our definitions, with an approval, and proves it held."
Getting started
Start with a pilot. Pick one domain whose issues already live in Prizm, such as claims, connect Data Workers to Prizm, Azure Databricks, Azure Data Factory and Purview, and run at L1 so every issue gets a diagnosis and a blast radius. Then turn on the first write class at L2, such as reruns after a merged fix, with steward approval. Plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Is DQLabs the same product as PRIZM? PRIZM by DQLabs is the current name of the DQLabs platform, branded "AI-Native Data Observability, Quality and Context" across three pillars: Data Observability, Data Quality and Enterprise Context. The docs call it Prizm.
How does Data Workers connect to DQLabs? Over DQLabs' API or MCP server today, reading issues, alerts, metrics and lineage. You can also run Prizm's MCP server beside Data Workers in Cursor or Claude Desktop and ask both in one conversation.
Prizm already has a swarm of agents and AI Stewardship. Why add Data Workers? Prizm's agents act on Prizm's own objects: metrics, rules, glossaries, domains, schedules and issue links. Many issues start outside those objects, in a source application or a pipeline notebook. Data Workers traces to that cause, routes each change to its owner under one approval, queues the rerun and verifies the result.
What about DQLabs' self-healing pipelines? DQLabs lists them in its Multi-Agent Agentic AI Data Management item, marked Private Beta with a waitlist. Data Workers works across your pipelines today, whatever runs them, with approvals, receipts and rollback.
Which Prizm MCP tools does our assistant need? Read tools cover the diagnosis, such as search_assets and get_lineage. Prizm's MCP tokens list the tools they may call and expire on a date you set, so keep write tools like create_metrics or manage_schedule with the stewards who own them.
Does Data Workers change our ServiceNow incidents, Prizm issues or ClaimCenter? No. Prizm opens and syncs the incident; the steward resolves it with the receipt link, and Prizm imports the resolution and closes its issue. Source changes, such as how a release posts recoveries, go to their owner as a proposal with the evidence attached.
Sources
- •DQLabs homepage ("The Enterprise Platform for Observability, Quality, and Context"), https://www.dqlabs.ai/ (checked Oct 3, 2026)
- •PRIZM by DQLabs product page (page modified Jul 23, 2026), https://www.dqlabs.ai/prizm/ (checked Oct 3, 2026)
- •DQLabs llms.txt (PRIZM branding, buyers, platforms), https://www.dqlabs.ai/llms.txt (checked Oct 3, 2026)
- •DQLabs, Agentic AI Data Management (Private Beta waitlist; page modified Jun 17, 2026), https://www.dqlabs.ai/ai-agentic-data-management/ (checked Oct 3, 2026)
- •DQLabs for Azure (ADLS, Synapse Analytics, ADF, Power BI), https://www.dqlabs.ai/azure/ (checked Oct 3, 2026)
- •Prizm Docs, Platform Overview (autonomous remediation "advisory only"), https://docs.dqlabs.ai/platform/overview.md (checked Oct 3, 2026)
- •Prizm Docs, Multi-Agent Architecture, https://docs.dqlabs.ai/platform/multi-agent-architecture.md (checked Oct 3, 2026)
- •Prizm Docs, AI Stewardship, https://docs.dqlabs.ai/platform/ai-stewardship.md (checked Oct 3, 2026)
- •Prizm Docs, AI & ML Capabilities (as of Jul 23, 2026), https://docs.dqlabs.ai/platform/ai-and-ml-capabilities.md (checked Oct 3, 2026)
- •Prizm Docs, Converse, https://docs.dqlabs.ai/platform/converse.md (checked Oct 3, 2026)
- •Prizm Docs, MCP Access Tokens, https://docs.dqlabs.ai/ai/mcp-access-tokens.md (checked Oct 3, 2026)
- •Prizm Docs, 1.3.3 Release Notes (Airflow pipeline observability, ADLS, Issues, Purview integration), https://docs.dqlabs.ai/Release_Notes_v1.3.3.md (checked Oct 3, 2026)
- •Prizm Docs, 1.3.4 Release Notes (Power BI semantic models, Actions, issue resolution workflow, SLA), https://docs.dqlabs.ai/Release_Notes_v1.3.4.md (checked Oct 3, 2026)
- •Prizm Docs, ServiceNow Integration, https://docs.dqlabs.ai/integrations/servicenow/integration.md (checked Oct 3, 2026)
- •Prizm Docs, Distribution metrics, https://docs.dqlabs.ai/architecture/metrics/distribution/overview.md (checked Oct 3, 2026)
- •Prizm Docs, Issue API, https://docs.dqlabs.ai/api-reference/metrics/issue.md (checked Oct 3, 2026)
- •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)