Data
NDPS and FRC
Regulatory compliance analysis for a national reporting council
- Role
- Backend architect, at SALI AI
- Built with
- Python
- FastAPI
- Celery
- MongoDB
- Redis
- AWS S3
- Google Cloud Storage
- Cloudinary
- MinIO
- React
- TypeScript
- LiteLLM
- WebSockets
A document intelligence platform supporting Nigerian regulatory operations. It ingests corporate sustainability and financial reports, analyses them against international reporting standards, and produces investor grade compliance reports with a human review step before anything is issued.
01
Why it exists
A reporting council receives filings faster than any team can read them, and the reading is not skimming. Each report has to be judged clause by clause against a framework, and the judgement has to be defensible afterwards.
Automating the judgement outright would be the wrong answer. What was needed was the reading done at machine speed and the decision left with a person.
02
What was built
Analysis across the standards the council works to, including the two main sustainability disclosure standards, sector specific reporting, materiality assessment, conceptual foundation review, and a chained data consistency audit that runs three checks in sequence.
Three report families: a narrative detailed report, a scorecard style comprehensive report, and a company facing summary carrying both reviewer and council feedback.
Role gated access across the parties involved, and live job progress over WebSockets.
A storage layer written against the idea of object storage rather than against a vendor. The same code runs on local disk during development, MinIO in a container, Amazon S3 or Google Cloud Storage in production, and Cloudinary for media, selected by one setting. Regulatory work outlives the platform decisions made around it, so where a filing is kept had to be a configuration question rather than a migration.
The ESG intelligence layer that lets an organisation process sustainability information through these workflows rather than by hand, which is the part that made the platform useful beyond compliance checking.
03
Architecture
The platform is deliberately a thin orchestrator. Every heavy operation, parsing, optical character recognition, model driven extraction, is delegated to the DocAI service over HTTP, behind a single client class that is the only seam between them. This platform owns documents, the job pipeline, results, review, and reports, and nothing else.
The frameworks themselves are data, not code. The clauses, prompts, and scoring for each standard live in structured files, including sector specific variants across roughly seventy seven industries, so tuning an analysis is editing data and adding a standard does not mean a release.
Upload, then dispatch exactly one background job per requested framework, then publish progress to a channel the interface subscribes to, so a long analysis reports itself rather than being polled.
Reports are assembled by orchestrators that fan out to per section agents, each responsible for one part of the document, over a model client with fallbacks behind it.
04
My contribution
Backend architect. The job pipeline, the extraction boundary, the framework data model, the report orchestrators, the storage abstraction, and the role model.
05
Engineering challenges
The API is asynchronous and the workers are not, which means two database access paths that must never be crossed. The boundary is explicit rather than incidental, because the failure mode when it is crossed is silent.
Keeping a human in the loop without making them the bottleneck, which shaped the review lifecycle more than any technical constraint did.
06
Result and impact
Delivered into Nigerian government regulatory operations, supporting the financial reporting council's review of corporate sustainability disclosure.