Retrieval & RAG engineering
Hybrid dense and lexical retrieval, reciprocal-rank fusion, reranking, and chunking strategies chosen against measured recall — not defaults.
Founder
Founder & Lead Engineer, CraftWyre
I build AI systems that cite their sources, refuse to guess, and hold up when the answer matters.
Introduction
I am a software engineer working on applied AI — retrieval systems, multi-agent pipelines, and the product engineering around them. CraftWyre is the company I founded to do that work properly: architecture first, evaluation before claims, and systems a team can still maintain a year later.
Most of my work sits in one narrow place: getting a language model to answer from a specific body of evidence, and to say nothing when the evidence is not there. That constraint shapes everything downstream — how documents are parsed and indexed, how retrieval is scored, how an answer is verified before a user ever sees it, and how the system reports what it could not resolve.
It is a constraint worth taking seriously because of where these systems get used. Legal research, financial analysis, tax and compliance, public-sector information — the domains I keep building for are the ones where a confident wrong answer costs more than no answer at all. Groundline, the product I am developing at CraftWyre, is built entirely around that idea: every answer carries the document, the page, and the excerpt behind it, an independent verification step removes anything the sources do not support, and the system refuses rather than fabricates.
The second thread running through the work is language. Ask in Urdu, get an answer in Urdu — with Arabic, Hindi, Turkish, and right-to-left rendering treated as first-class rather than an afterthought. Most polished tools in this space are English-first. Building for the region I work in meant solving cross-language retrieval properly, and that turned out to be an advantage rather than a tax.
I work across the whole stack because these systems fail at the seams. That means FastAPI and Python for the retrieval and agent layer, Next.js and React for the interfaces, Postgres, Redis, and vector search underneath, Docker and CI around it, and a real evaluation suite so a change to a prompt or a reranker is measured rather than guessed at.
At a glance
- Role
- Founder & Lead Engineer, CraftWyre
- Focus
- Retrieval-grounded AI, document intelligence, agent systems
- Building
- Groundline
- Projects
- 8 shipped or in active development
- Based
- Pakistan · Working with teams worldwide
What I do
These are the layers I build and maintain end to end — from how a document is parsed to how an answer is proven before anyone reads it.
Multi-agent systems
Planner, retriever, synthesizer, and verifier as separate roles with narrow permissions, so document content is treated as data and never as instructions.
Grounding & verification
An independent pass that re-checks every claim and citation against the retrieved evidence and drops whatever the sources do not support.
Multilingual NLP
Cross-language retrieval, Unicode-aware lexical search, language-matched answers, and correct right-to-left rendering across 100+ languages.
Document intelligence
PDF structure extraction with headings, tables, and OCR fallback; page preservation, deduplication, and document versioning through ingestion.
Secure multi-tenant architecture
Server-controlled tenant scope, isolated vector namespaces, envelope-encrypted object storage, scoped RBAC, and structured audit events.
Evaluation & reliability
Regression benchmarks for numeric recall, citation precision, unsupported-claim rate, latency, and cost, wired into CI as release gates.
Full-stack product engineering
FastAPI and Next.js applications with durable background jobs, admin controls, and the operational surface a real deployment needs.
Portfolio
Commercial products, client work, and the systems that came before them. Each entry carries an honest status — nothing here claims a result that has not been measured.
LeXAI
An AI-native legal research and drafting assistant built specifically for Pakistani law.
Retrieval-grounded over a corpus of Pakistani statutes and Supreme Court judgments, with a drafting engine that turns one conversational message into a court-ready document. Holdings and verbatim excerpts are shown separately so a lawyer can verify a citation rather than trust a paraphrase, and bailability follows a stated rule applied uniformly instead of a lookup table.
- Python
- LangGraph
- Vector search
- Next.js
MarketMind AI
An explainable market-research system producing an auditable bull/bear verdict for any ticker.
A fixed LangGraph workflow blends fundamentals, macro regime, and news sentiment into a 1–10 verdict where every layer stays independently auditable, alongside a price forecast with confidence bands and a walk-forward backtest. Includes a fully offline deterministic demo mode. Decision-support material only — not financial advice.
- FastAPI
- LangGraph
- React
- TypeScript
- Docker
Botline
A multi-tenant WhatsApp and Telegram gateway that puts document Q&A into the apps customers already use.
Webhook to dedupe to persist to queue to worker, end to end, with per-business tenancy and CLI onboarding. Built to call Groundline's chat API for retrieval-grounded replies while staying general enough for non-RAG handlers.
- FastAPI
- Telegram API
- WhatsApp API
- Background workers
LeXQuery
A retrieval system answering questions on Pakistani law with source citations across the PPC, CrPC, and Constitution.
The predecessor to LeXAI, and where the citation-first approach was first proven: retrieve from the statute corpus, answer only from what was retrieved, and show the source behind every statement.
- LangChain
- ChromaDB
- FastAPI
- OpenAI
Streaming Support Assistant
A RAG support chatbot with token-by-token streaming and a confidence-threshold fallback to a human.
FAISS vector search over a curated knowledge base, answers streamed over server-sent events, and a deliberate hand-off path: below the confidence threshold the bot escalates rather than improvising.
- FastAPI
- FAISS
- Server-sent events
How I work
They cost time up front and save it everywhere else — most of all when a system reaches the point where somebody makes a decision on what it said.
Start with the failure, not the feature
The first question on any system is what a wrong answer costs. That answer decides the architecture — how much verification, how much human review, how much the system is allowed to say on its own.
Evidence over eloquence
An answer that reads well and cannot be traced is worse than a short one that can. Citations, page numbers, and excerpts are product features, not debug output.
Measure before claiming
Retrieval quality, citation precision, unsupported-claim rate, latency, and cost get benchmarked in CI. If a number is not measured, it does not go in a sentence.
Refusal is a feature
A system that knows the boundary of its evidence is more useful than one that always produces something. Saying "not in these documents" is the behaviour I optimise for.
Build it so someone else can keep it
Clear module boundaries, real test suites, written architecture decisions, and deployment that is documented rather than remembered.
Toolkit
Languages
- Python
- TypeScript
- SQL
AI & retrieval
- LangGraph
- LangChain
- Pinecone
- FAISS
- ChromaDB
- BGE-M3
- Rerankers
- MCP
Backend
- FastAPI
- Pydantic
- PostgreSQL
- Redis
- RQ
- Prisma
Frontend
- Next.js
- React
- Tailwind CSS
- Framer Motion
Platform
- Docker
- GitHub Actions
- Prometheus
- S3 + KMS
- Vercel
Have something difficult to build?
Tell me about the users, the information, and what a wrong answer would cost. I will tell you honestly whether this is the right approach and what it would take.