AI infrastructure
DocAI
Unstructured documents into evidence backed data
- Role
- Designer and lead engineer, at SALI AI
- Built with
- Python
- FastAPI
- React
- TypeScript
- PostgreSQL
- pgvector
- FAISS
- LiteLLM
- Whisper
- Tesseract
- AWS S3
- Docker
The AI layer underneath several enterprise products. It turns unstructured documents, mostly sustainability and financial reports, into structured data where every extracted value carries the evidence it came from. It reads text, spreadsheets, audio, video, and images.
01
Why it exists
An extracted number nobody can trace is worse than no number, because someone will act on it. In regulatory and sustainability reporting, a figure that cannot be pointed back to its sentence in its source document is not usable in a filing, whatever its accuracy.
The second problem was reach. The organisation kept needing the same reading capability in different products, and each one was reimplementing it.
02
What was built
Ingestion across the formats an enterprise actually sends: PDF, Word, spreadsheets in several dialects, structured financial filing formats, audio through speech to text, video through both its audio track and text sampled from its frames, and standalone images through optical character recognition.
Video is treated as two independent sources, what was said and what was shown, and every chunk records which one it came from, so the two are never confused downstream.
A standards knowledge base, guided extraction against it, accounts and tenancy, background jobs, and thin client libraries in Python and JavaScript over the same API.
03
Architecture
Three engines that separate cleanly, so a caller who needs one is not forced to adopt all three.
Extraction takes any input and produces structured content, and by default it does this with no language model involved at all: parsers, optical character recognition, and speech to text, but no inference. A model is called in exactly one place, when an image yields no text at all, and only when the caller asks for it and supplies their own key.
Retrieval indexes and searches that content, over a vector backend that can be swapped between an in-process index and the database itself.
Compliance judges retrieved content against a standard, which is the only layer that reasons rather than reads.
The service runs stateless by default, holding nothing, with persistence, tenancy, and background jobs as options rather than requirements. That is what lets one deployment serve a product that wants a database and another that wants nothing kept.
04
My contribution
Designer and lead engineer. The architecture, the three engine separation, the ingestion and retrieval layers, the API, and the client libraries.
05
Engineering challenges
Making the compliance side read documents through the same engine as everything else, rather than keeping a second reader. Each format that moved over kept its previous reader as a same request fallback, never as a second primary path, so the migration could not quietly leave two implementations behind.
Large spreadsheets, which have to be windowed into chunks rather than read whole, or retrieval quality collapses on exactly the documents that matter most.
Keeping the extraction engine genuinely free of model calls, which is a discipline rather than a feature: it is the reason the engine can be pointed at confidential documents at all.
06
Result and impact
Became the central AI layer for several products across the organisation rather than the single purpose tool it started as, and is the extraction engine the regulatory platform depends on.