Building a Citizen-Powered Government Accountability Platform — Hackc…
Build a platform where a complaint against an official can't quietly vanish: it moves up the chain on time, and the citizen can find free legal help.
- Track: Social Impact
Problem Statement 6: Building a Citizen-Powered Government Accountability Platform
Track: Social Impact
Domain: Civic Technology, Government Accountability, Access to Justice
The Challenge
Citizens may face situations where government officials misuse their authority, demand unofficial payments, behave inappropriately, neglect their duties, or refuse to provide public services. Many citizens do not know where to report such incidents, how to pursue a complaint when authorities fail to act, or how to access legal assistance when the system does not provide a resolution.
A complaint may be acknowledged but never resolved, passed between departments, or closed without a satisfactory explanation. For people with limited financial resources, pursuing the matter through formal legal channels can be especially difficult.
Your challenge is to build a transparent, citizen-first government accountability platform that enables people to report alleged misconduct, preserves an auditable record of complaints, automatically escalates unresolved cases through the appropriate authority hierarchy, and helps citizens access legal remedies regardless of their financial situation.
The central principle is simple: a complaint supported by evidence should not be allowed to disappear without a trace, and an unresolved case should not be silently buried.
What Could You Build?
1. Evidence-Backed Citizen Complaints
Allow citizens to report alleged misconduct by officials across government departments, including police, municipal services, public hospitals, education, and other public services.
Accept videos, audio recordings, photographs, documents, and written descriptions.
Use AI to transcribe recordings, extract relevant details, and prepare a structured incident report.
Allow complainants to review and correct AI-generated reports before submission.
Generate a unique complaint ID and preserve the submission timestamp, evidence references, status history, and actions taken.
Support citizens who cannot provide recordings through a separate written complaint process with appropriate verification.
2. A Permanent, Auditable Complaint Record
Once a complaint is formally submitted, its history should not be silently erased or rewritten by an official or administrator.
Maintain a tamper-evident record of the original complaint, submitted evidence, status changes, transfers, decisions, and reasons for closure.
Keep a public record of the complaint's progress where disclosure is lawful and safe.
If a complaint is withdrawn, rejected, corrected, or closed, retain an auditable entry explaining what happened rather than erasing its history.
Provide a documented review and appeal process when a complainant disputes a decision.
Protect sensitive evidence, personal details, witness identities, and information that could expose complainants to retaliation.
Where a complaint or record must be restricted or removed from public view for privacy, safety, court orders, or other lawful reasons, preserve the appropriate audit trail and record the reason for the restriction. Public transparency should not require publishing sensitive personal information.
3. Automatic Escalation Through the Authority Hierarchy
Build a complaint-routing system that follows the relevant administrative structure, from the responsible local office through district and state authorities to the highest competent oversight authority, where applicable.
Automatically assign complaints to the appropriate department and jurisdiction.
Track acknowledgement, review, response, and resolution deadlines.
Escalate cases when the responsible authority fails to act within the applicable timeframe.
Continue escalating unresolved cases through successive competent authorities rather than allowing the complaint to remain indefinitely at one level.
Record every transfer, acknowledgement, response, decision, and escalation.
Notify complainants when their case moves to another authority and explain the next steps.
If the highest competent authority does not resolve the matter, guide the citizen towards appropriate independent oversight bodies or legal remedies.
The system should distinguish between an authority failing to respond and a case being actively investigated. Escalation must follow the relevant legal and administrative procedures rather than automatically treating silence as proof of misconduct.
4. AI-Assisted Verification and Misuse Prevention
Use AI to help organise complaints and identify potential abuse without allowing an automated system to determine guilt.
Analyse submitted recordings and documents to produce transcripts, timelines, and incident summaries.
Flag duplicate complaints, manipulated evidence, missing information, and suspicious coordinated submissions.
Identify relevant inconsistencies for human review without treating them as conclusive proof.
Maintain a clear distinction between allegations, pending investigations, and findings established through an appropriate process.
Allow officials to submit responses and challenge inaccurate records without permitting them to erase the original complaint history.
Provide an appeal mechanism for complaints that are rejected or closed.
A complaint supported by evidence should receive appropriate review, but AI analysis alone must not establish that an allegation is true. Complaints without recordings should also have a fair route to review.
5. Transparent Government Accountability Profiles
Create profiles for participating officials and departments that show relevant public-service information and documented accountability records.
Possible information includes:
Department, designation, jurisdiction, and official grievance channels.
Number of complaints received and their current statuses.
Response and resolution timelines.
Outcomes of completed investigations.
Officially documented findings and disciplinary actions, where disclosure is permitted.
Repeated patterns in verified findings, with appropriate context.
Keep complaint volume separate from verified misconduct. Do not automatically lower an official's score because someone filed an allegation.
An accountability indicator could reflect documented responsiveness, compliance with applicable service standards, and substantiated findings. Its methodology should be transparent, auditable, and open to correction.
6. Legal Guidance When Authorities Fail to Act
If a complaint remains unresolved after the applicable escalation process, help citizens understand what they can do next.
Explain possible legal procedures and complaint mechanisms relevant to the type of incident.
Identify appropriate oversight bodies, grievance authorities, and other available remedies.
Generate an organised case summary with a timeline, complaint references, evidence inventory, and previous responses that the citizen can share with a lawyer.
Provide checklists of documents and steps that may be required.
Explain procedural options in accessible language, without presenting general information as personalised legal advice.
The platform should guide users towards legitimate legal remedies rather than promising a particular legal outcome.
7. Affordable and Free Legal Assistance
A citizen's ability to pursue justice should not depend entirely on their ability to pay.
Help users find lawyers by location, legal specialisation, language, and consultation format.
Identify eligible government legal aid services, Legal Services Authorities, and other verified free or low-cost assistance.
Help eligible users understand how to apply for free legal aid and what documents may be needed.
Offer options for remote consultations where available.
Allow users to prepare and organise their case before meeting a lawyer.
Clearly distinguish verified legal aid, free consultations, and paid legal services.
The platform should prioritise relevant free legal aid options for users who cannot afford representation, rather than simply directing them to paid lawyers.
8. Citizen Dashboard and Case Tracking
Give each complainant a secure dashboard showing:
Complaint ID and submission date.
Current authority responsible for the case.
Complaint status and action history.
Upcoming deadlines and escalation dates.
Requests for additional information or evidence.
Previous decisions and reasons for closure.
Available appeal routes and legal assistance options.
Citizens should be able to follow their case without repeatedly visiting government offices or relying on informal contacts.
Expected Outcome
Build a working prototype demonstrating the complete journey: reporting alleged misconduct, submitting evidence, generating an AI-assisted case summary, preserving an auditable complaint history, escalating unresolved cases, tracking official responses, and finding appropriate legal assistance.
Teams may simulate government departments, authority hierarchies, escalation deadlines, and legal-aid directories. Live integration with government systems is not required.
The prototype should demonstrate that a complaint cannot be silently erased, that unresolved cases have a traceable escalation path, and that citizens can discover meaningful next steps even when the administrative process fails to provide a resolution.
Evaluation Criteria
Solutions will be evaluated on:
Accountability: Does the system preserve complaint history and make actions traceable?
Escalation: Can unresolved complaints move through the appropriate authority hierarchy?
Evidence Handling: Does AI organise evidence accurately without claiming to prove guilt?
Fairness and Anti-Misuse: Does the platform protect against malicious reporting while preserving fair review?
Transparency and Privacy: Does it balance public accountability with complainant and witness safety?
Access to Justice: Can users find relevant legal procedures and affordable or free legal assistance?
Accessibility: Can citizens with different levels of digital literacy use the platform?
Technical Execution and Impact: Does the prototype demonstrate a practical, credible improvement in government accountability?
Build it with AI
- Build 1 · The whole prototype: Build a working web app prototype for a hackathon. Build the whole thing, not a plan: every screen below should work when I open it. OUR CHOICES (change these, or leave them as they are) - App name: Jawabdehi - Main user: Sunita, 45, a vegetable seller in Jaipur. She was asked for money "to speed things up" when renewing her vending licence at the municipal office. She reads Hindi, uses a basic Android phone, and can't afford a lawyer. - Part we go deepest on: making sure her complaint keeps moving, and that she finds free legal help if it stalls THE PROBLEM Complaints against officials get acknowledged and then disappear: passed between offices, closed without a reason, or left unanswered. Citizens don't know where to complain, what to do when nobody acts, or how to get legal help they can afford. The app records a complaint with its evidence in a history nobody can quietly rewrite, sends it to the right office, moves it up the chain when deadlines pass, keeps the complainant safe, and shows them the legal routes and free legal aid available when the system doesn't answer. It does not connect to any government system. Every official, office, complai…
- Build 2 · Finish what's missing: Go through the app you built and check it against this list. For each item, say whether it is done, partly done or missing. Then build everything that is partly done or missing, one item at a time, and keep everything that already works exactly as it is. - Fairness: "complaint/allegation" until a finding; AI only flags; the escalation wording that says nothing about truth; made-up names only - Privacy: identity hidden from officials and the public, redactions approved by the reviewer, evidence never public, witnesses hidden, 112 on every page - Append-only events of every type, no delete or edit for any role, a SHA-256 hash chain, evidence fingerprints, "Verify this record" - AI through a server endpoint with the key kept out of the frontend, plus prepared demo results with no key - Sample chains with deadlines, escalation on missed deadlines, the investigation pause that needs regular updates, the demo date - 15 sample complaints covering every listed stage, including the coordinated cluster - Report (one question per screen, voice, in-browser recording), AI draft with a source for every field and "not stated", the complainant's corrections kept -…
- Add-on · Real accounts and a real database: Move the app from the browser's storage to a real backend, so different people on different phones use the same records. - Use [Supabase / Firebase / Node + PostgreSQL]: - Events go in an append-only table: the database itself must refuse UPDATE and DELETE on it, through permissions or a trigger, not just the app. - Evidence goes in private file storage, opened only through short-lived signed links. - Real sign-in for every role (phone OTP for citizens, email for officials, reviewers and admin), with each role able to read only what the role rules allow. Test it by trying to read a complainant's name while signed in as an official. - Work out the hash chain on the server, and keep checking it in the browser with "Verify this record". - A scheduled job every hour checks deadlines and escalates, writing events with "system" as the actor. - Rate-limit new complaints per account and per phone number, and keep the coordination flag working across accounts. - Tell me how to run it, how to seed the sample data, and how to put it online.
- Add-on · Publish the record's fingerprint: Make it possible to prove that not even the people running the platform rewrote the history. - Once a day, work out one fingerprint of the whole record: the latest hash of every complaint's chain, combined into one SHA-256. - Publish it somewhere we can't change afterwards: a public "Daily fingerprints" page, and also [a commit to a public GitHub repository / an OpenTimestamps proof]. - Add "Check against a published fingerprint" to the public record: it recomputes that day's fingerprint from the data and says whether it matches. - Explain in plain words on the page what this proves and what it doesn't. - Then show me the Tamper test failing this check too.
- Add-on · Another language: Add [Tamil] to the app as a third language. - Translate every string in src/i18n, the categories, the timeline event names, the legal routes, the legal aid check and the case summary. Use simple, respectful everyday words, and keep official names (RTI, FIR, Lokayukta, DLSA, BNSS) as they are, each with a plain explanation. - Make the AI draft and the transcription work in that language, and keep the complainant's own words in their language in the record. - Show each language's name in its own script in the language picker, and make sure longer words don't break any layout at 360px wide. - Make Read aloud use a voice for that language if the browser has one, and hide it for that language if it doesn't.
- Submit · README, link and demo: Get this ready to submit to the hackathon. 1. Write a README.md covering: - the problem in two lines, and who the app is for - what it does, one line per screen - how the record can't be rewritten (events, hash chain, evidence fingerprints, verify) - how escalation works, and how it tells silence apart from an investigation in progress - how AI is used, and why it never decides - how complainants and witnesses are protected - how misuse is handled - how the accountability indicator is worked out - the legal routes with their sources - how free legal aid comes first - how to run it, what is simulated, and what we'd build next 2. Tell me step by step how to put it online on Vercel or Netlify from a GitHub repo, so the judges can open a link. Include the setting that stops a page refresh from showing a 404, and where to add the AI key. 3. Write a 3-minute demo script for judges who score accountability, escalation, evidence handling, fairness and anti-misuse, transparency and privacy, access to justice, accessibility, and technical execution and impact. Show: - Sunita reporting by voice in Hindi, and correcting the AI draft - the office missing its dea…
- Debug · An error message: I'm getting this error: [paste the full error message from the terminal or the browser console] It happens when: [what you did, e.g. submitted a complaint, pressed Verify this record, ran npm run dev] The file it points to: [paste the file, or the part the error names] Explain in two lines what is causing it. Then fix only that: give me the corrected code for each file that changes, with its file name, and don't change anything unrelated. Tell me how to check it's fixed.
- Debug · Blank white screen: The app shows a blank white screen. The browser console (right-click the page, Inspect, Console) shows: [paste any red text, or write "nothing"] The terminal shows: [paste it] What I changed last: [describe it] Find the cause step by step: the console error first, then the entry files (main.jsx and App.jsx), the routes, any import that might be wrong, and stored events or evidence that no longer match what the code expects (and make Reset demo clear them). Fix the cause, not the symptom. Also add a simple error screen, so a crash in one screen shows a message instead of a blank page.
- Debug · Verify this record is wrong: "Verify this record" is wrong: [e.g. it fails on data nobody touched / it passes after the Tamper test / it blames the wrong entry]. Check these one by one: - Each event is hashed as canonical JSON, with keys in a fixed order and no fields added after hashing (such as a display label). - Each hash includes the previous event's hash; the first event uses a fixed starting value. - Verification recomputes from the first event, in stored order, and reports the first entry that doesn't match. - Evidence fingerprints are SHA-256 of the file's bytes (an ArrayBuffer), not of its name or a data URL. - Dates are stored as ISO strings, so they come back the same after a reload. - Nothing anywhere edits an event in place. Then show me a table: the untouched record, a changed event, a changed evidence file and a removed event, with expected and actual results.
- Debug · Escalation goes wrong: Escalation goes wrong: [e.g. a complaint escalates while an investigation is in progress with updates on time / it never leaves the first office / it skips a level / the citizen isn't told]. Check these one by one: - Deadlines are counted in whole IST days from the right event, and read from config.js. - Each level escalates once, to the next level in authorities.js. - "Investigation in progress" pauses escalation only while updates arrive within the update period, and a missed update resumes it with an event saying why. - A bribe demand also goes to the Anti-Corruption Bureau in parallel, without stopping the main chain. - At the top of the chain, the complaint shows next steps instead of looping. - Every move writes an event and a notification with the "says nothing about whether the complaint is true" wording. Use the Demo date to walk one complaint through every level, and show me the timeline as a table.
- Debug · The AI draft is wrong: The AI draft is wrong: [e.g. it added a detail that isn't in the recording / it names the official as guilty / it guessed a date / the transcript is in the wrong language]. Fix the server prompt so that: - Every field cites its source: a quote with a timestamp, or a document and page. - Anything not in the evidence is "not stated", never a guess. - It uses "alleged" and "complaint", never says anyone is guilty, and draws no conclusions. - It keeps the complainant's own language. Then check the AI's answer on the server: reject any field without a source and mark it "not stated". Make sure the complainant's corrections are saved next to the AI's version, not over it. Run the three sample evidence files again and show me each field with its source.
- Debug · Something private is showing: Something private is visible to the wrong person: [e.g. the official can see the complainant's phone number / a witness name shows on the public page / evidence opens from a public link]. Find every place data is shaped for a screen, and make one function per role (citizen, official, reviewer, public, admin) that decides which fields that role gets. Every screen must go through it, not hide fields with CSS or by not rendering them. Make the official's view use the reviewer-approved redacted summary only. Then switch to each role and list every field visible on every screen, as a table, so I can check nothing leaks.
- Debug · It broke after my last change: Everything worked until my last change. Now [what's broken]. The change I made, or asked you to make: [describe it or paste it] Compare the code before and after that change and find what broke. Fix it so the new change and everything that worked before both work. If the change can't work without breaking something, tell me and suggest another way to do it.
- Debug · The AI keeps going in circles: Stop. We've tried to fix this several times and it still isn't fixed. Don't write any more code yet. The problem: [describe it] 1. List what we've already tried, and why each attempt didn't work. 2. List three possible root causes, most likely first, and what would confirm each one. 3. Tell me exactly what to check or log (one console.log, or one thing to look at) to find out which it is. Once I tell you the result, make one focused fix.
- Debug · Broken on a phone: The app looks broken on a phone: [describe it, e.g. the timeline runs off the side of the screen]. Fix the layout so every screen works at 360px wide and at the largest text size in Settings: - nothing scrolls sideways, and no text is cut off - the timeline and tables become stacked cards - buttons are at least 48px tall and don't overlap - long Hindi words wrap - recording and uploading evidence works with one hand Check every screen, not only the one I named, and tell me which ones you changed.
- Debug · Broken after deploying: The app works on my laptop but not after deploying to [Vercel / Netlify / GitHub Pages]. What happens: [e.g. a blank page, a 404 when I refresh a complaint page, the AI draft doesn't work] The build log or browser console shows: [paste it] Check the usual causes one by one: - the build command and output folder - the base path - a rewrite so every route serves index.html - file names whose capital letters differ from their imports (my laptop may ignore case, but the server doesn't) - the AI key and other environment variables added to the host - whether the app calls the live /api endpoint instead of localhost - upload size limits on the host for evidence files Tell me exactly which settings to change and where.