Pipeline
The Ten-Step Pipeline
A Control Desk detection run passes through ten steps in fixed sequence. Nine of those steps are fully deterministic. The tenth — and only the tenth — calls AI.
Design intent
The pipeline is designed so that every step either has a verifiable deterministic output or is explicitly labeled as the AI boundary. This makes failures attributable: a detection miss is a deterministic problem; a mis-categorized diagnosis is an AI-quality problem. Neither can silently mask the other.
Steps 1 through 7, and steps 9 and 10, are deterministic. Step 8 is the sole AI step.
Step by step
Step 1 — Connect
What enters: a configured data source with a designated connector type.
What exits: a raw stream of source records ready for mapping.
Deterministic. The connector reads the source according to its type (CSV, JSONL, sample-data, or SQL) and emits rows. No transformation, no inference.
Step 2 — Map
What enters: raw source rows plus a per-source field mapping.
What exits: rows with source fields renamed and aligned to canonical field names.
Deterministic. The mapping is declared in configuration; the step applies it mechanically. This is where a client domain enters the system — as a mapping table, not as code.
Step 3 — Normalize
What enters: mapped rows.
What exits: canonical records in a uniform representation, ready for comparison.
Deterministic. Type coercions, null handling, and whitespace normalization are applied according to the canonical schema. No AI, no heuristics.
Step 4 — Detect
What enters: one or more normalized record sets from all configured sources.
What exits: a set of findings, each identifying a specific problem at a specific record.
Deterministic. Detectors are rule-driven and evaluate conditions mechanically. Cross-system detectors compare records across sources. Structural detectors validate records within a single source. No AI is involved. See Detection for the full capability list.
Step 5 — Fingerprint
What enters: the finding set from step 4.
What exits: the same findings, each with a stable identity derived from its structural characteristics.
Deterministic. Fingerprinting produces a consistent identifier for findings that share the same structural pattern, regardless of which records triggered them. This identity is what makes clustering possible in the next step.
Step 6 — Cluster
What enters: fingerprinted findings.
What exits: findings collapsed into distinct problem classes — one class per distinct structural pattern.
Deterministic. Findings with the same fingerprint belong to the same class. The number of AI calls in the next stage is determined entirely by this count, not by data volume. At the ~1M-row scale benchmark: 9,834 findings collapsed into 4 distinct problem classes, producing 4 AI calls — a 2,458× collapse.
Step 7 — Triage
What enters: clustered problem classes.
What exits: each class assigned to one of three lanes — log, playbook, or diagnose.
Deterministic. Triage consults the rule configuration to determine whether a class is already understood (log or playbook) or needs AI diagnosis. Only classes assigned to the diagnose lane proceed to step 8. This means AI spend is bounded by the number of novel problem classes, not by the size of the dataset.
Step 8 — Diagnose
What enters: one problem class from the diagnose lane, accompanied by a bounded evidence file assembled from the findings in that class.
What exits: a structured diagnosis: a cause category from a fixed taxonomy, a fix action from a fixed menu, and a confidence indicator.
The sole AI step. One AI call is made per problem class that reaches this lane. The AI receives only the bounded evidence file; it has no access to the full dataset, no access to the evaluation answer key, and no ability to call out to other systems. If the call fails or returns an unrecognizable result, the step degrades safely to "unknown" with a conservative default action and reports the degradation loudly. See Diagnosis for the evidence assembly model and degradation behavior.
Step 9 — Grade
What enters: the full set of diagnoses plus the evaluation answer key (in evaluation runs) or the persisted case record (in production runs).
What exits: scored outcomes; recall and AI category-accuracy are attributed separately.
Deterministic. Grading compares outcomes against expected results by rule. The recall metric measures whether the detectors found every planted break; the category-accuracy metric measures whether the AI categorized detected findings correctly. Keeping them separate means a detection failure cannot silently degrade the AI-quality number. See Evaluation for the measurement model.
Step 10 — Persist & audit
What enters: graded cases and all configuration changes made during the run.
What exits: durable records in persistent storage; an audit trail entry for every write.
Deterministic. Writes are atomic: they either commit in full or roll back entirely. Every configuration change lands with a before-and-after audit record. The audit trail is append-only and not modifiable through the normal run path. See Governance for write-back details.
Step summary
| Step | Name | Nature |
|---|---|---|
| 1 | Connect | Deterministic |
| 2 | Map | Deterministic |
| 3 | Normalize | Deterministic |
| 4 | Detect | Deterministic |
| 5 | Fingerprint | Deterministic |
| 6 | Cluster | Deterministic |
| 7 | Triage | Deterministic |
| 8 | Diagnose | AI — one call per problem class |
| 9 | Grade | Deterministic |
| 10 | Persist & audit | Deterministic |