From Leak Report to Repair Evidence: Engineering BOOND with AWS Serverless
A water-leak report is only the beginning. Discover how I built BOOND with AWS Lambda, API Gateway, DynamoDB, S3, and Cedar-based authorization to explore a more traceable workflow for municipal leak triage and repair verification.
From Leak Report to Repair Evidence: Engineering BOOND with AWS Serverless
A water leak can be reported in seconds. Turning that report into a prioritized, documented, and reviewable repair workflow is a much harder engineering problem.
The system needs to connect incident information, location, prioritization, backend processing, evidence storage, and authorization. A dashboard alone cannot do that. The workflow behind it matters just as much as the interface.
That challenge inspired BOOND, an AWS-powered municipal water-leak triage and repair-verification prototype I built to explore how serverless architecture can connect reporting with accountable follow-up.
The central design question was:
How can a lightweight cloud application organize leak reports while keeping sensitive actions controlled and repair evidence separate from ordinary ticket data?
Here is how I approached the problem, the AWS architecture behind it, and the engineering lessons I learned.
1. Start With the Workflow, Not the Dashboard
BOOND is organized around a simple lifecycle:
Report → Locate → Prioritize → Review → Document
A report enters the system as a ticket. The interface presents ticket information and geographic context, allowing reviewers to inspect incidents and use the available prioritization logic to decide which cases may need attention.
The workflow also includes engineer-oriented ticket closure, an after-repair photo requirement, and a dispute path for cases that need additional review.
Each part addresses a different operational need:
- A map helps communicate where reports are located.
- A ticket queue makes the workload easier to review.
- Prioritization helps structure attention rather than relying on an unorganized list.
- Photo evidence supports a documented closure process.
- Disputes provide a path for challenging a closure or requesting further review.
These features do not independently establish that a leak has been permanently fixed. They create a more structured process for recording and reviewing the work.
That distinction influenced the architecture: ticket data, uploaded evidence, and authorization-sensitive actions have different responsibilities and should not be treated as one undifferentiated operation.
2. The Architecture: Six Responsibilities, One Workflow
BOOND uses a serverless architecture built around managed AWS services.
Amazon API Gateway: The application boundary
API Gateway exposes HTTP endpoints consumed by the frontend. The application uses routes for ticket retrieval, report submission, photo-upload preparation, ticket closure, and disputes.
Keeping these operations behind an API creates a clear boundary between the browser and backend processing.
AWS Lambda: Request processing
The backend uses Python running in Lambda. Instead of maintaining a continuously running application server, the project uses functions to process incoming requests.
This separation also makes the backend easier to test independently from the user interface.
Amazon DynamoDB: Ticket records
DynamoDB stores ticket records and workflow information. Ticket-oriented access patterns fit the prototype's need to retrieve and update incident records.
The database is responsible for structured application data, not for storing large image files directly.
Amazon S3: Evidence and frontend assets
S3 stores photographs and repair evidence. A separate bucket hosts the frontend assets.
Separating frontend hosting from evidence storage provides a clearer starting point for access-control design: public application files and sensitive uploaded files should not share the same exposure assumptions.
AWS CloudFormation and AWS SAM: Infrastructure and deployment
CloudFormation and SAM support infrastructure definition, packaging, and deployment. Infrastructure as code makes the deployment process easier to reproduce and review than a collection of undocumented manual changes.
Cedar-based authorization: Sensitive operations
BOOND integrates Cedar-based authorization into sensitive ticket operations. The intended design is to make authorization part of the backend workflow, rather than treating a hidden frontend button as a security control.
Together, these components separate the user experience, API boundary, request processing, structured data, file storage, and authorization responsibilities.
3. Engineering Challenge: Uploading Evidence Without Browser Credentials
One important design decision concerns photographs.
A naive implementation might expose AWS credentials in frontend JavaScript so the browser can upload directly to S3. That would create an unnecessary credential-exposure risk.
BOOND instead uses a backend-requested presigned S3 URL for its photo-upload workflow.
The intended sequence is:
- An engineer selects an after-repair photograph.
- The frontend requests an upload URL from the backend.
- The backend prepares a temporary S3 upload URL.
- The browser uploads the image using that URL.
- The closure request references the uploaded evidence and proceeds through the backend workflow.
This approach allows the browser to perform a specific upload without receiving permanent AWS credentials.
However, a presigned URL is not a complete security boundary. A production implementation should validate the requested ticket, constrain object keys, apply appropriate expiry, enforce file-size and content-type limits, and prevent evidence from being associated with the wrong incident.
The backend must also treat the closure request as a separate sensitive operation. Uploading a photograph should not, by itself, authorize a ticket to be marked resolved.
That separation is one of the most important principles in this workflow: file upload and ticket closure are related operations, but they are not the same permission.
4. Authorization: Protect the Operation, Not Just the Button
A frontend can hide a control, but a user may still attempt to call its API directly.
That is why authorization must be enforced at the backend boundary.
BOOND integrates Cedar-based authorization into sensitive operations and is designed to associate engineer-authorized closure with after-repair photo evidence. A dispute workflow provides another route for cases that require review.
The production implications are significant:
- Authentication must establish who is making a request.
- Authorization must determine whether that identity can perform the requested action.
- Evidence validation must establish that the required file reference is present and acceptable.
- Workflow validation must ensure that the requested state transition is permitted.
These are related but distinct checks.
The current prototype's demo PIN should not be mistaken for production-grade identity management. A real deployment would need a suitable identity provider, secure session handling, role management, auditable decisions, and carefully tested policies.
Similarly, a photograph can support a repair record, but it cannot independently prove that a leak has stopped. Accountability requires a process for reviewing evidence and handling disputed outcomes.
5. Deployment Reality: Passing Tests Is Not the Same as Proving Everything Works
Cloud projects involve more than implementing functions. The frontend, API routes, Lambda handlers, DynamoDB records, S3 permissions, and authorization policies must work together.
During BOOND development, deployment restrictions affected some S3 hosting and CloudFront-related operations. This reinforced a practical lesson about AWS IAM: the permissions available to a deployment identity determine which infrastructure operations it can actually perform.
Least privilege is essential, but deployment plans also need to account for permissions boundaries and the precise resources involved.
The verification performed for this prototype included:
- 30 passing backend tests.
- Successful JavaScript syntax checks.
- Successful direct HTTP checks for deployed frontend resources and the tickets API.
These checks provide useful evidence, but their scope matters. They do not establish that every browser workflow passed end to end.
A successful live ticket closure was not included in final verification because it would modify a production record. I therefore distinguish the checks that passed from the full workflow that remains to be verified.
For a next-stage release, I would run the entire reporting, upload, authorization, closure, and dispute lifecycle against non-production data, including both successful and denied operations.
That is a more meaningful test of the system than checking whether the homepage loads.
6. Environmental Technology Needs Measurable Outcomes
The motivation for BOOND is environmental, but an environmental objective should not be confused with a measured result.
A map, a ticket queue, and a closure workflow may help organize maintenance activity. They do not automatically prove that water consumption or leakage has decreased.
The demonstration includes simulated incidents and illustrative visuals. These are intended to explain the product experience, not to represent verified citizen reports or actual repair evidence.
To evaluate BOOND in a real municipal environment, I would establish a baseline with an operating maintenance team and measure:
- Time from report submission to review.
- Time from report to verified repair.
- Percentage of closures with usable supporting evidence.
- Repeat incidents at previously reported locations.
- Estimated water saved, calculated using a validated methodology.
Only after collecting suitable operational data could the project make defensible claims about improvements in response time or water conservation.
This is an important design principle for environmental software: build a workflow that can support measurement before claiming impact that has not been demonstrated.
7. What I Would Improve Next
The next development stage would focus on four priorities.
Production identity and access management
Replace prototype authentication with a production-ready identity provider and clearly defined roles. Test authorization policies for both allowed and denied operations.
End-to-end integration testing
Verify report submission, photo upload, evidence association, closure, and disputes in a controlled environment using non-production records.
Operational observability
Introduce structured logging, monitoring, and actionable alarms for API failures, upload errors, and authorization denials. This would make failures easier to diagnose.
Validated environmental impact
Work with municipal maintenance teams to validate prioritization rules, define service-level measures, and assess whether the workflow improves response times or repair accountability.
These improvements would help move BOOND from a prototype toward a system that can be evaluated responsibly in a real operational setting.
Conclusion: Building for Traceability
BOOND began with a practical engineering question: how can a water-leak report become a structured and reviewable maintenance workflow?
Building the prototype gave me hands-on experience with API Gateway, Lambda, DynamoDB, S3 presigned uploads, CloudFormation, AWS SAM, Cedar-based authorization, and automated testing. It also reinforced that a cloud architecture is more than a list of services. Its quality depends on how clearly responsibilities are separated, how sensitive operations are protected, and how carefully behavior is verified.
The most important takeaway is that reporting, prioritization, evidence collection, and authorization should be designed as connected but distinct parts of a workflow.
BOOND's goal is to help turn scattered water-leak reports into structured prioritization and documented repair processes—while remaining transparent about what the prototype has and has not demonstrated.
Project Links & Resources
Explore BOOND and its implementation through the following links:
- GitHub Repository: https://github.com/Ajayrathod04/BOOND
- Live Application Demo: https://boond-frontend-351458007747.s3.ap-south-1.amazonaws.com/index.html
- AWS API Endpoint: https://698gkx4o9a.execute-api.ap-south-1.amazonaws.com/tickets
- AWS CloudFormation Console: https://ap-south-1.console.aws.amazon.com/cloudformation/home?region=ap-south-1#/stacks
- AWS Builder Center: https://builder.aws.com/
- Hackathon — Environmental Hacks: https://www.wemakedevs.org/aws/env
BOOND demonstrates how serverless cloud architecture can connect incident reporting, map-based prioritization, evidence handling, and authorization into a more structured water-leak maintenance workflow.
Every Drop Matters. Better Workflows. More Accountable Water Management.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article