Data operations platform
The data in system B doesn't match system A.
Today that's a Slack thread: unowned, unaudited, resolved by whoever happened to notice. Control Desk makes it a managed case — detected, diagnosed, graded, and written to an audit trail.
When records diverge across systems, or when a field goes null that shouldn't, or when a schema shifts without warning, Control Desk surfaces the finding, assembles the evidence, and routes it through a deterministic pipeline to a graded outcome. The lifecycle is detect → diagnose → fix → verify: every step is accounted for, every configuration change is audited, and the single AI call in the pipeline is bounded to a fixed taxonomy so its behavior can be tested and its failures attributed precisely.
Nine of the ten runtime pipeline steps are deterministic. The one that calls AI — diagnosis — degrades safely instead of failing: if AI is unavailable or returns something outside the taxonomy, the case is filed as "unknown" with a conservative default action, and the workspace reports the observed fallback rate honestly.
How it works
Control Desk runs every data-quality pass through a ten-step pipeline. Nine steps are fully deterministic — they produce the same output for the same input, always. Step 8, Diagnose, is the single point where AI enters the runtime.
Ingest and normalize (steps 1–3)
Each source system attaches through a connector. A per-source field mapping declares how source fields correspond to canonical ones, and the normalize step converts raw rows into canonical records that all downstream steps can compare uniformly. Four connector types are available now: CSV, JSONL, sample-data, and SQL.
Detect (step 4)
Deterministic detectors run against the canonical records. Cross-system detectors compare records across sources; structural detectors inspect individual records against declared constraints. Every detector is driven by rules that carry severity and scope. Single-source setups run structural checks; configurations with two or more sources add cross-system detection automatically.
Cluster and triage (steps 5–7)
Every finding is fingerprinted to give it a stable identity, then clustered into distinct problem classes. Triage routes each class to one of three lanes: log (low-severity, no action needed), playbook (known pattern, handled by a pre-approved rule), or diagnose (novel, needs AI). Only the diagnose lane proceeds to step 8. At the scale benchmarks — 333,333 entities across three systems, roughly one million records — clustering collapsed 9,834 findings into 4 distinct problem classes, so step 8 ran 4 times. AI spend is proportional to distinct problem classes, not data volume.
Diagnose (step 8 — the single AI call)
One AI call per problem class, not per finding and not per record. The AI's only view of the data is a bounded case file assembled deterministically in step 7. The diagnosis maps to a fixed cause taxonomy and a fixed menu of fix actions, so every outcome is structured and testable. If the AI is unavailable or returns a response outside the taxonomy, the case is filed as "unknown" with a conservative default action. The pipeline never halts; the workspace reports the observed fallback rate, not configured intent.
Grade, persist, and audit (steps 9–10)
Grading scores outcomes along two independently tracked axes: recall (detection completeness, measured entirely by the deterministic detectors) and category accuracy (the AI's precision over detected findings). The two-axis design means a flawed detector lowers recall without contaminating the AI-quality number. All cases, run results, and configuration changes land in an append-only audit trail.
At the smaller run: 29,902 records, 316 findings, 4 problem classes, 4 AI calls. At the larger run: 996,736 records, 9,834 findings, 4 problem classes, 4 AI calls. Records grew approximately 33×; findings grew approximately 31×; AI calls stayed flat at 4. All scale runs use PostgreSQL persistence.
Feature catalog
The table below lists every capability in two states: Available now means code-verified as of 2026-07-16. In development means a design intention without a committed date.
| Capability | Status |
|---|---|
| Detection | |
| Cross-system value-mismatch detection | Available now |
| Cross-system missing-upstream detection — an entity present in one system, absent downstream | Available now |
| Cross-system schema-drift detection | Available now |
| Structural not-null validation | Available now |
| Structural format validation (pattern conformance) | Available now |
| Structural range validation | Available now |
| Declarative, rule-driven detection — every detector is configured by rules with severity and scope; single-source setups run structural checks, two-plus-source setups add cross-system checks automatically | Available now |
| Sync-failure detection via a dedicated sync-event channel — a failed sync is a job-level event, not a field-value signal, and would be handled through its own channel. | In development |
| Diagnosis | |
| Deterministic evidence assembly — a bounded case file is the AI's only view of the data | Available now |
| Single-call AI diagnosis per problem class, against a fixed cause taxonomy and fixed fix-action menu | Available now |
| Safe degradation — diagnosis never halts the pipeline; on any failure it returns "unknown" with a conservative default action and reports the degradation | Available now |
| Honest AI status — the workspace reports the observed diagnosis fallback rate, not the configured intent | Available now |
| Timing-drift diagnosis category — a planned addition to the fixed cause taxonomy. | In development |
| Governance | |
| Staged rule intake — validate and preview a candidate rule without persisting anything | Available now |
| Staged data-source intake — validate a source, preview its canonical records, and run structural checks without persisting | Available now |
| Approve ≠ activate — approval always lands inactive; activation is a separate, deliberate act | Available now |
| Atomic, audited configuration write-back — all-or-nothing writes with a before/after audit trail | Available now |
| Single-administrator authentication gating every write and activation | Available now |
| AI rule miner — mines candidate detection rules from pasted policy or documentation text; every candidate must cite the passage it came from; runs at authoring time only, feeds the same approval gate | Available now |
| Dry-run grading of candidate rules before activation — false-positive check on clean data plus recall check on a planted break | Available now |
| Multi-user roles and permissions — extending the single-administrator model to teams with differentiated access levels | In development |
| Scale | |
| Deterministic clustering of findings into problem classes — one case, one AI call per class | Available now |
| Deterministic triage lanes (log / playbook / diagnose) — only the diagnose lane reaches AI | Available now |
| PostgreSQL persistence path with bulk ingest, proven at ~1M rows | Available now |
| Streaming scale path for 10M+ rows — a refactor of the ingest and detection path for continuous high-volume workloads | In development |
| Self-improving triage — promotion of repeatedly-approved case classes to automatic playbooks, analytics-driven with no AI involved | In development |
| Data & workspace | |
| Four connectors: CSV, JSONL, sample-data, SQL | Available now |
| Canonical normalization via per-source field mapping | Available now |
| Live workspace — on-demand detection runs over active sources, diagnosed case views, rule and data-source viewers readable without login | Available now |
| Ecosystem integrations: orchestration, ingestion, observability, and BI tooling — connecting Control Desk to the systems already in your data stack | In development |
Research and documentation
Three whitepapers describe the method in full — architecture, benchmarks, and evaluation model — with explicit sections on what each paper does not claim.
Substrate, patterns, config: an architecture for domain-neutral data operations
The three-layer split; how domains enter as plug-in data through connectors and field mappings; the single AI call in a ten-step pipeline; and the automated guards that keep the domain-neutral core free of client vocabulary.
AI calls scale with problem classes, not data volume
Deterministic clustering and triage as the mechanism behind 79× and 2,458× AI-call collapse; the full scale tables; and the commercial argument in technical clothing.
Grading an AI that cannot see the answers
How the evaluation harness plants known breaks and mints a secret answer key the diagnosis path cannot read; why recall and AI precision are measured on separate axes; and what an honest passing run proves.