DEV Community: Shahrukh

# What Happens When You Try to Build a Lawyer for Someone Who Can't Afford One?

Shahrukh — Sat, 04 Jul 2026 00:40:11 +0000

The Problem That Wouldn't Leave Me Alone

Pakistan has 220 million people. A functioning legal system. Hundreds of Acts, ordinances, and constitutional provisions that technically protect every citizen.

Almost nobody can use them.

The median lawyer's consultation fee in Karachi is more than what many families earn in a week. Legal aid is understaffed and geographically concentrated in major cities. And the laws themselves? Written in English — a language most of the population reads functionally at best, and doesn't speak at home at all.

So when a landlord illegally locks someone out. When a factory worker gets fired without severance. When a woman wants to know her inheritance rights. When a tenant needs to understand what "Section 16 of the Rent Restriction Ordinance" actually means for their specific situation — they either find a lawyer they can't afford, ask someone who doesn't really know, or quietly give up.

This isn't a knowledge problem. It's an access problem.

I'm a CS student at Sukkur IBA University in interior Sindh — not Karachi, not Islamabad. The kind of city where you feel the gap between what the law says and what people actually know it says every single day. That gap is where HAQ started.

HAQ is an Arabic and Urdu word. It means right — as in, what is rightfully yours.

The name felt important.

The Core Idea: Ask the Law, Get the Law

There's a specific failure mode with AI and legal questions that drove every design decision I made, and it's worth naming clearly.

Standard LLMs — any of them — will answer legal questions confidently. They'll cite "Section 144" or "the Transfer of Property Act" with total authority. They are often wrong. Sometimes subtly: the section exists but doesn't say what the model claims. Sometimes obviously: the Act doesn't apply in that province. Always uncitable: the user has no way to verify without finding the source themselves.

For an accessibility tool, a confidently wrong answer isn't neutral. It's actively dangerous. Someone might not challenge their landlord, file the wrong petition, or miss a critical deadline because an AI answered with a tone that didn't invite doubt.

The insight behind HAQ: don't let the model make legal claims it can't back up with a document you retrieved yourself.

RAG — Retrieval-Augmented Generation — is the technical name. The idea is: before the model speaks, find the relevant passages from actual Pakistani legislation. Feed those passages to the model. Tell the model it can only answer using what it was given. Link directly to the source.

If it can't find a relevant passage? Say so. Don't hallucinate.

That's the whole system. Everything else is engineering to make it work at scale, in Urdu, for Pakistani law specifically.

Phase 1: The Data Problem Nobody Talks About

Building an AI on Pakistani law first requires having Pakistani law.

This sounds obvious. It was not simple.

Pakistan's legal documents are scattered across government portals of varying quality — sometimes available as scanned PDFs, sometimes as HTML tables with broken encoding, sometimes simply not publicly available in machine-readable form at all. The Federal Legislative List, provincial Acts, ordinances — each comes from a different source with different formatting conventions and different levels of digitization.

I ended up with 100+ Acts. The pipeline: download, extract text, clean it, chunk it into pieces an embedding model could meaningfully index.

Chunking strategy matters more than it sounds. Split too coarsely and a single chunk contains an entire Act — retrieval becomes a lottery. Split too finely and a clause is torn from its context — the model retrieves words without meaning. I settled on section-level chunking: each chunk is one section of one Act, plus metadata (Act name, section number, jurisdiction, source URL).

4,000+ chunks. Source link back to the original legislative document for every single one.

The Embedding Nightmare: From 10 Hours to 8 Minutes

The first time I ran the full embedding pipeline, it took 10 hours and 23 minutes.

This is the part of ML projects nobody tweets about. You write the code, it looks correct, you kick it off, and you go to sleep because it will still be running when you wake up.

The problem was sequential API calls. For each chunk, the pipeline would:

Send chunk text to Cohere's embedding API
Wait for response
Store the vector in Pinecone
Move to the next chunk

Each round trip takes roughly 200ms. Four thousand chunks × 200ms = around 800 seconds in pure API wait time, before you account for network variance, rate limiting, and Pinecone write latency. In practice: over ten hours.

The fix was embarrassingly obvious in hindsight:

# Before: sequential, one chunk at a time
for chunk in chunks:
    embedding = cohere.embed(chunk.text)
    pinecone.upsert([(chunk.id, embedding, chunk.metadata)])

# After: batched — the way the APIs were designed to be used
COHERE_BATCH = 96
PINECONE_BATCH = 100

for i in range(0, len(chunks), COHERE_BATCH):
    batch = chunks[i:i + COHERE_BATCH]
    embeddings = cohere.embed([c.text for c in batch])  # one API call, 96 texts

    vectors = [
        (c.id, emb, c.metadata)
        for c, emb in zip(batch, embeddings.embeddings)
    ]

    for j in range(0, len(vectors), PINECONE_BATCH):
        pinecone.upsert(vectors[j:j + PINECONE_BATCH])

New runtime: 7 minutes and 43 seconds.

Same 4,000+ chunks. Same vectors. Same output. 87× faster — just by respecting the batch interfaces that were there all along.

If you're building anything with embedding pipelines: batch from day one. Sequential processing is only acceptable for five-chunk demos.

The Hallucination Problem, Specifically

RAG reduces hallucination. It doesn't eliminate it.

Language models are trained to be helpful, which means they're trained to complete answers even when they should say "I don't know." Give a model three retrieved chunks and ask a question those chunks don't quite answer — it will often bridge the gap with something plausible-sounding that came from training weights, not from what you gave it.

For general Q&A, that's annoying. For legal advice, it's a liability.

I spent more time on the system prompt than on any other single piece of code. The key constraints ended up looking like this:

You are HAQ, a Pakistani legal assistant.

RULES YOU CANNOT BREAK:
1. You may only cite law that appears in the RETRIEVED CONTEXT below.
2. If the context does not contain a clear answer, respond with:
   "I couldn't find a clear answer in the available legislation.
    Please consult a qualified lawyer for this situation."
3. Every legal claim must end with a citation: [Act Name, Section X]
4. Never speculate about intent, enforcement, or likely court outcomes.
5. If the user's province is unclear, ask before answering.

Rule 2 was the hardest to nail. Models resist admitting ignorance — you have to make the refusal feel like a legitimate, well-formed response rather than a malfunction. The phrasing "I couldn't find a clear answer in the available legislation" was tested against probably thirty variations before it consistently produced the behavior I wanted without the model trying to work around it.

The citation layer closes the loop. Every retrieved chunk carries a source URL. When HAQ cites [Rent Restriction Ordinance 2001, Section 8], the UI renders that as a live link to the actual government document. The user can verify. The model can't hide behind vague authority.

Temperature: 0.1. Deliberate. Legal answers should be boring and accurate, not creative.

The Fallback Chain: Four Models, One Query

HAQ runs inference on Groq — specifically because of the inference speed. For someone who might be in genuine distress about an eviction notice or a wrongful termination, waiting fifteen seconds for an AI to respond is a UX failure.

But Groq's free tier has rate limits. Models have context window limits. Sometimes a specific model is just unavailable. So I built a fallback chain:

MODELS = [
    "llama-3.3-70b-versatile",   # Primary: best reasoning quality
    "llama-3.1-70b-versatile",   # Fallback 1
    "llama3-70b-8192",           # Fallback 2
    "mixtral-8x7b-32768",        # Fallback 3: longest context window
]

def query_with_fallback(prompt: str, context: str) -> str:
    for model in MODELS:
        try:
            response = groq_client.chat.completions.create(
                model=model,
                messages=[
                    {"role": "system", "content": SYSTEM_PROMPT},
                    {"role": "user", "content": f"Context:\n{context}\n\nQuestion: {prompt}"}
                ],
                temperature=0.1,
            )
            return response.choices[0].message.content
        except RateLimitError:
            continue
        except Exception as e:
            log_error(model, e)
            continue

    raise AllModelsFailedError("All fallback models exhausted")

Four models. One query. The user never sees a rate limit error — they just get an answer.

The Bilingual Problem Is Harder Than It Sounds

Urdu-English code-switching is the natural register of educated Pakistanis. Nobody speaks pure Urdu in a legal context — you'd say "میرے landlord نے mujhe غیر قانونی طور پر lock out کر دیا" (My landlord has illegally locked me out) before you'd say any pure-Urdu equivalent that nobody actually uses.

LLMs handle Urdu worse than English. They handle Romanized Urdu (Urdu transliterated into Latin characters) even more inconsistently. They handle code-switched Urdu-English at unpredictable quality levels depending on which model you're using and whether the moon is in the right phase.

My solution was to stop fighting this. HAQ accepts input in any mixture of languages and scripts. The query preprocessing detects dominant language and script. The retrieval always runs against English-language legislation (because that's how Pakistani law is written). The response is generated in whatever language the user wrote in.

The UI renders RTL text for Urdu script. Mixing RTL and LTR in the same paragraph — when someone writes half in Urdu script and half in English — is a CSS situation I spent two days on. Unicode bidirectional algorithm, dir="auto", then eventually a per-paragraph language detection function that sets directionality at the paragraph level rather than the document level.

It's still not perfect. Code-switched sentences with English entity names embedded mid-Urdu are the hardest case. It's good enough that users don't notice unless they're looking.

Location, Location, Jurisdiction

Pakistan has four provinces, federally administered territories, and a capital territory — each with different legislative jurisdiction across different domains. Tenancy law is provincial. Labor law is partly federal, partly provincial (post-18th Amendment). Family law has its own court system entirely.

An answer about rent disputes in Lahore can be completely wrong for Karachi. And wrong answers here are worse than no answers.

HAQ asks for city on first launch and maps it to jurisdiction. The Pinecone query filters by jurisdiction metadata before ranking by semantic similarity:

def build_filter(jurisdiction: str) -> dict:
    return {
        "$or": [
            {"jurisdiction": {"$eq": "federal"}},
            {"jurisdiction": {"$eq": jurisdiction}},
        ]
    }

results = index.query(
    vector=query_embedding,
    filter=build_filter(user_jurisdiction),
    top_k=5,
    include_metadata=True
)

Federal law plus the user's provincial law. Five results, semantically ranked. That's what the model gets to work with.

This sounds like a small feature. It changes accuracy dramatically for anyone outside Islamabad.

Voice, OCR, and Legal Letters

Three features that don't sound like AI features but matter more than any of the ML decisions above, for the actual users I'm building for.

Voice input + TTS: If your legal question is "میرا کرایہ ختم ہو رہا ہے اور مالک مکان کیا کر سکتا ہے" and you're not comfortable typing on a phone — or you're not fully literate — you should be able to say it. Whisper handles transcription. pyttsx3 handles response playback. The full pipeline works voice-in, voice-out.

Document OCR: Someone receives a legal notice. It's a physical piece of paper or a photo on their phone. HAQ accepts the image, runs Tesseract OCR with the Urdu language pack, extracts the text, and adds it to query context. "What does this mean? What are my rights?" is a full HAQ query at that point.

Legal letter generation: If the answer is "yes, you have grounds to challenge this" — the next thing the user needs is a formal letter. HAQ generates one in the appropriate Pakistani legal format, citing the relevant sections, as a downloadable PDF or DOCX. Not a substitute for a lawyer reviewing it. But something concrete to start with, in the right format, with the right citations.

None of these are technically sophisticated. All of them are the difference between a demo and a tool that someone actually uses.

What HAQ Actually Is

Let me be precise about what this does and doesn't do.

HAQ does: help someone understand what Pakistani law says about their situation, with verifiable citations, in Urdu or English, on their phone, for free.

HAQ does not: replace a lawyer. It doesn't interpret law — it retrieves it. It doesn't advise on strategy. It doesn't predict court outcomes. Every response includes a clear disclaimer directing users toward qualified legal counsel for anything complex.

The goal was never to replace the legal system. It was to close the information gap between people and the system that already exists to serve them.

When someone in Sukkur can read what Section 8 of the Rent Restriction Ordinance actually says about their eviction notice — rather than relying on what someone told them someone else said the law might be — that's not a small thing. That's the difference between knowing your rights and not knowing them.

What's Still Broken

HAQ is live. HAQ is imperfect. Here's the honest list:

Gap	Status
Coverage	100+ Acts is substantial. It's not complete. A crawler for remaining provincial Acts is in progress.
Urdu retrieval	A dedicated Urdu sentence encoder would improve semantic search quality beyond what multilingual-e5 provides.
Conversation memory	History doesn't persist across sessions. Follow-up questions lose context. This matters.
Lawyer directory	The natural next step after "you have a case" is "here's someone in your city." That integration doesn't exist yet.

If you want to contribute — especially if you work in Pakistani law, Urdu NLP, or legal tech — the repository is open.
**

Try It
HAQ is live on Hugging Face Spaces — no installation, no API key, no setup.

🤗 Hugging Face → https://huggingface.co/spaces/Shahrukh350/Advocate-AI

Ask it about tenancy rights in Punjab. Ask what the Defamation Ordinance says about online speech. Ask in Urdu. Ask in English. Ask the way you actually talk. Watch what it retrieves, read the citations, click the source links, and see whether it holds up.

The full source — RAG pipeline, embedding scripts, system prompts, everything — is open under MIT:

GitHub → [HAQ repo] https://github.com/Shahrukh-aidev/Adovacate-AI

If you find gaps in legislation coverage, broken Urdu rendering, or a case where it hallucinated past its guardrails — open an issue. That's exactly the kind of feedback that makes this better. PRs welcome, especially from anyone working in Pakistani law, Urdu NLP, or legal tech accessibility.*

There are 220 million people in Pakistan. A significant number of them will interact with the legal system at some point in their lives without ever speaking to a lawyer.

That's not acceptable. And it's not unfixable.

Built by Shahrukh at Sukkur IBA University.

#ai #llm #showdev #opensource

#python #rag #legaltech #nlp #accessibility #pakistan #webdev #beginners #programming

What Happens When You Try to Build Eyes for Someone Who Can't See or Hear?

Shahrukh — Thu, 02 Jul 2026 13:38:52 +0000

The Problem That Wouldn't Leave Us Alone

There are 285 million people living with visual impairment worldwide. That's not a statistic we stumbled on in a paper. That's roughly the entire population of Pakistan — the country we live in — walking through the world with a tool designed in the 1800s as their primary navigation aid.

The white cane is genuinely brilliant engineering for what it does. But it has a fundamental physical constraint: it scans the ground. Obstacles at chest height, head height, or anywhere in the mid-air zone between? Invisible.

Guide dogs are extraordinary. They're also expensive to train, unavailable in most of the developing world, and not everyone can care for an animal.

We're four CS students at Sukkur IBA University. We don't have research grants or hardware labs. What we had was the question: what if a piece of clothing could give someone a spatial sense they were born without?

That question turned into IRIS — Interactive Responsive Inclusive System.

The Idea: Make the Jacket Feel

The core insight was deceptively simple.

Skin is an incredible input device. We use tactile sensation constantly — the gentle pressure of a doorframe, the change in floor texture, the warmth of sunlight from a window. We know from research on sensory substitution (shoutout to Paul Bach-y-Rita's work) that the brain is remarkably good at reinterpreting tactile input as spatial awareness, given enough meaningful signal.

So: what if we mapped space onto the body?

A vibration on your left shoulder = something approaching from the left. A strong buzz on your center chest = obstacle directly ahead, close. Light hum everywhere = clear path for meters.

Not just on/off. Proportional. The closer the obstacle, the more intense the vibration. The more off-center it is, the more precisely the corresponding motor responds.

That was the dream. Now we had to build it.

The Hardware: What Goes Inside a Jacket

Let's be honest with you — early conversations about this project involved a lot of very naive assumptions about how simple this would be.

The core hardware stack ended up being:

The sensing layer — Three HC-SR04 ultrasonic sensors mounted left, center, and right on the jacket. They pulse ultrasound and listen for the echo. Simple, cheap, battle-tested. Range up to 2 meters, which gives roughly a 1–2 second warning window at walking pace.

The brain — An ESP32 microcontroller runs the real-time loop: read sensors, run the math model, drive the motors. It's fast enough, it has built-in WiFi, and it's cheap enough that we didn't cry when we fried one (we fried one).

The feeling — Seven ERM (Eccentric Rotating Mass) vibration motors distributed across the jacket. Left, center, right for the ultrasonic zone. Plus three for the AI vision layer. Plus one dedicated "URGENT" motor for critical alerts.

The eyes — A Raspberry Pi 4 with a camera module runs in parallel, capturing frames every 3 seconds and sending them to Microsoft Azure Computer Vision. The Pi is the brains for the AI layer; the ESP32 handles the real-time haptics.

The first prototype looked like someone had attacked a jacket with a soldering iron and lost. By the third iteration it looked almost intentional.

The Night Everything Was Wrong: A Love Story With Motors

Here's something nobody tells you about haptic feedback projects: ERM vibration motors are little monsters.

We'd wire everything up, send a PWM signal, and... nothing. Motor just sat there. Or it would hum faintly — clearly receiving power — but not spin.

This is static friction. ERM motors need significantly more torque to start rotating than to keep rotating. If your target intensity is, say, PWM 80 out of 255, and the motor's breakaway torque requires PWM 120 to overcome — it just won't start.

We lost a full weekend to this. We thought we had bad motors. We thought our transistor circuit was wrong. We tried different resistor values, different supply voltages, different PWM frequencies.

The fix, when we finally found it, is almost embarrassingly simple:

Motor was OFF + new signal received?
  → Blast full 255 PWM for 50ms   (kick it over the static friction hump)
  → Then settle to target PWM     (proportional intensity)

A 50 millisecond kick-start. That's it. That's the fix for a weekend of misery.

If you're ever building a haptic system — save yourself the pain. Implement the kick-start from day one.

The Math That Made It Real

This is the part we're most proud of, and the part that took the longest to get right.

The naive approach to directional haptics is simple: if something is on the left, buzz the left motor. On the right, buzz the right. In the middle, buzz the center.

That works. But it produces jarring, binary feedback. On. Off. On. Off. For someone relying on this as a navigation sense, that's tiring and imprecise.

We wanted something that felt continuous. As an obstacle drifted from left to center, the motors should smoothly interpolate — the left motor fading down, the center motor rising up, like a balance needle swinging.

The solution came from thinking geometrically. Each motor has a fixed angular orientation θ in the jacket's coordinate plane:

Left motor → θ = π (facing 180°)
Center motor → θ = π/2 (facing forward)
Right motor → θ = 0° (facing right)

Then, given two distance readings — center distance and side distance — the PWM intensity for any motor at angle θ becomes:

                255 × side × center
PWM = 255 - ──────────────────────────────────────
             √( center² · cos²θ + side² · sin²θ )

Visually, think of an ellipse defined by the two distances. The motor's angle determines where on that ellipse we sample — giving it natural directional sensitivity. Close in the center? The ellipse is narrow and tall — the center motor maxes out, the side motors stay relatively calm. Close on the left? The ellipse stretches sideways — the left motor fires hard, center fires moderately, right barely registers.

We built an interactive 3D Desmos model to visualize this before we committed to the formula. Watching the motor intensities shift smoothly as we moved a virtual obstacle around the space was genuinely one of the best moments of the project.

Scenario	Left Motor	Center Motor	Right Motor
Everything 3m away	~127 (mild)	~127 (mild)	~127 (mild)
Left obstacle at 0.3m	~245 (strong)	~145 (moderate)	~10 (barely)
Center obstacle at 0.3m	~145 (moderate)	~245 (strong)	~145 (moderate)
Everything at 0.2m	255 (max)	255 (max)	255 (max)

This is what made IRIS feel like a sense rather than a burglar alarm.

The AI Layer: Teaching the Jacket to See

The ultrasonic sensors are fast and reliable, but they have no concept of what they're detecting. A wall and a child both return the same echo.

For that, we added an Azure Computer Vision pipeline running on the Raspberry Pi.

Every 3 seconds, the Pi camera captures a 1280×720 JPEG. That image goes to Azure's dual API — one call for scene description ("a person standing near a flight of stairs"), one for object detection with bounding boxes.

Anything below 50% confidence gets discarded. The rest gets classified.

The frame is divided into three horizontal zones (left / center / right), and each detected object's bounding box center determines which motor zone fires. Object size in the frame estimates physical distance — a bounding box covering more than 25% of the frame means it's very close, triggering maximum intensity plus the dedicated URGENT motor.

Some objects earn special treatment:

URGENT_OBSTACLES = ["car", "truck", "person", "stairs",
                    "hole", "wall", "pole", "dog", ...]

If any of these appear close or center, the jacket interrupts whatever it's doing and fires the urgent motor while the Pi speaks a voice alert via espeak. The voice can describe the full scene — "stairs ahead" — something no ultrasonic sensor could ever tell you.

The Communication Problem Nobody Warned Us About

Two devices. One jacket. They need to talk to each other over WiFi.

Our first instinct was MQTT — it's the standard IoT messaging protocol, it's reliable, it has guaranteed delivery. We spent time setting up a broker, testing it, latency testing it.

Then we noticed something uncomfortable: ~50ms latency between the Pi sending a command and the ESP32 firing a motor. For haptics, that's a lifetime. The user's body is expecting a response now — delayed feedback teaches the nervous system the wrong thing.

We switched to raw UDP sockets. The command format is as minimal as we could make it:

"V,{motor_index},{intensity},{duration_ms}"

Examples:
  "V,3,255,500"  →  AI-Left motor, full power, 500ms
  "V,1,100,200"  →  Center motor, gentle pulse, 200ms
  "STOP"         →  Kill all motors immediately

Latency dropped to ~1ms. Yes, UDP is "fire and forget" — if a packet drops, the motor misses one pulse. But for haptic feedback, that's fine. A missed vibration is imperceptible. A late vibration is actively wrong.

We also scrapped hardcoded IP addresses (which would break on any new network) and had the ESP32 advertise itself via mDNS as esp32.local. The Pi finds it automatically on startup. Plug in anywhere, it just works.

Submitting to Microsoft Imagine Cup

We submitted IRIS to Microsoft Imagine Cup 2026 in the Accessibility category.

Writing the submission forced us to articulate something we'd been feeling but not quite saying: this project isn't about the technology. The ESP32, the Azure API, the trigonometric model — those are just means. The thing we actually built is a small reduction in the margin between what sighted people take for granted and what everyone else has to work around.

285 million people. The cane has been the primary tool for most of them for over a century. We're four students from Sukkur, Pakistan writing a few hundred lines of C++ and Python and we built something that works today, with components anyone can order, that gives directional spatial awareness no cane has ever given.

That's not nothing.

Try It, Break It, Improve It

Everything is open source under MIT — hardware, firmware, Python scripts, the math model.

GitHub → IRIS-Jacket

The full architecture, pin mappings, circuit diagrams, setup instructions — it's all there. If you build a version, change the motor layout, swap Azure for a different vision API, add a GSM module so it works offline — we want to know. Open a PR. File an issue. Send a message.

There are 285 million people in the world this could matter to.

That's a lot of reasons to keep building.

Built by Shaikh Muhammad, Shahzeb, Khizar, and Shahrukh at Sukkur IBA University.

This post was written with AI assistance for structure and language.
All technical decisions, debugging, and math are our own.

#showdev #iot #accessibility #opensource

#raspberrypi #esp32 #python #cpp #computervision #hardware #azure #webdev #beginners #ai #programming