Recent work: what I found, and what I built.

The problem. Engineers were already using AI coding tools. Governance had not caught up: policy documents with no enforcement point, and pressure to install third-party plugins nobody had vetted.

What I did

• Designed a three-level context hierarchy: one global engineering standard, a domain layer for each business area, and a file per repository. Every AI session inherits all three, so the principles travel with the work.
• Wrote the governance as plain markdown under version control, distributed by a one-command installer. First-party files only. No unvetted plugins.
• Built a set of review skills the AI runs on demand: security review, threat modelling, data-model review, dependency audit, integration-pattern check and a regulatory checkpoint.
• Put release gates on the installer itself. A build whose bundled contents drift from the source fails loudly before it reaches a single engineer.
• Shaped the rollout as a controlled pilot: two squads, non-production work, with the security gate as a prerequisite rather than an afterthought.

What changed. Engineering principles became something the tooling applies at the point of work, instead of something people get reminded about at a review board.

Useful if your engineers use Claude Code, Copilot or Cursor and your AI governance is mostly a PDF.

The problem. Nobody held a current picture of how the core systems worked. Documentation was years out of date, suppliers owned parts of the stack, and design conversations started from memory and opinion.

What I did

• Recovered the full source estate: more than 1,100 repositories and over 600,000 files.
• Built a reusable, AI-assisted reverse-engineering method. It keeps three things apart: the method, the context for each system, and the findings. It triages which system to analyse next by how central it is to integration and how exposed it is to regulation.
• Mapped 46 systems: integration edges, system-of-record boundaries, runtime flows and risks.
• Held every finding to one rule. It is anchored to repository/path/file:line and labelled Fact, Inference or Not yet verified. A catalogue entry stays an assertion until the code proves it.

What changed. Design conversations moved from “we think it works like this” to “it works like this, and here is the line”. The same evidence then carried supplier onboarding, platform replacement options and a reconciled application inventory.

Useful if you run legacy core systems, depend on supplier-owned code, face a due-diligence exercise, or suspect your documentation stopped telling the truth some time ago.

The problem. Critical knowledge about the estate lived in people's heads and in scattered wikis. When someone leaves, it leaves with them. Senior roles had turned over without a proper handover.

What I did

• Designed a separate, hand-over-able knowledge structure. Each knowledge base holds raw verbatim sources, compiled and cross-linked articles, query outputs and a changelog.
• Compiled five knowledge bases covering the systems estate, the advice platform, a core legacy platform, data architecture and AI engineering: more than 220 articles, each traceable to its source.
• Wired it into the engineering AI context, so a developer's assistant in any repository starts out already knowing the estate.
• Wrote a verified-answer standard: eight rules an answer has to meet before it counts as known.
• Prototyped an executive query page. Type a question, get a plain-English answer with its sources shown. Built API-first, with the answer contract in the schema, so an answer without evidence is an invalid response rather than a weak one.
• Put a credential scan on the ingest gate. Source code carries secrets, and knowledge bases leak them if nobody checks.

What changed. Knowledge the organisation owns, instead of knowledge on loan from individuals. A successor with no context can pick it up cold.

Useful if you carry key-person risk, rely on interim or contract architects, or have AI assistants confidently making things up about your own systems.

The problem. Reports disagreed with each other. Point-in-time questions, such as what the firm knew about a client on a given date, could not be answered reliably. Every fix added another reconciliation layer downstream.

The cause. Systems overwrote history in place. Ownership of the source of truth was unclear by data type. Consumers rebuilt the truth for themselves instead of consuming it from an authoritative source. One valuation figure passed through six layers with no real-time reconciliation between them.

What I did

• Framed the thesis: truth reconstruction against authoritative consumption. Every consumer reconstructing the truth is a symptom. One owner publishing it is the fix.
• Applied it across the estate: temporal integrity, source-of-truth ownership by data type, and an enterprise asset registry.
• Built the registry as a queryable graph with blast-radius analysis. Ask what depends on a service and it returns every impacted asset, with regulatory obligations inherited down the dependency chain. One query on a shared service returned 207 impacted assets across five groups.

What changed. Remediation aimed at the source of the defect, not another reconciliation report stacked on top of it.

Useful if you have regulatory reporting that needs point-in-time answers, or a data platform with several “golden sources” that disagree.

The problem. A regulated new-business process with low straight-through processing, elapsed times measured in weeks, and most cases generating a follow-up contact. The business had measured the symptoms well. Nobody had traced them into the code.

What the code showed

• Three asynchronous queues, each drained on a timer, each a place a case could stall without telling anyone.
• A pipeline step that caught every exception and reported success. Failed cases were never retried and never surfaced.
• A data contract enforced on the wrong side of a system boundary. Incomplete records were rejected silently downstream, and staff had worked out that editing a field and changing it back would force a retry.

What I did. Mapped every symptom to a root cause, then wrote the plan in two parts. Four actions that could start that week, on artefacts the firm controlled, each with an owner and a success measure. Around them, a five-move structure to deal with everything else.

The first action cost nothing: measure the silent failure, read-only, before changing a line. The whole business case rested on a number nobody had.

What changed. A plan that could start in days, instead of a programme that needed months of discovery first.

Useful if your operations team has built workarounds into its daily routine, or your failure demand is high and nobody can say why.

The problem. A core platform supported by a third party, costly to change and holding the business back. A request to put partner APIs on top of it. A legacy database with vendor support ending and a hard deadline attached.

What I did

• Separated two requests that looked like one. A partner API is a product, with consumers and backward-compatibility promises. A decoupling layer is a seam, built so the thing behind it can be replaced. Publishing the product first would have welded the business to the system it was trying to leave. The recommendation: build the seam, earn the product.
• Wrote a future-state architecture with a staged migration and explicit decommission gates, so capabilities move one at a time while the business keeps trading.
• Reframed the database exit. Every dataset it held already existed elsewhere, so this was a decommission, not a data migration: move the processing logic, replace the admin screens, switch it off. The problem shrank, and AI-assisted code conversion became a realistic option.
• Assessed every option against three stated tests: deadline, cost and quality.

What changed. Options sized honestly, with nothing presented as decided that had not been decided.

Useful if you face vendor lock-in, an end-of-support date, or a “we just need an API” request that is really a replacement strategy in disguise.

The problem. A move from a licensed low-code ETL tool to a code-first stack: dbt, managed Airflow and a cloud data warehouse. Several delivery partners were working in the estate, a licence renewal set the deadline, and each partner brought its own way of doing things.

What I did

• Wrote the platform reference: the end-to-end pipeline, its layers, patterns and controls, readable by someone who was not in the room.
• Set one dbt standard to hold across every vendor.
• Specified hooks built into the platform from day one: tests, data-quality rules, heuristic checks, restartability, telemetry and pipeline observability. Things the platform provides, not things each team has to remember.
• Produced a deep-dive on the legacy tooling so the migration scope was evidenced, not estimated, and a briefing deck for leadership.

What changed. The client's engineering positions were on paper before the direction of travel was set by whichever supplier shipped first.

Useful if you are modernising ETL, running multi-vendor delivery, or planning to bring a platform back in-house.

The problem. Architecture that sits in review boards and unread documents does not change what gets built. It just slows it down.

What I did

• Designed a lightweight solutions engineering model: clear criteria for when architecture must be engaged, a one-page framing template, explicit decisions. No new review board. The burden of proof sits with the exception.
• Wrote every paper in three tiers: already decided (and where), proposed here (and on what basis), and open. Nothing proposed reads as decided.
• Produced a readiness report ahead of a major platform launch. Every finding, whatever its severity, classified as fix now, fix over time or defer, so leadership could make the call.
• Ran a 124-requirement fit assessment for a supplier bid. Every rating evidenced or marked Unknown. Nothing invented.
• Wrote handover and supplier onboarding packs that let a newcomer, internal or external, be useful in week one.

What changed. Architecture that is connected to delivery, and documents that get read.

Useful if your architecture function is known mainly for saying no, slowly.