Proof production work, not demonstrations
No single tool tells the story.
The story is that one governed methodology produced several distinct, production-grade engineering tools that plug into — and measurably improve — an existing enterprise diagnostic ecosystem.
Individually each solves a real problem: automated extraction, reliable correlation, scalable diagnosis, safe demonstration. Together they answer the question a single case study can't — whether the method repeats.
01 — The ecosystem
Two paths, one source contract.
Factory-built tools shown against the platform they operate within
SOURCE / FIELD EXTRACTION & PREP PRODUCTION PLATFORM OUTPUT ────────────── ───────────────── ─────────────────── ────── Access control ─┐ system of ├──▶ DoorSet-CSV-Extract ─┐ record │ Factory-built │ │ ├──▶ Collector ──▶ Cloud ──▶ Production Building data ─┘ legacy: two manual │ anonymize analytics diagnostics platform XML exports ───────┘ + package runtime + reports └──▶ DPT-Workbench ──▶ ADAM ──▶ Pre-sales SIDE / PRE-SALES LANE Factory-built demo report re-sites to a safe synthetic lab identity
On the production path, extraction pulls configuration directly from the access-control database, a collector anonymises and packages it, and the cloud platform runs the analytics that produce the customer's diagnostic reports. On the pre-sales path, DPT-Workbench re-sites a pre-anonymised dataset into a safe synthetic identity and feeds the same diagnostic engine, so a realistic demonstration can be shown without exposing any real customer.
The surrounding platform is the environment the suite operates within, not something the Factory built. That distinction is the point — these tools were designed to integrate with a mature enterprise ecosystem, not replace it.
02 — Built with the Factory
Three Factory-built tools, one operating method.
ADAM ML and the Engineering Tool
The diagnostic engine and its runtime. Classifies door-level false-alarm root causes and provides the ingest, ranking and workflow surface that runs the analysis at scale.
Read the case Case 02 · Factory-builtDPT-Workbench
Structure-preserving pseudonymization. Turns real, pre-anonymised data into a synthetic dataset that still behaves like a live operational system downstream.
Read the case Case 03 · Factory-builtDoorSet-CSV-Extract
Governed extraction. Pulls configuration and topology out of the access-control database on a schedule, reconstructs door-set structure at the source rather than inferring it downstream, and fails closed on schema drift.
Read the caseData collector
The anonymisation and packaging step on the production path. Not a Factory output — it is the platform component the Factory-built tools hand off to, shown here because the path doesn't read correctly without it.
Context only03 — The through-line
The tools are the evidence. The method is the capability.
The tools marked Factory-built were not produced by informal prompt-driven experimentation. They were specified, designed, implemented, validated and packaged under a single governed methodology — specialized roles, independent cross-model validation, evidence-grounded reasoning, fail-closed escalation, and tamper-evident records.
The same method that governs one tool governs the next. That is why the suite hangs together: shared source contracts, a consistent fail-closed posture, and a common standard for how the work was checked and proven.
That standard reaches the repository itself. Across all of these tools, nothing was committed until an independent Validator cleared it, one role held commit authority, and publication remained a separate decision held by the Principal. The version history is the audit trail — which only holds if the record has exactly one author and every entry was cleared before it was written.
The three fall into two problem classes: operational diagnosis, and governed data extraction and transformation. One good tool in either class can be luck, or a strong individual contributor, or a problem that happened to suit the approach.
Three tools across extraction, analytics and data transformation — each with different constraints and a different downstream consumer — is the harder claim, and the one worth making.
Read as a suite rather than a list, these make the case that the method is repeatable — not a one-off.
Or write directly — [email protected]