Hazard Intelligence

Exploring AI-assisted enterprise workflows—where AI can reduce effort, where it should step back, and where human judgment still needs to lead.

Hazard Intelligence is a self-directed extension of the Hazard Reporting platform I originally designed in 2024.

The goal was not to automate the workflow end to end. It was to explore how AI could reduce manual effort in a high-stakes operational experience without creating false confidence or removing human judgment.

Why I Explored It

The original reporting flow required users to choose a hazard type before taking a photo.

That meant classification happened before the strongest piece of evidence was captured, and users could not change the hazard type later. Incorrect selections created downstream work for admins, who had to correct and reroute the report.

I wanted to explore whether reversing that sequence could reduce manual classification and move correction earlier in the workflow.

Revised Workflow

The revised flow adds more system intelligence while reducing upfront decision-making for the user.


Functional Prototype

I turned the revised workflow into a working mobile prototype so I could test the interaction beyond static screens.

The prototype supports photo-first hazard classification, browser camera capture, on-device image recognition, confidence-aware suggestions, and manual correction when the model is uncertain. Users can confirm or change the suggested hazard, verify location, edit report details, and complete a simulated end-to-end submission flow. Safety and emergency guardrails remain in place throughout the experience.

Launch Live Prototype ↗

Built with
React · TypeScript · Vite · MobileCLIP · Browser Camera and Geolocation APIs · Vercel

Prototyping The Interaction

I used Codex to move from static screens into a functional prototype and test the complete capture-to-result flow.

That surfaced issues I would not have caught in Figma alone. During camera testing, for example, the visible preview and the image being sent to the classifier were cropped differently, allowing background content outside the frame to influence the result. I updated the capture behavior so the model analyzed the same image the user saw.

Model Tradeoffs In The Prototype

I tested different image-recognition approaches to understand the tradeoff between model size, speed, and usefulness in a mobile workflow. The published prototype now uses a lighter on-device model that made classification noticeably faster while still producing useful hazard suggestions in early testing.

This was not a formal accuracy benchmark. The goal was to validate the interaction, understand where the model struggled, and identify where human confirmation still needed to remain part of the flow.

What I Learned From Testing

Mobile testing showed that where the hazard appeared within the camera frame affected classification quality. When the hazard was centered and visually prominent, results were more reliable. As it moved farther off-center, confidence and accuracy dropped.

I used that finding to improve the capture experience itself by adding lightweight camera guidance that prompts users to center the hazard within the frame before taking the photo.

Testing also reinforced the value of confidence-aware interaction design. High-confidence matches could stay streamlined with a single recommendation, while more ambiguous results could surface multiple plausible options for the user to confirm or correct.

Human Stays In Control

The model supports the decision, but the user still makes it. AI recommends; the user confirms, corrects, or changes the classification before submitting.

Manual fallback · Editable classification · Required location verification · No automatic submission

What Still Needs Testing

Before production, I’d validate performance across a broader image set, tune confidence thresholds, test false positives and negatives, confirm accessibility, and measure whether AI assistance actually reduces reporting effort.