267 skills, eight platforms, one canonical design.

The problem it solves

Master data programs run for quarters for two reasons that have nothing to do with technology. The design work is largely the same on every engagement and gets redone by hand each time. And the design is written directly against one vendor's configuration language, so a client's thinking about their own data is locked to a platform decision made in month one.

Both are structural. Both can be designed out.

What I built

267 active skills covering a 50-step engagement lifecycle: discovery workshops, profiling, data modeling, source-to-target mapping, match and merge logic, survivorship, stewardship workflow, ingress pipelines, observability, testing, deployment, and certification. Around that sits 71 source connectors, a five-agent delivery architecture, a browser cockpit, and industry packs.

The canonical layer holds the model, the match rules, the survivorship logic, the data quality rules, the stewardship design, and the publication contract. Eight translators emit configuration for eight master data platforms. A client who changes vendors mid-program keeps their design. A consultant who learned the system on one platform is productive on the next.

Translation is not neutral, and pretending otherwise is the easy mistake. One platform treats its data quality layer as a firewall that rejects records by default rather than flagging them, so the translator upgrades flag rules to quarantine rules and writes a note explaining every upgrade it made. Those semantic differences are the actual work.

How I built it

Nineteen waves, each closing one named gap

The system began at v2.9 on a live enterprise engagement and matured to v8.7.4 across nineteen lettered waves. Waves E through N built and hardened the engine. Waves O through W made the proof portable, which is the part most internal tooling never survives.

The rule throughout was the smallest change that closes a real gap, never a speculative feature. Every wave has a named gap attached, and the wave is finished when that gap is closed and tested.

332 automated gates and a truth gate

Nothing ships until a test proves it. More than one gate per skill is what lets the system be handed to someone who did not build it. There is also a truth gate that fails the build when the documentation and the code disagree, which is the failure mode internal tooling usually dies of.

152 named refusals

The system refuses rather than fabricates. Where an answer depends on client data it has not been given, it says so and stops. Where it generates an assumption, that assumption is flagged for human review rather than folded silently into a deliverable.

This is the design decision I would defend hardest. An AI delivery system that guesses plausibly is worse than no system, because the guess arrives inside a document with a firm's logo on it.

What it made possible commercially

The suite is the reason a master data practice can be stood up without hiring ahead of revenue, and that is the part leadership cares about.

The platform expertise that used to live only in an expensive specialist's head is encoded in tooling, so the specialist role can be trained from the existing engineering bench in weeks rather than recruited over quarters. That single change rewrites the entry cost of the market.

On the back of it I built the partner agreement and its referral economics, a per-engagement price benchmarked against the vendor's own software-to-services band, three modeled staffing scenarios that name the margin lever explicitly, and a two-horizon plan with a hard gate between them.

Horizon one is bench-delivered with zero net-new hires. Horizon two is the annualized run-rate, and it does not unlock until the second engagement lands. Pipeline is stage-weighted rather than assumed, capacity is checked against demand before revenue is claimed, and the two inputs that cannot yet be defended with data are labeled as such.