A Photo, a Policy, and a Water Warning: How We Built JalNet with AWS Cedar
How we built JalNet, an Android water-intelligence prototype that transforms citizen observations into route warnings while protecting private photo evidence with AWS open-source Cedar authorization.
A Photo, a Policy, and a Water Warning: How We Built JalNet with AWS Cedar
What if reporting a flooded road could help someone else avoid it?
Imagine you're heading to college when you encounter a waterlogged road. You take a photograph, perhaps send it to a WhatsApp group, and continue on your way.
But what happens to that information?
Someone travelling along the same road may never see your message. Another person might see it hours later, when the conditions have changed.
That's the problem we wanted to explore with JalNet, a map-first Android water-intelligence prototype developed for Environmental Hacks — Heat & Water.
Our goal was simple:
Turn citizen water observations into useful, location-aware warnings while keeping the original photographic evidence private.
JalNet's light-mode Android map. This is an actual emulator screenshot with synthetic LOCAL/DEMO incident and route data.
1. From a photograph to an incident
We designed JalNet around a practical citizen workflow:
- Choose a location on the map.
- Capture a photograph using the Android camera.
- Save the image as a private draft.
- Upload the evidence to the local backend.
- Review and classify the observation.
- Explicitly confirm the report.
- See the resulting incident and any affected saved route.
The application is built using React Native, Expo, TypeScript and MapLibre.
The reporting workflow uses a separate local Node.js API. It validates photographs and stores private evidence before the citizen confirms what they observed.
One important decision was to never treat a single report as independently verified.
A newly confirmed citizen report can produce an incident marked UNVERIFIED. Its age and expiry matter because an observation is not a permanent guarantee of current conditions.
The actual report-review interface. This screenshot shows manual classification with synthetic emulator evidence. No vision model ran for this capture.
Our current local prototype uses manual classification. We've designed an interface for image-analysis providers, including an unverified future AWS Nova integration, but we don't claim live AI image recognition in this demonstrated workflow.
The final publishing decision belongs to the human.
2. Turning observations into route warnings
Simply collecting reports wasn't enough.
We wanted JalNet to connect reports to decisions.
The local backend includes incident processing, freshness tracking, conservative fusion and geometric intersection checks against saved-route corridors.
When a reported incident intersects a saved corridor, the app can display a warning.
An actual Android emulator result after a staged report was confirmed. The warning uses a synthetic straight-line demo route, not real road-network navigation.
There are important limitations.
Our current local routes are straight-line demo corridors, not calculated turn-by-turn road routes. An absence of reports doesn't establish that a road is safe.
The aim is to communicate available observations and their uncertainty, not promise something the data can't establish.
3. Why protecting evidence became a security problem
One of the most interesting engineering questions emerged while designing private photo uploads.
Who should be allowed to read or modify a citizen's original report?
Photos may reveal people, vehicle numbers, buildings or other personal information.
We separated private evidence from public incident information.
The public map can show an appropriately limited incident summary, but the original photograph is not automatically made public.
However, hiding a photograph from the UI isn't enough. The backend must enforce the restriction.
This is where we integrated AWS Cedar.
4. Implementing real authorization with Cedar
Cedar is an open-source authorization policy language and engine released by AWS.
Instead of relying only on scattered ownership checks, JalNet uses the real Cedar 4.13.0 WebAssembly engine in its local Node.js backend.
We protect four private-report actions:
- ReadReport
- PresignReport
- CompleteUpload
- ConfirmReport
The essential rule in our Cedar policy is:
resource.owner == principal In other words, the authenticated user must match the actual persisted owner of the report.
The server derives both values from trusted sources; it does not accept the claimed report owner from the mobile interface.
The original ownership comparison also remains as defense in depth.
What happens if access is denied?
Returning HTTP 403 is only part of the requirement.
Our tests verify that a denied operation does not:
- Issue an unauthorized upload grant.
- Read another user's private evidence.
- Mutate a report.
- Initiate analysis.
- Publish an incident.
- Award droplets.
We also exercise a separate test-only forbid policy, showing how a forbid overrides an otherwise permitted owner.
The production permit policy remains unchanged.
JalNet includes 40 actual-engine Cedar authorization tests. Its public repository also provides an isolated HTTP demonstration that executes real decisions rather than relying only on mocked authorization results.
The lesson: security is not just about denying access. It's about ensuring denied operations have no unauthorized effects.
You can inspect the actual policy here:
5. Building trust through confirmation and rewards
We introduced a contribution system called Droplets to recognize eligible citizen participation.
The ledger is designed around idempotency, meaning a retried request must not create duplicate rewards.
Our local prototype awards provisional points for eligible actions, while stronger claims about usefulness require supporting evidence.
The local Android ledger after a staged confirmed report, showing a provisional +2 contribution. This does not represent verified environmental impact.
We deliberately avoid displaying invented metrics such as the number of people saved or the amount of water conserved.
Trust depends as much on what a product refuses to claim as on what it can calculate.
6. My Water: making household estimates understandable
While building the incident-reporting system, we also explored a household water-planning feature.
We called it My Water.
Users can enter their estimated tank capacity, current water level and approximate daily consumption.
Consider this example:
Input | Value |
|---|---|
Tank capacity | 1,500 litres |
Current level | 60% |
Daily consumption | 300 litres/day |
Calculated remaining water | 900 litres |
Estimated depletion | 72 hours |
When the user presses Simulate one day, the application deducts one hypothetical day's consumption.
That produces 600 litres remaining, 40% tank level and approximately 48 hours of estimated supply.
My Water calculating 900 litres remaining from the local demo fixture. The result comes from executable calculations, not a connected sensor.
The calculator has validation, local persistence and explicit simulation behavior.
It does not use a physical water meter or IoT sensor. Its depletion estimate assumes constant consumption and no refill.
We believe this kind of honest, interactive calculation can be valuable even before sensor integration exists.
7. Water Stress: why transparency matters
Another prototype feature is the Water Stress DEMO indicator.
It combines six fictional, editable pressure factors using explicitly defined weights.
The implementation handles missing inputs and adjusts the weights of available factors. When available input coverage falls below the configured minimum, it suppresses the headline score.
The calculated Water Stress DEMO indicator. The inputs are fictional, not official or live environmental measurements.
The point of this feature isn't to claim a validated scientific water-stress index.
It demonstrates how an explainable indicator could present calculations, inputs, weights and uncertainty together.
8. Our technology stack
JalNet combines mobile, backend, geospatial and authorization components.
Area | Technology |
|---|---|
Android app | React Native, Expo, TypeScript |
Maps | MapLibre and OpenFreeMap assets |
Local persistence | SQLite and local backend files |
API | Node.js |
Validation | Zod |
Authorization | AWS-origin Cedar 4.13.0 |
Testing | Vitest, HTTP tests, Android emulator |
Infrastructure definitions | AWS CDK |
The current working local architecture follows this general flow:
Android camera → private upload → Cedar-protected operations → human review → incident processing → route warning and contribution ledger.
The codebase also preserves implementations for a possible future AWS deployment involving Cognito, API Gateway, Lambda, DynamoDB, S3, SQS, Bedrock Nova and Amazon Location.
Those services are not currently verified as deployed.
Our Build It approach uses the actual open-source Cedar engine running locally, rather than claiming a cloud deployment that hasn't been demonstrated.
9. Android design and real testing
We wanted JalNet to feel like a real Android application, not only a technical proof of concept.
The interface uses a map-first layout, Lucide icons and persistent System, Light and Dark appearance options.
During development, we tested reporting, route states, draft recovery, tank calculations, authorization and other behavior using automated tests and Android emulator sessions.
We also exercised an earlier staged camera-to-route-warning flow on a physical Redmi.
A separate signed ARM64 Android preview is available for testing the standalone features such as My Water, Water Stress, maps and appearance settings.
That preview intentionally excludes backend-dependent reporting and authorization operations rather than exposing our fixed-identity local development API to the public internet.
10. What we learned
Building JalNet taught us four particularly important lessons.
Authorization needs to be testable. Cedar makes ownership rules explicit and helps us demonstrate that denied operations have no unauthorized effects.
Environmental observations require uncertainty. A citizen report is not the same as a measured, independently verified condition.
A functioning prototype should be transparent. Local processing, synthetic routes, fictional indicators and unverified cloud services should be clearly distinguished.
Useful products connect information to decisions. The most important part of JalNet isn't the number of screens. It's the journey from an observation to information someone can act on cautiously.
11. What's next for JalNet?
Our roadmap includes genuine AI-assisted image interpretation, improved report verification, secure hosted infrastructure, road-network routing, verified environmental data and optional IoT measurements.
We're also exploring future features such as TankerOS and HeatSafe, but these remain previews or planned functionality rather than deployed services.
The immediate engineering priority is making the existing camera-to-incident experience reliable and ensuring every security and environmental claim remains verifiable.
Final thoughts
JalNet began with a simple idea:
A photograph of a water-related problem should help someone else make a better-informed decision.
That idea brought us into mobile development, geospatial geometry, state management, privacy engineering and authorization.
AWS Cedar became one of the most valuable parts of the experience because it allowed us to turn a simple ownership rule into an explicit, enforceable and testable policy.
There's still plenty to build, but we're proud of the working prototype and what we've learned.
Explore the project:
Developed for Environmental Hacks — Heat & Water. JalNet is a team project created with assistance from OpenAI Codex. The repository retains the relevant MIT, Cedar, Lucide and map-data license notices. All screenshots shown here are actual Android emulator captures using disclosed demo data.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article