Anonymised, composite case studies from the kinds of engagements I lead across healthcare, fintech, SaaS, e-commerce and AI. No logos and no confidential numbers: just how each system was designed, how the data flows, and why.
A South Korean recruitment platform used AI to match candidates to roles and summarise applications for employers. Under the AI Basic Act, AI used in hiring sits in the high-impact category. The goal was to keep the efficiency while making every AI-assisted step transparent, overseen by people and evidenced.
Matching and ranking modelsLLM summariesEvaluation set with fairness checksReviewer workbenchDecision logRead the case study →Case study · Managed IT services · United KingdomA mid-sized UK managed service provider held administrator access to hundreds of customer environments. The Cyber Security and Resilience Bill would bring providers like it under the NIS regulations for the first time. The goal was to get ahead of it: control privileged access centrally, detect and report incidents quickly, and tell affected customers promptly.
Central identity providerJust-in-time privileged accessSession recordingSecurity event pipelineIncident case managementRead the case study →Case study · Manufacturing · European UnionA European manufacturer of connected heating and ventilation equipment collected rich product data, but only its own service teams could use it. The EU Data Act turned that into an obligation: users must be able to access the data their products generate and share it with others. The goal was to build that into the product platform rather than bolt on a support process.
Device telemetry over OTLPOpenTelemetry Collector gatewaysEvent streamingProduct data catalogueUser data access APIRead the case study →Case study · Insurance · AustraliaAn Australian general insurer had put AI into claims intake, customer service and fraud review, mostly through one hosted model provider. Nobody had asked what happens when that provider is slow, out of capacity or gone. Under APRA's CPS 230 that is a board-level question, and the goal was a credible answer.
Model gatewayTwo hosted model providersPrivate model fallbackKubernetes inference routingRules-based degraded modeRead the case study →Case study · Travel · Singapore & Southeast AsiaA regional travel marketplace saw consumer AI agents arrive in its home market, able to compare, basket and book on a person's behalf. Its site was built for humans and scrapers. The goal was to give agents a fast, safe and honest way in, without breaking the experience for everyone else.
Structured product dataAgent booking APIMCP serverKubernetes Gateway APIIdempotent booking serviceRead the case study →Case study · Consumer lending · IndiaAn Indian digital lender collected consent in its app but could not say, for any one customer, which partners held their data, for what purpose, or whether a withdrawal had reached them. With the DPDP Rules phasing in, the goal was a consent and data-rights platform that turns legal obligations into events every system honours.
Consent ledgerPurpose and data catalogueEvent streaming (Kafka)Policy enforcement at APIsRetention and erasure jobsRead the case study →Case study · Insurance · United StatesA US specialty insurer ran its agent portal, quoting tools and dozens of marketing sites on PHP, some of it years out of support. When an actively exploited PHP flaw landed, nobody could say quickly where PHP was running. The goal was to close that exposure in days, then turn a one-off scramble into a platform that stays patched.
PHP 8.x (supported releases)Apache HTTP ServerContainer golden imagesWeb application firewallOpenTelemetryRead the case study →Case study · Financial services · Security operationsA security operations team faced more alerts than analysts, from tools that each spoke their own data format. Leadership wanted AI to help. Analysts wanted it not to invent things or take actions on its own. The goal was a copilot that speeds up triage and investigation while every response stays a human decision.
OCSF event schemaSIEM and data lakeMITRE ATT&CK mappingLLM with tool callingRetrieval over runbooksRead the case study →Case study · Utilities · UAEA UAE utility's customers asked the same questions in Gulf Arabic, Modern Standard Arabic, English and a mix of all three. Its knowledge lived in policies written in one language or the other. The goal was an assistant that answers in the customer's language, from the right source, with a citation, and keeps personal data in the country.
Multilingual embeddingsHybrid searchArabic text normalisationArabic-capable LLMRetrieval-augmented generationRead the case study →Case study · Fintech · UAEA UAE fintech had built its product on screen scraping and one-off bank integrations. The Central Bank's Open Finance framework offered a regulated, standardised alternative through a central API hub. The goal was to re-platform around consent and secure APIs without stalling the product roadmap.
Open Finance API hubOAuth 2.0 and OpenID ConnectFAPI 2.0 security profileConsent serviceEvent busRead the case study →Case study · Technology · Multi-cloud enterpriseYears of acquisitions and team autonomy had left infrastructure across three clouds, described by hundreds of Terraform folders with copied modules, giant state files and secrets in plaintext. Changes were slow and frightening. The goal was an estate that teams could change quickly and safely, without a central bottleneck.
Terraform or OpenTofuAWSAzureGCPModule registryRead the case study →Case study · Software · AI productsAn AI software company was losing weeks in every enterprise deal to security and AI questionnaires, each asking for the same things in different words. Regulation was moving in three markets at once. The goal was one governance programme whose evidence could be reused for every buyer, auditor and regulator.
AI system inventoryISO/IEC 42001NIST AI RMFSOC 2Evaluation suiteRead the case study →Case study · Life sciences · BiotechA growing biotech ran several trials through different vendors: an EDC system, central labs, eCOA, wearables and imaging. Each study rebuilt its data pipelines from scratch, and the path from raw data to submission datasets lived in programmers' heads. The goal was one platform with lineage, quality and audit trails built in.
EDC and vendor feedsCDISC SDTMControlled terminologyData lakehouseLineage catalogueRead the case study →Case study · Life sciences · Drug safetyA drug safety team tracked potential signals across spreadsheets, email and slide decks. Each evaluation meant a bespoke data request and weeks of analysis. The goal was one platform that detects candidate signals, keeps the reasoning auditable and lets the team test them quickly against real-world data.
Safety database extractsMedDRA-coded eventsDisproportionality analysisOMOP CDMOHDSI HADESRead the case study →Case study · Software · B2B SaaSSeveral product teams had shipped AI features, each with its own prompts, its own vendor calls and its own idea of 'good'. Model upgrades were risky, regressions were found by customers, and nobody could say what an AI feature cost to run. The goal was one platform for evaluating, releasing and observing every LLM feature.
OpenTelemetry GenAI conventionsOTel CollectorEvaluation harnessLLM-as-judgePrompt registryRead the case study →Case study · Technology · Scale-upCloud bills were growing faster than the business, and nobody could say which team or product drove the increase. The goal was a platform where every workload has an owner, a cost, sensible defaults and a cheap way to shrink, so cost becomes a product decision rather than a quarterly panic.
KubernetesOpenCostFOCUS billing dataHorizontalPodAutoscalerVertical Pod AutoscalerRead the case study →Case study · Enterprise · Software and servicesEngineers had connected assistants to dozens of MCP servers, some internal, some from the internet, most with broad tokens. Security wanted to stop it; product teams wanted more of it. The goal was a platform that made the approved path the easiest one.
Model Context ProtocolPrivate MCP registryOAuth 2.1Identity providerMCP gatewayRead the case study →Case study · Insurance · Multi-line carrierClaims arrive as phone notes, emails, photos and PDFs. Triage decides which adjuster sees what, how fast, and with which flags. The goal was to use AI to do that first pass well, without letting a model decide anyone's claim, and with a governance programme ready for state regulators.
Document AIStructured outputsRules engineGraph featuresEvent busRead the case study →Case study · Startups · B2B softwareFounders shipping quickly, customers arriving, and a Series A process ahead. Architecture decisions lived in chat threads, security questionnaires were piling up and nobody owned hiring for senior engineers. The goal was technical leadership that fitted the stage: enough structure to scale and pass scrutiny, without slowing the team down.
Architecture decision recordsDORA metricsSLOsSOC 2 readinessCI/CDRead the case study →Case study · Private equity · AI software targetAn investor was close to committing to a company whose value rested on its AI. The questions were simple to state and hard to answer: is the AI really theirs, do they have the rights to the data behind it, will it scale at a sensible cost, and can this team keep building it?
Data room reviewArchitecture reviewCode reviewModel and data provenanceCloud cost modelRead the case study →Case study · Telecom · Digital and IT servicesMany monitoring tools, each owned by a different team, and incidents still reported by customers before anyone inside noticed. The goal was one telemetry pipeline, service-level objectives tied to customer journeys, and alerts that fire because users are affected rather than because a server is busy.
OpenTelemetry SDKsOBI (eBPF)OpenTelemetry CollectorOTLPPrometheusRead the case study →Case study · Real estate · Property operatorLeases, identity documents and supplier invoices arrived as scans, photos and PDFs, and every one was keyed in by hand before a tenant could be onboarded or a bill paid. The goal was to automate the routine documents and make the rest faster to check, while keeping the core system's data trustworthy.
Vision LLMStructured outputsJSON SchemaRules engineWorkflow engineRead the case study →Case study · Media · Broadcast and publishing archiveA large archive of video, audio and photographs, catalogued under decades of changing conventions, with most items described by little more than a title and a date. The goal was consistent, searchable metadata at archive scale, without letting a model invent the catalogue.
Batch LLM inferenceSpeech-to-textSKOS concept schemeDCMI Metadata TermsSentence embeddingsRead the case study →Case study · Education · Digital learningGeneric chatbots gave students answers that ignored the syllabus, skipped the reasoning and pitched the language at the wrong age. The goal was a tutor grounded in the curriculum, that guides with hints rather than handing over answers, stays safe for young learners and shows teachers where students are stuck.
LLMRetrieval over curriculum contentVector and keyword searchPrompt cachingInput and output guardrailsRead the case study →Case study · Legal · In-house and advisoryEvery incoming contract was compared to the playbook by hand, clause by clause, under deadline. The goal was not to replace that judgement but to prepare it: extract the clauses, compare them to the playbook, and propose cited redlines a lawyer accepts, edits or rejects.
LLM with structured outputsJSON SchemaLong-context modelsRetrieval over playbook and precedentsDocument parsingRead the case study →Case study · Manufacturing · Multi-plantQuality data in one system, production data in each plant's own stack, supplier data in spreadsheets and portals. Defects were found late because nobody could join the three. The goal was an open lakehouse fed by contracted data from every plant, with quality metrics everyone agreed on.
Apache IcebergSparkChange data captureOpen Data Contract StandardREST catalogRead the case study →Case study · Energy · Asset-intensive operationsMaintenance history in one system, sensor data in another, drawings and procedures in a document store. Every root-cause investigation started with an engineer stitching them together by hand. The goal was one asset knowledge graph that linked them, with an assistant that answers questions and shows its working.
RDF / OWL ontologySHACLW3C SOSA/SSNGraph databaseTime series storeRead the case study →Case study · Government · UAETeams across a UAE government entity wanted generative AI for drafting, summarising and search. Public chatbots were off the table because the data could not leave national infrastructure. The goal was a shared, in-country LLM service with one front door, redaction, routing and evaluation built in.
vLLMOpen-weight LLMsGPU clusterKubernetesAI gatewayRead the case study →Case study · SaaS · B2B platformA few heavy tenants could degrade the service for everyone, and enterprise buyers were asking for isolation guarantees the platform could not evidence. The goal was tiered tenancy: pooled by default, dedicated where it is worth paying for, with per-tenant limits and isolation proven by tests rather than asserted in a questionnaire.
MongoDBKubernetesGateway APIResourceQuotasOpenTelemetryRead the case study →Case study · Logistics · Freight and fulfilmentEvery delayed shipment produced emails: carriers, customers, warehouses, customs brokers. Staff read, classified and chased each one by hand. The goal was agents that classify exceptions, look up shipment state through governed tools and draft the next action, with a person approving anything that changes the world.
LangGraphModel Context ProtocolStructured outputsMessage queuesTMS APIsRead the case study →Case study · Retail · Stores, web and marketplacesStock moved all day in stores, warehouses and online, but channels learned about it once a night. Overselling was the predictable result. The goal was to stream every committed stock and order change from the operational databases into projections that every channel could read in near real time.
DebeziumApache KafkaKafka ConnectTransactional outboxStream processingRead the case study →Case study · E-commerce · Multi-supplier marketplaceSupplier feeds arrived with their own categories, attribute names and units. Search filters broke, facets contradicted each other and an AI shopping assistant gave confident answers from messy data. The fix was a governed product ontology that every catalogue load is mapped to and validated against.
SKOSOWL 2SHACLRDF triple storeschema.orgRead the case study →Case study · Banking · Retail and corporate onboardingOnboarding analysts were searching hundreds of policy pages and past case notes for every decision. The goal was an assistant that answers from approved sources only, shows its citations, respects who is allowed to see what, and is measured against questions compliance has signed off.
Hybrid searchVector indexRAGRe-rankingSSO and entitlementsRead the case study →Case study · Payments · PlatformAs volume grew, retries and timeouts started producing duplicate charges and a growing manual reconciliation queue. The goal was a payment path that was safe to retry at every step, published events reliably, and reconciled itself, sized for more than a million transactions a day.
PostgresIdempotency-Key headerTransactional outboxDebeziumKafkaRead the case study →Case study · Fintech · Digital payments and lendingFraud rules scored one transaction or one account at a time, while organised fraud spread across many accounts sharing devices, addresses and payees. The goal was to resolve those shared entities, connect them in a graph, and give risk models and investigators the network view the rules were missing.
KafkaSplink-style probabilistic matchingGraph databaseConnected componentsFeature storeRead the case study →Case study · Life sciences · PharmaceuticalA pharmaceutical evidence team licensed data from several partners and started every study with a new data pull and months of cleaning. The goal was a study pipeline that ran the same pre-specified design at every partner, measured its own bias, and could be re-run exactly when a regulator asked.
OMOP CDMOHDSI HADESStrategusCohortMethodATLASRead the case study →Case study · Health insurance · PayerPrior authorisation ran on fax, phone and portals, and a federal rule had set dates for API-based exchange. The goal was standards-based FHIR APIs that providers could call, wrapped around claims and utilisation management systems that could not be replaced in time.
FHIR R4Da Vinci CRDDa Vinci DTRDa Vinci PASCDS HooksRead the case study →Case study · Healthcare · Provider groupClinicians were finishing notes in the evening, and every AI scribe pilot had stalled in security review. The goal was a private ambient documentation pipeline that drafted notes for clinician sign-off, ran on infrastructure the organisation controlled, and could prove what happened to every recording.
SMART on FHIRFHIR R4 DocumentReferenceWhisper-class ASRvLLMPrivate GPU nodesRead the case study →Case study · Healthcare · Hospital networkSeveral hospitals, several EHR configurations, and a research team waiting months for every dataset. The goal was one standardised, quality-checked research platform on OMOP, fed from FHIR, that could answer questions locally and join federated studies without moving patient data.
FHIR R4Bulk Data exportOMOP CDM v5.4OHDSI vocabulariesData Quality DashboardRead the case study →Typical use cases I design and build for: the problem, the approach, the flow and the stack. Pick your sector, then book a call to talk through yours.
Problem. Clinicians spend evenings on notes; AI scribe pilots stall in security review.
Approach. Private speech and LLM pipeline that drafts notes into the EHR for clinician sign-off, with SMART on FHIR scopes and full audit.
Problem. Faxes and portals slow approvals while new interoperability rules set API deadlines.
Approach. FHIR prior authorisation and coverage APIs in front of existing claims systems, with decision tracking and metrics reporting.
Problem. Each study needs a new data pull and months of cleaning before the first result.
Approach. OMOP-standardised data with reusable cohort definitions and study packages that run across data partners.
Problem. Row-by-row fraud rules miss coordinated accounts sharing devices, addresses and payees.
Approach. Entity resolution into a graph of customers, devices and payments, with graph features feeding risk scoring and investigator tools.
Problem. Retries and timeouts cause duplicate payments and manual reconciliation as volume grows.
Approach. Idempotent APIs, an outbox pattern and event-driven reconciliation sized for more than a million transactions a day.
Problem. Analysts search hundreds of policy pages and past cases for every onboarding decision.
Approach. Retrieval over approved policy and case notes with citations, permission-aware access and an evaluation set signed off by compliance.
Problem. Inconsistent categories and attributes make search, filters and AI shopping assistants unreliable.
Approach. A product taxonomy in SKOS with a small OWL core, synonyms for search, and validation on every catalogue load.
Problem. Nightly batch syncs oversell stock across stores and online channels.
Approach. Change data capture from operational databases into an event stream that keeps inventory views current everywhere.
Problem. Delayed shipments generate thousands of emails that staff triage by hand.
Approach. Agents that classify exceptions, look up shipment state through governed tools and draft actions for approval.
Problem. Noisy tenants slow everyone down and enterprise buyers ask for isolation guarantees.
Approach. Tiered tenancy with pooled and dedicated options, per-tenant limits, and data isolation proven in tests.
Problem. Teams want generative AI but data cannot leave national infrastructure.
Approach. In-country model serving with an AI gateway, PII redaction, routing and evaluation, aligned to UAE data rules.
Problem. Maintenance history, sensor data and drawings live in separate systems, so root causes take weeks.
Approach. A graph linking assets, components, work orders and sensor streams, with natural-language questions over it.
Problem. Quality, production and supplier data cannot be joined, so defects are found late.
Approach. An open-table-format lakehouse with data contracts from each plant and governed metrics for quality.
Problem. Reviewers compare every contract to playbooks by hand under deadline.
Approach. Clause extraction to a structured schema, comparison against the playbook, and cited suggestions a lawyer accepts or rejects.
Problem. Generic chatbots give answers that don't match the syllabus or age group.
Approach. A tutor grounded in the curriculum with safety filters, guided hints instead of answers, and teacher dashboards.
Problem. Decades of content are hard to find because metadata is sparse and inconsistent.
Approach. Batch enrichment with models into a controlled vocabulary, human review queues and searchable embeddings.
Problem. Leases, IDs and invoices are keyed in by hand, slowing onboarding.
Approach. Extraction to validated schemas with confidence thresholds and exception queues, feeding the core system.
Problem. Many monitoring tools, no shared view, and incidents found by customers first.
Approach. OpenTelemetry end to end with a collector gateway, service-level objectives and burn-rate alerting.
Problem. Investors need to know whether the AI, the data rights and the team are what the deck says.
Approach. A structured review of architecture, model and data provenance, security, costs and team, with a risk-rated report.
Problem. Founders are shipping fast but architecture, hiring and security are falling behind investor expectations.
Approach. A part-time CTO who sets the technical roadmap, decision records, delivery metrics and the first senior hires.
Problem. Manual first-pass triage leaves simple claims queued behind complex ones and depends on who reads the file.
Approach. Schema-validated extraction, cited summaries and explainable signals that suggest routing for adjusters to accept or override, under a written AI programme.
Problem. Assistants connect to unreviewed MCP servers with broad personal tokens and no audit trail.
Approach. A private MCP registry, a gateway tied to the identity provider, progressive scopes and audit for every tool call.
Problem. Cloud spend grows faster than the business and nobody can say which team or product drives it.
Approach. Enforced ownership labels, workload cost allocation joined to FOCUS billing, in-place right-sizing and queue-driven scale to zero in service templates.
Problem. Many AI features, no shared definition of good, and model upgrades that break things customers notice first.
Approach. Owned evaluation sets as CI release gates, a model gateway, OpenTelemetry GenAI tracing and cost and quality per feature.
Problem. Potential safety signals tracked in spreadsheets, with slow bespoke evaluations and no audit trail.
Approach. One tracked record per signal, scheduled screening of reports, physician validation and real-world data evaluation on OMOP with negative controls.
Problem. Each study rebuilds vendor pipelines, and the path from raw data to submission datasets is undocumented.
Approach. An immutable raw zone, versioned SDTM mappings in a shared library, checks on every load and lineage with audit trails designed for validation.
Problem. Every enterprise deal stalls on AI and security questionnaires while EU, US and Gulf rules keep moving.
Approach. One AI inventory, a unified control set mapped to the EU AI Act, ISO 42001, NIST AI RMF and SOC 2, and evidence generated by delivery pipelines.
Problem. Copied modules, giant state files and secrets in state across three clouds make every change slow and risky.
Approach. Composed provider-specific modules, state split by blast radius, secrets kept out of state, and pipeline-only applies with policy checks.
Problem. Screen scraping and one-off bank integrations break often and fail security reviews.
Approach. A consent service at the core, a FAPI-grade connector to the Central Bank's API hub, isolated tokens and data minimised at ingestion.
Problem. Customers write in Gulf Arabic, MSA, English and mixed text, while policies exist in only one language.
Approach. One bilingual index with multilingual embeddings, Arabic normalisation, answers in the customer's language with citations, and in-country hosting.
Problem. Too many alerts across tools with different data formats, and analysts wary of AI that invents findings or acts on its own.
Approach. Normalise events to OCSF, add ATT&CK and runbook context, and let a read-only copilot draft cited triage summaries and propose actions for analyst approval.
Problem. An actively exploited PHP flaw, and nobody could say quickly where PHP was running or which versions were out of support.
Approach. Build a live runtime inventory, contain and patch through golden images, trace legacy apps before changing them, then migrate route by route behind a facade.
Problem. Consent was a sign-up checkbox, and nobody could prove a withdrawal reached every partner holding the data.
Approach. An append-only consent ledger per purpose, withdrawals published as acknowledged events, retention jobs that delete with proof, and consent manager interfaces.
Problem. Consumer AI agents started shopping and booking for people, but the marketplace was built for humans and scrapers.
Approach. Machine-readable inventory and prices, an agent API and MCP tools, hold-and-approve idempotent booking, and separate routing and limits for agent traffic.
Problem. Critical claims and service processes depended on one hosted model provider with no tested alternative.
Approach. Map AI uses to critical operations, put a gateway in front of every model call, add a second provider and a private model, and rehearse failover and exit with live traffic.
Problem. Product data was used only internally, but the EU Data Act requires users to access it and share it with others.
Approach. Scalable OTLP ingestion, a readable data catalogue, raw data separated from derived models, and self-service access and sharing with consent.
Problem. Technicians held standing admin access to hundreds of customer environments, and incidents could not be traced quickly to affected customers.
Approach. One identity provider for people and automation, just-in-time recorded access, an incident pipeline with reporting timelines, and a customer impact map for notification.
Problem. AI matched and summarised candidates, but nobody could show which steps used AI, how they were tested or how a candidate could challenge them.
Approach. An AI inventory, GenAI tracing as the evidence store, an evaluation gate with group checks, and a reviewer workbench where people make every adverse decision.
Short form: the challenge, the approach, the architecture and the result, one tab each.
A multi-division organisation where every system had its own idea of a customer, product and contract.
Reports never reconciled, and the first AI assistant confidently gave the wrong answers.
A transactional platform built on synchronous calls and a shared database.
Peaks caused latency spikes, overnight batches overran, and releases were scary.
A regulated organisation wanted to put its data and AI to work across the US and the Gulf.
Every new use case stalled in security reviews and data-residency questions.
EHR, lab, claims and device data in different formats and code systems.
Each integration was a bespoke project, and research cohorts took months to assemble.
Leadership wanted generative AI, but legal would not allow sensitive records to reach a public API.
The project had stalled at "we can't".
Client names, figures and specifics are withheld under confidentiality. Detailed references available on request.
The fastest route is a free 30-minute call. Prefer to write? Send a message and I'll reply personally within two business days.