In October 2024 I started building Sheria Platform: an AI-powered judicial intelligence system for Kenya's court system. I built it independently, from scratch, and it went on to get shortlisted in Kenya's NIRU National AI Hackathon 2025 (Governance & Policy track) from 2,467 proposals out of 5,656 national registrants. This post is about the architecture decisions behind it — specifically, why legal retrieval needed more than a standard RAG stack.
Why legal research is a harder retrieval problem
Most RAG demos treat retrieval as "find the top-k most similar chunks." That's a reasonable starting point for FAQ bots, but it breaks down for legal research. A lawyer or judge doesn't just want a passage that sounds relevant — they need to know whether the case it comes from is still good law. A precedent that's been overruled is worse than useless if it's presented with the same confidence as a controlling authority. Similarity search alone has no concept of that.
An agentic pipeline instead of a single retrieval call
Sheria's core is a LangGraph agentic graph with three stages:
Planner → Retriever → Responder. The Planner breaks down the
legal question before any retrieval happens. The Retriever runs targeted
searches against Qdrant vector indexes built over Kenya Law
Reports. The Responder composes the final answer using
IRAC prompting — Issue, Rule, Application, Conclusion — the
same structure lawyers are trained to reason in, rather than a generic
paragraph of prose. Responses stream back to the frontend as NDJSON so the
UI can render incrementally instead of waiting on a full generation.
A citation graph, not just a vector index
The part that actually addresses the "is this still good law" problem is a
Neo4j citation graph layered on top of retrieval. Case
relationships are modeled as explicit edges — CITES,
OVERRULES, DISTINGUISHES — so the system can
traverse from a retrieved case to what it cites, what overruled it, and what
later distinguished it. That graph traversal is what turns a similarity match
into something closer to actual legal research.
Keeping it fast, self-hosted, and cheap to run
None of this goes through an external LLM API. Inference runs on a 3-node
Ollama GPU cluster (RTX 3050s) serving Qwen2.5:7b. To keep
repeated queries cheap, I added semantic caching on top — Qdrant
+ Redis, matching on cosine similarity above 0.95 with a 30-day
TTL — so near-duplicate questions don't trigger a full inference pass every
time.
Making it a real platform, not a notebook demo
The rest of the stack exists to make this production-shaped: FastAPI microservices with JWT-based RBAC, Prometheus metrics and OpenTelemetry tracing for observability, M-Pesa STK Push payments via the Safaricom Daraja API, and a Next.js frontend with an admin panel, an ingestion job monitor, and a health dashboard. It's the same discipline I apply to production data infrastructure at my day job, just pointed at a different problem.
Where it stands
Sheria is currently in the prototyping and mentorship phase after the NIRU hackathon shortlist — a validation that the "traceable, self-hosted legal AI" framing resonates beyond just me. I'll be writing more here as the retrieval and citation-graph work evolves.