Representative work.

The question

The retailer — supermarkets, a fashion line, and a fast-growing e-commerce arm — had spent two years and a real budget on AI. Fourteen pilots ran across merchandising, supply chain, marketing, and store operations; two had reached production. The board's question was blunt: is this a capability we should fund as one — or fourteen experiments we should stop calling a strategy?

The diagnosis

We expected to find weak models. We didn't. Several pilots — demand forecasting, markdown optimisation, returns-fraud detection — were technically sound. What was missing sat underneath them: there was no operating model. No shared definition of what "good" meant, no route from a working pilot to a governed production system, and no single owner for any capability once the data-science team moved on.

The same customer and product data had been extracted and reshaped four separate ways by four separate teams. The problem was not the models. It was the absence of the thing models are meant to sit on.

The leap

We proposed they stop choosing between pilots and instead build the layer all of them needed: a thin AI foundation. A shared feature and data layer on the lakehouse they already owned; a single model-and-LLM gateway so every team called models the same way; and one evaluation harness, with retail-specific metrics, that every capability had to pass. Above it, a stage-gate — experiment, validated, governed-production — with a business owner and an engineering owner named at each gate. We did not pick winning pilots; we picked the five use cases that would share the foundation first.

The build

A ninety-day foundation came first: a feature store on the existing lakehouse, a model gateway fronting both classical models and LLMs, and an evaluation harness measuring what retail actually cares about — forecast bias, markdown margin impact, recommendation lift, fraud precision.

Then we re-platformed three capabilities onto it — demand forecasting, markdown optimisation, and personalised recommendations — pairing our engineers with theirs rather than delivering to them. The stage-gate became a fortnightly governance forum the client now runs without us.

The outcome

Twelve months in, AI capabilities in production had gone from two to nine. Time from a proposed idea to a governed production system fell from roughly nine months to about ten weeks — because the foundation and the eval harness were no longer rebuilt each time. Forecast accuracy improved enough to move real inventory; markdown margin recovered measurably. Most of all, the board stopped funding a list of experiments and started funding one capability, with a roadmap and named owners.

What we'd do differently

We would have stood the evaluation harness up in the first fortnight, not the second month — it became the spine of every later conversation. And we under-scoped the change management for store operations: a model is only adopted if the store manager trusts it, and that trust is built in person, not in a release note.

The question

The network — fourteen hospitals, a diagnostics arm, a growing tele-health service — had clinicians and an innovation team who, between them, had built four AI tools: radiology triage, a sepsis early-warning score, automated discharge-summary drafting, and clinical-coding automation for billing. None were in routine use; the medical board had declined to approve them. Leadership's question was not whether to deploy AI in clinical settings, but how — responsibly.

The diagnosis

We reviewed the tools expecting to recommend which to keep. Several were clinically promising. But the medical board was not being obstructive — it was being correct. There was no clinical AI assurance: no standard for evaluating a tool against clinical outcomes rather than benchmark accuracy; no monitoring for whether a model that worked in validation still worked on this month's patients; and no clear accountability between the clinician who acts, the tool that advises, and the vendor that built it.

A responsible board cannot approve what it cannot assure. The missing thing was a framework — and its absence was the real finding.

The leap

We proposed treating assurance as a standing function, not a launch gate. Every AI capability would pass through a defined pipeline: pre-deployment evaluation against a held-out patient set built to be demographically representative, not merely large; an explicit, written human-in-the-loop role for each tool; continuous post-deployment monitoring for drift and for performance across patient subgroups; and a named clinical owner accountable for each. We recommended starting with the two highest-value, lowest-risk tools — discharge-summary drafting and coding automation — to prove the pipeline before bringing radiology triage through it.

The build

We stood the assurance pipeline up with the clinical informatics team. An evaluation harness measuring what clinicians and regulators care about — sensitivity and specificity by subgroup, calibration, time-to-decision — not aggregate accuracy. A monitoring layer watching live performance and raising a flag the moment a subgroup's results drifted. An audit trail recording every AI-assisted decision and the clinician's action on it.

All of it integrated with the EMR, and reviewed by an assurance forum we constituted with the medical board in the room from the first week.

The outcome

Within twelve months, three tools were approved for routine clinical use: discharge-summary drafting, clinical-coding automation, and the sepsis score as a decision-support aid. Discharge drafting returned meaningful clinician time each week; coding accuracy rose and denied claims fell. Radiology triage entered a supervised rollout under the same pipeline. The medical board's posture changed from a veto to a framework — it now had a defensible way to say yes.

What we'd do differently

We brought the medical board fully into the room in week six. It should have been week one — they were the people whose trust the entire engagement depended on, and earlier partnership would have saved a month of re-explaining. And building a genuinely representative held-out patient set took longer than we scoped: demographic representativeness is careful, detailed work, and we should have planned for it.

The question

The retailer's e-commerce platform — the one carrying a third of revenue — went down roughly once a quarter, and always at the worst moment: a sale, a festival, a Black Friday. It was a single-cloud monolith, scaled by adding bigger machines. The CTO's question: do we keep patching, or rebuild the foundation?

The diagnosis

The outages were not a capacity problem — they bought capacity every quarter. They were a coupling problem. Checkout, catalogue, and pricing shared one deployable and one database, so a slow query in catalogue took checkout down with it.

And there was no observability worth the name: the team learned about outages from customers, not dashboards. They were operating blind, on a system designed to fail all at once.

The leap

We proposed a two-cloud architecture — not for fashion, but because their disaster-recovery story was fiction and a second cloud made it real. Decompose the monolith along the seams that actually mattered — checkout, catalogue, pricing, identity — each independently deployable and independently scalable. And build security, cost controls, and observability in as day-one infrastructure, not retrofits.

The build

We did it in slices, never a big-bang cutover. Checkout moved first — highest stakes, so we proved the pattern where it mattered most. Each service got infrastructure-as-code in Terraform, a defined SLO, and dashboards before it carried a single request. A FinOps layer tagged every resource to a service and a team, so cost finally had an owner.

We embedded SREs alongside the retailer's engineers and ran two festival peaks together before handing back the pager.

The outcome

P0 incidents fell from seven a quarter to one. Cloud spend dropped 31% even as traffic grew 2.4×, because autoscaling replaced standing, over-provisioned capacity. Provisioning a new environment went from days to minutes. The next Black Friday was, for the first time anyone could remember, uneventful.

What we'd do differently

We moved the catalogue service before its data contract was solid, and paid for it in a fortnight of reconciliation. Data seams should be settled before a service moves, not discovered during the move.

The question

The network's clinicians and quality team kept hitting the same wall. To answer a question — which diabetic patients had missed a follow-up, how a cohort responded to a pathway change — someone filed a data request, and weeks later received a spreadsheet of uncertain provenance. The data existed: in the EMR, the lab system, imaging, pharmacy, billing. It simply never assembled into a patient.

The diagnosis

Eleven systems each held a true fragment of the patient, and none held the patient. Worse, they disagreed on identity — the same person appeared with three medical-record numbers across three sites. Every analysis began by re-solving "who is this patient," badly, from scratch.

Before anything could be trusted — a dashboard, a cohort, a model — identity and a shared clinical model had to exist.

The leap

We proposed a clinical data lakehouse built around two things the network had never had: a resolved patient identity, and a shared clinical data model in a recognised standard (FHIR-aligned), so a diagnosis or a lab result meant the same thing regardless of its source system. Every dataset would carry its provenance and its data contract. The same foundation that let the quality team ask a cohort question would, later, let an AI model train on a population that was actually defined.

The build

We built the lakehouse and, first, an identity-resolution layer reconciling patients across the eleven systems — with clinical review of the uncertain matches, not a silent algorithm. Then we mapped each source into the shared clinical model, with data contracts catching upstream drift.

We built the longitudinal patient timeline as a governed dataset, and a cohort-query capability on top. The clinical informatics team co-built it, and owns it.

The outcome

For the first time, the network could see a patient as one timeline. A cohort question that had been a multi-week data request became an afternoon's work against a governed dataset. Identity errors surfaced and were corrected at the source. And when the clinical AI assurance work began, it had what it needed — a defined population, with provenance — instead of a spreadsheet.

What we'd do differently

We treated identity resolution as mostly a technical problem. It is also a clinical-governance problem, and the clinical review of ambiguous matches needed more clinician time than we scheduled. We would staff that from the first week.

The question

The bank's personal-loan application was a real revenue funnel — and a leaking one. Of every hundred customers who began it, a large majority never finished. The bank had spent on marketing to drive applications and on staff to process them; almost no one had asked why the application itself was where customers gave up.

The diagnosis

We watched people use it. The application was forty minutes of forms, because it asked the customer for everything — including what the bank already knew, and what it could verify itself. It demanded documents be found, scanned, and uploaded; it failed late and made people start over; it never told anyone where they stood.

It had been built as a data-collection form for the back office — not as a product for the person filling it in.

The leap

We proposed rebuilding the application as a product with a single job: get a qualified customer to a decision with the least effort the regulator allows. Ask only what the bank genuinely cannot obtain another way. Use AI behind the screen to do the paperwork — extract data from a photographed document, pre-fill from records the bank already held, run an instant pre-assessment so a standard applicant had an answer in minutes. Every AI step checked against the bank's lending rules; nothing about the credit decision hidden or hand-waved.

The build

We rebuilt the application on a modern front-end that saved state continuously — no one would lose their progress again — and tolerated being finished across two sittings or two devices. Behind it: a document-extraction service through a model gateway, pre-fill from the bank's own systems, and a pre-assessment model that returned an indicative decision while a human underwriter stayed in the loop for anything non-standard or adverse.

We instrumented every step, so drop-off finally had a number against it, and shipped to one customer segment first.

The outcome

Application completion roughly tripled. For standard applicants, time from start to an indicative decision fell from several days to minutes — and the underwriters' time moved to the cases that genuinely needed judgement. Drop-off became a measured, monitored number rather than an accepted cost of doing business. The funnel the bank had been feeding from the top finally stopped leaking from the middle.

What we'd do differently

We optimised the happy path first and the adverse-decision path second. But the moment that most needs care is the one where the answer is "no", or "not yet" — handled badly, it costs trust and sometimes a complaint. We would design the difficult outcomes first next time.

The question

The manufacturer had put AI on the floor — vision models inspecting parts for defects, models predicting failure on the big machines — across nine plants. It worked at launch. A year on, two questions had no owner: was each plant's model still as good as the day it shipped, and who fixes it at 2 a.m. when a line is down? Operations watched the servers; no one watched the models.

The diagnosis

A model trained centrally and deployed to nine plants does not stay one model. Each plant has its own lighting, its own cameras, its own machines ageing at their own rate — so each plant's model drifted its own way. The quality model at one plant had quietly begun passing a class of defect; the maintenance model at another cried wolf often enough that the floor had started ignoring it.

Both failures were invisible to a dashboard built for uptime — and both models ran at the edge, on the floor, which the cloud-shaped operations practice had no real handle on.

The leap

We proposed operating the fleet of models as a fleet — per plant, never in aggregate. Each plant's model gets its own live evaluation against locally-labelled outcomes, and its own drift detection, because "the model" is really nine models living nine lives. An EdgeOps layer to manage what runs on the floor — versioning, rollout, rollback — as carefully as anything in the cloud. And an on-call that can read a model going wrong at one plant and act before the floor loses trust in it.

The build

We took over operations follow-the-sun and, alongside CloudOps, stood up the model fleet: per-plant evaluation jobs scoring the quality and maintenance models against outcomes labelled by that plant's own inspectors and technicians; drift monitors on the camera feeds and sensor inputs; an EdgeOps layer giving every plant a versioned, reversible model deploy in place of a manual update.

A regression gate stopped a retrained model shipping to a plant if it lost ground there — even if it had improved on average. We trained each plant's team to read its own model's health.

The outcome

Model degradation that used to surface as a warranty claim or an ignored alarm now surfaces per plant, in hours, as an alert. False maintenance alarms fell sharply once each plant's model was tuned and watched against its own machines — and the floor began trusting the alerts again, which is the entire point of an alert. A retrained model now reaches nine plants in a controlled rollout, not a nervous all-at-once update.

What we'd do differently

We built the central, fleet-wide evaluation view before the per-plant one, because it was easier — and it told us almost nothing useful. The average of nine drifting models is a number that hides every problem inside it. We would build the per-plant view first, and the rollup second.