Step 1: The Model Describes the Scene
We send the photo to Amazon Bedrock through the Converse API with a structured prompt. We ask it to estimate a depth range, identify reference objects such as a kerb, tyre, or person's legs, assess confidence and image quality, and flag hazards such as flowing water, open manholes, or exposed wires.
The model returns JSON that we validate and normalize before using it. This prevents malformed responses from entering the decision pipeline.
Step 2: Deterministic Rules Turn That into a Verdict
A dedicated Python module contains the vehicle-specific thresholds. For example, a petrol scooter is classified as GO below 10 cm, RISKY from 10 to 20 cm, and NO-GO from 20 cm onward. A bus has a different threshold, with GO below 40 cm.
Additional hazards can worsen the verdict by one level. Low confidence, poor image quality, flowing water, a strong current, or an open drain can make a crossing riskier. An exposed wire in the water triggers NO-GO for every vehicle.
These decisions are made by code that can be inspected, tested, and updated. The rules also have unit tests, making the decision process more transparent than relying on a model's free-form answer.
Step 3: Be Honest About Uncertainty
Estimating water depth from a single photograph is difficult because of perspective, reflections, and unknown road geometry. We therefore avoid presenting false precision.
- Lead with categories: Passable, Potentially Unsafe, Unsafe, or Requires Inspection.
- Round depth estimates: Display depth as a range rounded to 5 cm.
- Escalate uncertain cases: If confidence is low, the image is poor, there is no usable reference object, or the estimated range is too wide, show Requires Inspection.
- Never turn uncertainty into reassurance: A low-confidence estimate must not be presented as a confirmed safe crossing.
We also provide an evaluation script that reports mean absolute error and, most importantly, how often the system incorrectly classifies a crossing as GO when the ground truth is NO-GO for a scooter.
Step 4: Build a Fallback Instead of Failing Silently
Amazon Bedrock may be unavailable because of quotas, regional restrictions, or model availability changes. Our analysis flow handles these failures explicitly.
For blocked-drain photos, the system can fall back to Amazon Rekognition label detection and clearly mark the result as “AI analysis unavailable, needs review.” Rekognition labels are not treated as equivalent to a reliable water-depth estimate.
A drain is never automatically marked cleared without verification. If analysis gets stuck or fails, the user sees an error and a Retry option instead of an indefinite loading screen.
Step 5: Moderate Images Before Analysis
Before an uploaded image reaches the analysis model, Amazon Rekognition moderation checks whether it is safe to process. This adds a screening step before image analysis and helps prevent unsuitable uploads from entering the pipeline.
Key Takeaways
- Use models for perception and code for decisions. Keep safety-critical thresholds explicit and testable.
- Make uncertainty visible. “I don't know” should be a valid outcome when the available evidence is insufficient.
- Design the failure path first. During severe weather, users need clear guidance when a service is unavailable, not a broken or misleading result.
Loading article