Whitepaper · WP-1
Substrate, patterns, configuration: an architecture for domain-neutral data operations
Abstract
Most data-quality systems are built for a domain and then generalized under pressure, which is why domain vocabulary leaks into their core and every new client becomes a rebuild. Control Desk inverts that order. Its engine is a substrate that knows nothing about any client, domain, or data source; reusable patterns sit above it; and each deployment is expressed as client configuration — a connector and a field mapping — that plugs in as data, not as code. This paper describes the three-layer split, argues that domain neutrality holds by construction rather than by discipline, presents the two-domain proof in which one unchanged engine surfaces every seeded divergence across two unrelated domains, and describes the automated guards that fail the build if the boundaries are crossed. It does not report accuracy; that is the subject of WP-3.
1. The problem with domain-shaped engines
A system that reconciles data across systems must understand two things at once: the general shape of a mismatch — a value present here and absent there, a field whose format has drifted — and the specific meaning of the records in front of it. The temptation is to build both into one place. If the core is allowed to absorb one domain's meaning, the next unrelated domain forces that meaning back out. Domain vocabulary has become load-bearing, and neutrality is now something the team promises rather than something the architecture guarantees.
The failure is structural, so the remedy has to be structural too. If the core is ever allowed to name a domain concept, no amount of care keeps the next one out. Neutrality has to be the kind of property a build can check, not a habit a reviewer maintains.
2. Three layers
Control Desk is organized as three layers, each depending only on the one beneath it.
- Substrate — the domain-neutral core. It knows how to normalize records, detect mismatches, cluster findings, and grade outcomes in the abstract. It knows nothing about any client, domain, or data source. It is reusable precisely because it is empty of domain meaning.
- Patterns — reusable structures that sit above the substrate: the detector types, the triage lanes, the fixed taxonomy of causes and menu of fix actions. Patterns are general across domains but richer than the bare substrate; they are how the substrate's abstractions become usable capability.
- Client configuration — the per-deployment layer. A domain enters here and only here, and it enters as data: a connector that attaches a source system, and a field mapping that declares how that source's fields correspond to canonical ones. No client's meaning is ever written into the layers below.
The dependency arrow points one way: substrate ← patterns ← client configuration. Configuration may lean on patterns and the substrate; nothing lower may reach up to know what a particular client's data means.
3. Domain neutrality by construction
Neutrality "by construction" means the arrangement of the layers makes the leak impossible, not merely discouraged. Because a domain can only enter as client configuration, and because configuration is the top layer, there is no legitimate path for a domain concept to reach the substrate. A source system attaches through a connector; a field mapping translates its raw fields into canonical records; from that point on, the substrate operates only on canonical records whose provenance it does not know. It cannot special-case a client because it has never been given a client to name.
This is what turns the core into reusable property. An engine that has absorbed one client's vocabulary is worth one client. An engine that has absorbed none is worth every client that can be expressed as a mapping — which, given a connector and a field mapping, is any client whose data can be expressed as a connector and a field mapping
4. The two-domain proof
An architecture that claims neutrality has to demonstrate it, not assert it. The demonstration is deliberately blunt: one unchanged domain-neutral engine is pointed at two unrelated domains, connected through nothing but their respective field mappings, and asked to find trouble. It surfaces every seeded divergence in both.
What matters is the word unchanged. The engine is not recompiled, reconfigured internally, or taught anything about either domain between the two runs. The only difference between the two deployments is the connector and the field mapping — the client-configuration layer — exactly as the architecture requires. If neutrality were a promise rather than a property, the second domain would need a code change; it does not. The single engine, ingesting two unrelated domains through mappings alone, surfacing every planted divergence in each, is the claim of Section 3 made observable.
5. Enforced invariants
Layer discipline that lives only in reviewers' heads decays. Control Desk therefore encodes several of its boundaries as automated guards that fail the build when crossed. Described at the level of what they do:
- Domain purity. An automated guard fails the build if domain vocabulary enters the domain-neutral core. The neutrality of Section 3 is not a convention the team observes; it is a condition the build enforces.
- LLM-free detection. An automated guard fails the build if any AI client enters the detection, clustering, or triage path. The deterministic stages stay deterministic by construction, which is what lets WP-2 hold AI calls flat and WP-3 attribute recall entirely to a layer with no AI in it.
- Answer-key separation. An import-boundary guard plus a serialization-leak check make it structurally impossible for the diagnosis path to read the secret answer key minted during evaluation. This is the load-bearing invariant of WP-3 and is described in full there; here it is simply another boundary the build refuses to let anyone cross.
- Approve-inactive. Approving a rule or data source always writes it in the inactive state, whatever was submitted; activation is a separate authenticated act. The safe default is not a policy that can be forgotten but a behavior the system always performs.
- Evaluation isolation. Structural rules are proven silent on the evaluation corpus, so adding governance rules cannot move the benchmark numbers. The measurement stays honest even as configuration grows.
Each guard converts a claim a team would otherwise have to keep making into one the machine keeps for them. A boundary that fails the build is a boundary that stays put.
What this does not claim
This paper does not claim that any particular domain is well-served without a correct field mapping; a bad mapping produces bad canonical records, and the substrate cannot rescue what it was mistranslated. It does not claim the substrate can reconcile data it cannot read — an unsupported source is a missing connector, not a neutrality failure. It does not claim neutrality guarantees quality: an engine that ignores every domain equally can still be wrong about all of them, which is why detection and diagnosis are measured separately in WP-3 and no accuracy figure appears here. And it does not claim the two-domain proof exhausts the space of domains; it shows that the mechanism of neutrality works, not that every conceivable domain has been tried.
6. What this means for your data operations
If your reconciliation problem today lives in a chat thread and a spreadsheet, the practical consequence of this architecture is that onboarding your domain is a configuration task, not an engineering project: a connector for each source and a field mapping to canonical records. The engine that then inspects your data is the same engine proven neutral across unrelated domains, with the same build-enforced boundaries keeping it that way. See how the layers turn into a working case in Control Desk, and read the method in more detail in the documentation. The economics of running it at scale are the subject of WP-2; how its one AI call is graded honestly is the subject of WP-3.