About Paul Lewis

Why I Built Contexta

Every large programme I have worked on has hit the same wall. Somebody produces a 200-page requirements document. It gets emailed around. People skim it. They highlight the bits they understand, ignore the bits they do not, and assume someone else has read the rest. Then six months later, in UAT, you discover the non-functional requirement that kills the architecture was sitting in paragraph 47 of appendix C the whole time.

I have watched this happen on programmes worth tens of millions of pounds. At DWP, at MOJ, at NHS Digital. The technology changes, the documents change, but the failure mode is always the same: people do not have a structured way to break down what a document actually says, what it implies, and where the gaps are.

Contexta started as a spreadsheet. Then a Python script. Then a proper application. The core idea has always been the same: give teams a structured way to process documents so that requirements, risks, and uncertainties are surfaced before decisions are made — not discovered during testing.

The platform is built as a set of analysis engines, each tackling a different aspect of the problem. CEIUS handles requirements analysis with a five-stage decision framework. PerfTest brings structure to performance test result analysis. More engines are coming. The common thread is that they all turn unstructured information into structured, auditable outputs that teams can actually act on.

I built Contexta because I wish I had it on every project I have ever worked on. Not as a replacement for human judgement — I have never believed AI can replace experienced analysts — but as a tool that handles the grinding, repetitive extraction work so people can focus on the decisions that actually matter.