Case 02 DPT-Workbench · structure-preserving pseudonymization
Two requirements pulling in opposite directions.
Remove every identifying customer characteristic. Preserve enough operational and structural fidelity that downstream analytics remain valid. Neither requirement is allowed to relax — and the tool has to satisfy both at once, across interdependent files.
That tension is the whole engineering problem. Anonymise too hard and the data stops behaving like a real system. Preserve too much and identity survives into the output.
blocking on drift
preserved structural columns
parity acceptance gate
01 — The contradiction
You cannot demonstrate the product with a real customer's data.
A realistic dataset was needed downstream — to populate the demonstration report shown to prospective customers, so they could see what the reporting experience would actually look like.
A real customer's report could not be used for that purpose. And the available test systems were too small to generate anything credible: a demonstration built on a handful of synthetic doors looks exactly like what it is.
DPT-Workbench exists to resolve that contradiction. It takes real, pre-anonymised source data and transforms it into a pseudonymised dataset that still behaves like a live operational system when processed downstream — so the diagnostic engine can consume it and produce a realistic demonstration surface.
Not a file converter. Not a one-off masker. Not a lightweight interface over a script.
Those would all be easier, and any of them would have failed the acceptance criterion — because correctness here is not defined by the tool's own checks. It is defined by whether the downstream analytics still work on the output.
02 — The redesign
Changing the spine without letting the behaviour drift.
An approved v2.0.0 baseline already existed as a portable single-file Windows executable. The v3.0.0 effort was not a cosmetic enhancement — it replaced the structural spine, moving from a legacy two-XML input model to a DoorSet-extract CSV model.
That class of change is risky precisely because the foundation moves while the required behaviour cannot meaningfully drift. The mission stayed identical: remove identifying characteristics, preserve operational structure, support downstream analytical behaviour.
What could not change
These were carried as hard constraints rather than preferences — design choices the redesign was not permitted to trade away for convenience.
- GUI-first An operator tool, not a developer-operated environment.
- Standalone Packaged executable, portable, no runtime assembly required.
- Fail-closed Structural or identity doubt blocks output rather than degrading it quietly.
- Accountable Correctness judged by the downstream consumer, not by internal checks.
How the work was carried
Work was separated across roles, with a hash-bound and immutable artifact chain behind every approval. Nothing reached the repository until the Validator cleared it, and only the Builder could commit it once cleared.
- Architect Design authority. Did not implement.
- Validator Independent review. Did not build the fix.
- Builder Implementation against a cleared directive. Sole commit authority.
- Deployer Runtime and packaging validation against live proof.
03 — The part that proves the governance
A fault window made a batch of evidence inadmissible.
Mid-project, a fault-window event rendered a prior batch of session artifacts inadmissible. The evidence behind a set of decisions could no longer be trusted.
The process did not hand-wave past it. The design and review sequence was re-established cleanly, and the current-authority baseline was rebuilt on admissible artifacts only.
This is the least glamorous part of the case and the most important one. Any method looks disciplined while things go well. What a governance model is actually for is the moment something goes wrong — and the question of whether the damage can be bounded, traced and reversed rather than quietly absorbed.
Work found unreliable is marked inadmissible, its trace preserved, and rebuilt from clean authority.
The trace is preserved rather than deleted. That is what makes the recovery reviewable afterwards instead of merely asserted.
04 — Acceptance
The gate was downstream behaviour, not file similarity.
Superficial resemblance between input and output would have been easy to achieve and would have proved nothing. The decisive test was whether the diagnostic engine, run against the transformed dataset, produced the same diagnoses it produced against the source.
v3.0.0 implementation, review and deployment validation completed for the validated scope. The transformed dataset remained analytically useful to the downstream consumer it was built to serve. Acceptance measured on diagnosis columns 11–13 across a 50-row comparison
One DoorSet extract CSV behind a blocking 38-column schema gate, plus 30 daily archive CSVs and a site-identity surface, in a flat archive contract.
The validated run preserved 2,620 DoorSet rows, processed 30 daily CSVs containing 506,150 rows, and emitted 32 output entries.
All 38 columns governed explicitly — 10 masked as identity-bearing, 28 preserved as structural, with invariance checks treated as blocking controls.
05 — Why the alignment problem is non-trivial
It does not mask one file in isolation.
Four surfaces that must stay coherent simultaneously
The DoorSet extract carries the schema, explicit door-key fields and tokenized relationships that must survive unchanged wherever they are structural rather than identifying.
The daily archives carry ongoing event history — over half a million rows in the validated run — and their point references must continue to resolve correctly against the transformed catalog.
The identity and output-naming surfaces must be re-sited to the target identity without corrupting downstream join behaviour.
Four independent operator-set target fields must thread consistently through renaming, masking, validation, packaging and reporting.
Join integrity protects controller, interface, point and hostname coherence across files. Row counts must be preserved. A residual sweep confirms identity-bearing values did not survive.
Token columns and numeric point linkage stay verbatim. Altering them would damage analytical fidelity without improving privacy — masking for its own sake is a defect, not a safeguard.
Cross-file dependence at operational density is what makes this a measure of capability rather than a demonstration. Small datasets hide alignment failures.
06 — What the case establishes
Not simply to build software. To build governed software.
DPT-Workbench shows the method can specify, redesign, implement, validate and package a sophisticated product whose success depends on satisfying governance, operational, analytical and usability constraints at the same time — and can do it through a change of structural foundation, under defect pressure, without losing traceability.
The tool is the evidence surface. The method is the capability behind it.
The engineering problem was not to anonymise data. It was to produce an analytically faithful dataset at operational scale.