London specialty insurance market3 months, ongoingFinancial services and insuranceLive engagementProof of conceptRoughly a year of stalled work, rebuilt as a working proof of concept in two weeks
12 months → 2 weeksprior build effort rebuilt as a working proof of conceptBlank repository on Azure. Markdown-first extraction, third-party API enrichment, confidence scored from source provenance plus model certainty plus a search cross-check.Expand the engagement here
A working proof of concept in two weeks: PDFs in, business intelligence out on Azure, covering ground that had previously taken this business roughly twelve months. We pair-programmed the entire fortnight with one of the client's own engineers, who ended it saying they were 70% confident they could run the process without us. Month one was the audit that pulled us across the whole programme; month two was this build.
- the client engineer's own confidence they could run the process unaided afterwards
- 70%
- AI-engineering proof of concept delivered, from a month-1 start
- Month 2
A specialty insurance business was running a complex multi-workstream programme with delivery stalling in the gaps between product, engineering and platform. Data quality issues were blocking development and testing, a security gate was approaching with no coordination owner, delivery tooling was split across Azure DevOps boards and GitHub, and the leadership team wanted an AI strategy that amounted to more than a set of tool licences. The immediate need was momentum; the underlying need was a different way of building.
Month one was an audit, and it took us across far more of the programme than a readout exercise would have. We took ownership of whatever was actually blocking delivery: unblocking the data issues holding up development and testing, supporting disaster-recovery failover planning and release governance, and leading the migration from Azure DevOps boards to a GitHub-based delivery model with agent-assisted workflows. In parallel, on the operating-model workstream, we contributed to the workshops shaping product vision, data strategy and the AI operating model, and produced the structured outputs defining MVP focus, data foundations and AI strategy. The value of doing it that way is that by the end of the month we understood the estate from the inside rather than from a survey.
Month two went after the capability the business had been circling for roughly a year: getting information out of PDFs and turning it into business intelligence. We ran our AI-engineering-first method. Every requirement (PDFs, diagrams, images) became structured markdown, AI built a knowledge map across the corpus, and a gap-and-contradiction pass surfaced ambiguities the business had not realised were ambiguous, before a line of code was written. Those went back to the subject-matter experts and were resolved in conversation rather than in rework.
Only then did the build start, from a blank repository on Azure, with high-level prompts against the whole requirement set and a security review roughly every fifth prompt. This was greenfield. It replaced work that had stalled rather than changing a running system with existing behaviour to preserve, and the two-week figure should be read in that context. The pipeline itself is set out stage by stage below.
The entire fortnight was pair-programmed with one of the client’s own engineers, because a proof of concept nobody internal can reproduce is a demonstration rather than a capability.
- 1Extract to markdownEvery source document is converted to markdown before anything else happens, so what the model actually read stays inspectable by a human rather than disappearing into an embedding.
- 2Narrow to the key fieldsThe markdown is reduced to the fields the business needs, rather than carrying whole documents forward and paying for them at every later step.
- 3NormaliseFields are normalised into consistent shapes and units, so downstream logic compares like with like instead of guessing.
- 4Enrich against third-party APIsRecords are enriched from external sources, and each enrichment carries the provenance of the source it came from.
- 5Add semantic context and thematic groupingRelated records are grouped and given the context a person would otherwise add by hand when reading them side by side.
- 6Apply business logicThe client's own rules run over the enriched record. This is the layer that is theirs, not ours, and it is the layer that changes most often.
- 7Land in the dashboardOutput lands in an internal dashboard the business already uses, rather than in a tool that only exists while we are there.
- Source provenance. How much the source of a given enrichment is worth trusting.
- Model certainty. What the model itself reports about the extraction or the match.
- Search cross-check. An independent search-based check against the value that was produced.
Those three produce a confidence score on the record, and the score is an input to routing rather than a display value. Review is routed by confidence and consequence together, so a low-confidence field on a high-consequence record reaches a human first and a high-confidence field on a low-consequence one does not generate work. That is a routing rule, not an assurance framework, and it has not been through a regulator or an audit.
In two weeks the proof of concept was working: PDFs in, structured and enriched data out, business intelligence on a dashboard the business could use, covering ground that had previously taken roughly twelve months. A separate AI data-quality proof of concept on Azure OpenAI demonstrated that entity-resolution output could be validated and scored automatically, with human review prioritised rather than queued.
The number we care about most is the softest one. At the end of the fortnight we asked the client engineer who had paired on the whole build how confident they were that they could follow the process and deliver the next outcome without us. They said 70%, and 70% after two weeks is the difference between having bought a proof of concept and having started to acquire a capability.
The two-week build is a proof of concept, not a production deployment. Month three stands up an adjacent agent-led engineering team to productionise it against the organisation’s security standards, on a four-to-six week target.
The architecture in detail, the model and platform choices, the prompt and review approach, and the working history of the fortnight sit under client confidentiality, alongside the client's name. You should expect the same treatment of your name and your estate if you engage us.
What transfers is the whole shape of the engagement: one senior person accountable from month one, the operating-model outputs produced alongside the build, a monthly cadence with something real at the end of each month, and a handover built into the build rather than bolted onto the end of it. What does not transfer yet is production. This is a working proof of concept built inside the client's regulated estate, month three is productionising it against the client's security standards, and the result will be published here, dated, when it lands.