Documentation
Control Desk — Method Overview
Control Desk turns cross-system data mismatches into managed, audited cases. This documentation describes the method: what the system does at each stage, why decisions are made the way they are, and where the boundaries are.
What Control Desk is
When data in system B does not match data in system A, most organizations resolve that in a Slack thread — unowned, unaudited, and invisible the next time the same problem recurs. Control Desk makes that a managed case: it detects the divergence, assembles the evidence, calls for a diagnosis, grades the result, and persists an audit trail.
The operational loop is: detect → diagnose → fix → verify. Each stage is distinct, attributable, and independently grounded — detection is fully deterministic; diagnosis uses exactly one AI call per distinct problem class; grading is deterministic again.
The three-layer architecture
Control Desk is built across three layers, each with a deliberate scope:
- Substrate — the domain-neutral core. It contains the pipeline engine, the detection machinery, the clustering and triage logic, the evaluation harness, and the governance mechanisms. The substrate knows nothing about any client, domain, or data source. An automated guard fails the build if domain vocabulary enters this layer.
- Patterns — reusable configurations and problem-class definitions that sit above the substrate and below a specific deployment.
- Client configuration — the per-deployment layer. A domain enters the system exclusively as plug-in data: a connector (how to read the source) plus a field mapping (how source fields correspond to canonical ones). No substrate code changes when a new domain is added.
This separation is enforced, not documented. The substrate is tested against two unrelated domains; the same unchanged engine ingests both through nothing but field mappings.
One AI call in the loop
The pipeline has ten steps. Exactly one of those steps calls AI: step 8, Diagnose. Every other step is deterministic. This is a design constraint, not an approximation — an automated guard fails the build if an AI client enters the detection, clustering, or triage path.
Keeping AI to a single, bounded call makes the system auditable. When a diagnosis is wrong, the failure is attributed correctly: either the detector missed the signal (a recall problem, no AI involved) or the AI mis-categorized a correctly detected finding (an AI-quality problem). The two cannot mask each other.
What the documentation covers
These pages describe Control Desk at the method level — what each component does, why it is designed the way it is, and what the system guarantees. Implementation internals are not published here: no source code, no configuration schemas, no internal framework names. The unit of description is effect, not mechanism.
- Pipeline — the ten steps end to end; what is deterministic and where the one AI call sits.
- Detection — the two detection axes (cross-system and structural), the seven detection capabilities, and how detection is configured.
- Diagnosis — evidence assembly, the fixed taxonomy, safe degradation, and honest AI-status reporting.
- Evaluation — how recall and AI precision are measured separately, the answer-key separation model, and what a passing run proves.
- Governance — staged intake, the approve-then-activate two-step, atomic audited write-back, and single-administrator gating.
For a capability overview and feature catalog, see the Control Desk product page. For the research behind these design decisions, see the whitepapers.