PIRS — Public Infrastructure Reporting System
This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.
What I Built
PIRS (Public Infrastructure Reporting System) is a civic technology platform designed to help citizens report public infrastructure problems and understand what to do about them.
The idea started with a simple question:
What if reporting a pothole, water problem, sewer blockage, electricity fault, or broken traffic light could be easier and more informative?
Instead of simply submitting a complaint and forgetting about it, PIRS connects three parts of the experience:
REPORT → LOCATE → TRACK
A citizen can report an infrastructure problem, provide its location and supporting information, and then track the report.
I also wanted PIRS to go beyond being a reporting form.
The platform includes a Knowledge Center containing structured infrastructure information and an AI Assistant that uses that knowledge to help citizens understand infrastructure problems and reporting procedures.
The application currently covers infrastructure categories including:
- Electricity
- Water
- Sewer
- Roads
- Traffic Lights
- Illegal Dumping
- Fallen Trees
- Other
The goal was to create something that feels like a real civic technology product rather than just a form submission project.
Demo
Live application:
https://public-infrastructure-reporting-sys.vercel.app/
The application includes:
- Home
- Report Issue
- My Reports
- Knowledge Center
- AI Assistant
- Login and Registration
The AI Assistant can answer questions such as:
- How do I report a water problem?
- What information should I provide when reporting an electricity fault?
- Who should I contact about a damaged road?
- What should I do if I see a blocked sewer?
The answers are grounded in infrastructure knowledge stored in Sanity rather than being generated from an empty prompt.
Screenshots
Home
The landing page introduces the reporting workflow and makes the REPORT, LOCATE and TRACK concept central to the experience.
Report Issue
The reporting interface allows citizens to select an infrastructure category, describe the problem, provide a location and attach supporting information.
My Reports
Citizens can view the issues they have submitted and follow their current status.
Knowledge Center
The Knowledge Center presents structured infrastructure information organized by category.
AI Assistant
[INSERT AI ASSISTANT SCREENSHOT]
The AI Assistant uses the PIRS knowledge stored in Sanity to provide grounded infrastructure guidance.
Code
GitHub repository:
https://github.com/laytontozvireva-star/Public_Infrastructure_Reporting_System
The project is built as a React application with Tailwind CSS and Supabase, with Sanity powering the structured infrastructure knowledge layer.
My Build Process
This project was built iteratively rather than from a finished specification.
I started with the original PIRS concept: a platform where citizens could report infrastructure problems such as electricity faults, water problems, sewer blockages, potholes and broken traffic lights.
The first version focused primarily on the reporting experience.
As the project developed, I realized that reporting alone was not enough. A citizen might know that something is broken but still not know:
- Who is responsible?
- What information should be provided?
- What safety precautions should be taken?
- How should the problem actually be reported?
That led me to add a structured knowledge layer using Sanity.
Step 1 — Designing the reporting experience
The first goal was to make reporting simple.
I created the main reporting flow around:
Category → Description → Location → Photo → Submit
The application uses Supabase for authentication, database storage and report photos.
The infrastructure categories were also designed to match the types of public problems PIRS is intended to handle.
Step 2 — Introducing Sanity
I then created a Sanity project specifically for PIRS infrastructure knowledge.
Instead of storing everything as unstructured text, I created a structured infrastructureKnowledge document type.
The schema contains fields such as:
- Title
- Category
- Problem
- Safety guidance
- Reporting procedure
- Required information
- Responsible authority
- Location context
- Summary
- Source name
- Source
This became an important change in the architecture.
The knowledge was no longer just text displayed on a page. It became structured content that the application could query and use.
Step 3 — Collecting infrastructure knowledge
I started adding real infrastructure information from relevant Zimbabwean sources.
For example, the knowledge base contains information related to organizations and services such as ZINWA, ZESA and City of Harare services.
The source material was transformed into structured PIRS knowledge records rather than simply copied into frontend components.
This means the application can retrieve information by category and the AI layer can work with the structured fields.
Step 4 — Building the Knowledge Center
After the Sanity content was available, I built the Knowledge Center in the React application.
The frontend retrieves infrastructure knowledge from Sanity and presents it in a citizen-friendly interface.
This created a second major experience inside PIRS:
Report an issue → Learn about the issue
Step 5 — Adding the AI Assistant
The next step was connecting Gemini to the structured PIRS knowledge.
The AI assistant does not simply receive the user's question and generate an unrestricted answer.
The backend first retrieves the available infrastructure knowledge and identifies records that are relevant to the question.
Those records are then provided to Gemini with instructions to:
- Use only the supplied PIRS knowledge
- Avoid inventing authorities or procedures
- Avoid inventing contact information
- Prioritize safety
- Clearly state when the available knowledge is insufficient
- Preserve the supplied source information
This was important because infrastructure reporting can involve safety issues and incorrect contact information could make the system less useful.
Step 6 — Debugging real problems
The build was not completely smooth.
One of the biggest problems appeared when the Gemini API started returning HTTP 429 responses because the free-tier request quota had been reached.
Initially, the frontend displayed a generic connection error.
I traced the problem through the production logs and found that the actual backend response was a Gemini quota error.
I then changed the backend to return a clear 429 response when the quota is exceeded and changed the frontend to preserve and display the backend error message.
That turned a vague:
Unable to connect to the PIRS knowledge assistant.
into a useful message explaining that the AI service had reached its daily limit.
I also added retry handling for temporary Gemini service errors.
This was one of the most useful parts of the build because it showed me that getting an AI feature working is only one part of the problem. Handling failure states matters just as much.
What worked
The final architecture became:
Citizen
↓
React + Tailwind PIRS
↓
┌───────────────────────┐
│ │
│ Supabase │
│ Reports + Auth │
│ Photos │
│ │
└───────────────────────┘
+
┌───────────────────────┐
│ │
│ Sanity │
│ Infrastructure │
│ Knowledge │
│ │
└───────────────────────┘
↓
Relevant Knowledge
↓
Gemini
↓
PIRS AI Assistant
The combination of structured content and an AI interface made the Knowledge Center much more useful than a collection of static articles.
Sanity Project Details
Sanity Project ID: wenswj4d
Dataset: production
The main Sanity document type is:
infrastructureKnowledge
The schema was created specifically for PIRS and contains structured fields for infrastructure categories, safety guidance, reporting procedures, responsible authorities and source information.
Sanity is therefore not just being used as a generic CMS.
It acts as the structured knowledge layer behind the Knowledge Center and AI Assistant.
Technical Stack
Frontend
- React
- React Router
- Tailwind CSS
- React Markdown
- Lucide React
Backend / Data
- Supabase
- Sanity Content Lake
- GROQ
AI
- Google Gemini API
Deployment
- Vercel
Development
- VS Code
- Git
- GitHub
What I Learned
Building PIRS taught me several things about combining structured content with AI.
1. Structured content changes what an AI application can do
Instead of giving an AI model a completely open-ended prompt, I can provide it with a defined body of infrastructure knowledge.
That makes the application's behavior easier to control.
2. Schema design matters
The Sanity schema determines what information is available to the application.
Fields such as responsibleAuthority, safetyGuidance, reportingProcedure and requiredInformation give the AI and frontend meaningful structure to work with.
3. AI features need failure handling
The Gemini quota problem was a good reminder that an AI API can fail even when the application itself is working correctly.
The application therefore needs proper handling for:
- Rate limits
- Temporary service failures
- Missing API keys
- Missing knowledge
- Invalid questions
- Backend errors
4. The product should come before the AI
The AI Assistant became more useful after the underlying PIRS product and knowledge model were defined.
The AI is not the entire product.
It is one part of a larger civic reporting experience.
Why I Built PIRS
Infrastructure problems are often visible to citizens long before they are formally reported.
A fallen pole, leaking pipe, pothole, blocked sewer or broken traffic light can affect an entire community.
PIRS explores how software can make the process of reporting these problems more accessible while also helping citizens understand what information they need to provide.
The project started as a reporting system.
It evolved into a combination of:
Civic Reporting + Structured Knowledge + AI Assistance
That evolution is what made the project especially interesting to build.
Final Thoughts
PIRS started as a simple idea:
See a problem → Report it → Provide the location → Track it
While building it, the project became much larger.
Sanity gave the application a structured infrastructure knowledge layer, while Gemini provided a conversational interface over that knowledge.
The result is a civic technology platform that combines reporting, location, tracking, structured content and AI assistance in one experience.
This submission represents the actual build process, including the problems, debugging and architectural decisions that happened along the way.
Top comments (0)