Case Study · Product Design · AI Builders Challenge with IBM Bob · 2026

Sky to Porch

Making public hazard data easier to understand

IBM watsonx Granite · 16 Public Data Sources · Output Checks · Next.js · Live Product

Live app GitHub repo Watch the demo
Sky to Porch banner: the tagline Space data, plain English above six colored hazard chips and the satellite-over-house logo
Problem
Public observations about heat, smoke, and other hazards are spread across agency websites, in the form scientists use. A parent asking whether it was dangerously hot at practice yesterday finds raw data products and technical terminology, or a chatbot that answers confidently without any data behind it.
Process
I defined the product scope and UX direction, then coordinated development and review across four AI tools. The app retrieves and checks public observations before using IBM watsonx Granite to explain the findings in plain English.
Result
Sky to Porch brings 16 public data sources into one interface covering six hazard categories. Visitors can explore a location or a real event, view the available observations, and read a plain-English explanation with links to its sources. They can investigate local hazards without retrieving scientific datasets or setting up API access themselves.
6Hazard categories at launch
16Public data sources at launch
1,780Automated tests at launch
55Recorded architecture decisions

DownlinkThe Demo

Video demo

The three-minute demo follows a query from event selection through to the explanation and its sources.

Explore the live app.

35,786 kmProject Context

Why I started this project

After Hurricane Beryl, many people in Houston had damaged homes and needed evidence of what had happened at their address for an insurance claim. The observations existed, but there was no clear way for them to find or use them. I wanted people to be able to look up a storm, a heat event, or a smoke day without learning GIS software or setting up API access.

The explanation also needed to stay within what the observations supported. A confident answer could give a misleading impression of conditions at a particular home or street. This shaped how the application processes evidence and how much detail its answers can claim.

705 kmUsing the App

Starting a query and reading the result

Sky to Porch covers fire, flooding, heat, drought, air quality, and volcanic activity. Visitors choose a location and a hazard, then select what they are concerned about. The available concerns include home, health, pets, travel, power, and community.

They can also start with one of six examples based on real events. These include Hurricane Beryl in Houston and the 2023 smoke episode in New York. Selecting an example fills in the location, hazard, and dates.

The result combines a map with a written explanation. Source links let visitors check the underlying information, and a badge identifies the AI model used to write the answer.

Queries take about 10–20 seconds. Progress labels show what the app is doing while visitors wait.

Sky to Porch landing page in dark theme: six real-event story cards beside an interactive map and the insight panel
Six real-event examples provide a starting point beside the map and insight panel.
The insight panel mid-query, showing the staged evidence pipeline: checking coverage, fetching observations, validating evidence, writing the answer
The panel shows the current processing stage while observations are retrieved and checked.
Hurricane Beryl query over Houston: NASA IMERG rain imagery on the map, and a Granite-written answer noting rain was observed but no flood extent was detected
NASA IMERG imagery shows rainfall during Hurricane Beryl. The answer distinguishes that observation from the absence of a detected flood extent in the available evidence.
Sky to Porch on a phone-sized screen: the story cards stacked in a single column above the Ask, Map, and Insight tab bar
Ask, Map, and Insight appear as bottom tabs on smaller screens.

400 kmAI Collaboration

My role and AI collaboration

This project was built in collaboration with AI; the design decisions, content, and direction are mine. The code was written by the four tools below; the decisions about what to build and what counted as finished were mine.

The four tools had different responsibilities:

  1. 01

    ChatGPT

    Helped explore the problem, research the concept, and define the initial scope.

  2. 02

    IBM Bob

    Served as the primary development tool. Its work included the dataset registry, six evidence adapters, interpretation logic, AI routing, output checks, query flow, map, and automated tests.

  3. 03

    Codex

    Supported code review and prompt writing, carried out part of the verification work, and helped check completion of the 14 work packages.

  4. 04

    Claude Code

    Handled the final project review and polish, strengthened protections around paid AI endpoints, and completed the production deployment on Vercel.

I set the six-hazard scope and evidence rules, directed the interaction flow and visuals, and selected the demo stories.

Throughout development, I reviewed and accepted each merged pull request, managed credentials and spending controls, and prepared the contest submission. Every architecture decision was recorded, ADR-0001 through ADR-0055, so the reasoning behind the build can be checked in the repository.

100 kmEvidence

How the answers are produced

The pipeline separates interpreting the observations from writing the explanation.

The process has four stages.

Stage 1

Retrieve observations

NASA · NOAA · USGS · EPA · server-side

The server requests satellite imagery and ground-station records for the selected area and dates. Each source has a coverage profile that the application can check. Timeouts and responses that exceed size limits are reported as retrieval failures.

Stage 2

Validate and interpret

TypeScript

The application checks the observations and applies predefined rules. For example, a station’s peak heat index can be mapped to a National Weather Service severity category. With the same evidence and rules, this stage produces the same conclusion.

Stage 3

Generate the explanation

IBM watsonx · ibm/granite-4-h-small

IBM watsonx Granite, using ibm/granite-4-h-small, receives the structured conclusions and writes the response. A labeled OpenAI fallback is available when the primary provider is unavailable.

Stage 4

Check the generated text

Output checks

Output checks look for unsupported numbers, invented links, and claims that exceed the evidence. Rejected passages are replaced with text produced directly from the application’s rules, and the reason is logged.

The provider fallback and the rule-based fallback serve different purposes.

Switching providers helps keep AI explanations available during an outage.

The rule-based response allows the application to answer without generated prose when an output is rejected or a paid AI call cannot proceed.

Showing the scope of the evidence

Source labels

Satellite products and ground stations provide different kinds of information. Their geographic coverage and level of detail vary, so I kept them clearly labeled in the interface.

Analysis radius

The analysis radius remains visible. Answers describe the area represented by the observations, without treating a station reading or satellite pixel as a measurement of conditions inside a particular building.

Observations and conclusions

The application also distinguishes an observation from the conclusion drawn from it. For example, a mapped smoke plume provides information about smoke coverage. It does not establish an individual person’s exposure. Similarly, a missing observation cannot establish that an area is free of danger.

Coverage status

Coverage status is shown explicitly. At launch, Canadian and Mexican sources were registered but marked as prepared rather than active. If a source fails, the interface reports the failure and shows the evidence that remains available.

10 mAccess Controls

Controlling access to paid AI calls

Before launch, a review of all 12 API routes found an unprotected endpoint that could trigger paid AI calls. That endpoint was removed. Rate limiting was then moved from individual server instances to shared storage in Upstash Redis.

The resulting controls included:

  • Limits for short bursts, sustained use, and daily requests, along with a daily spending limit across all users.
  • Rate-limit identifiers stored as HMAC digests with expiration times. The keys do not contain raw IP addresses or message content.
  • Origin checks that reject requests from unapproved website origins.
  • A rule that blocks paid AI calls when Redis is unavailable and uses a rule-based answer instead.

The first production deployment went live before the AI environment variables had been configured. The app still displayed the retrieved evidence, reported that AI was not configured, and made no paid AI calls.

0 mLaunch

Launch and next steps

Sky to Porch was deployed on Vercel before the challenge deadline. The project included 1,780 automated tests, with browser checks during the production rollout.

During a production demo, output checks rejected a Granite response. The app supplied a rule-based answer and completed the query, showing the fallback in use beyond the automated tests.

The next steps identified at launch were to expand coverage beyond the United States and add support for Spanish and Traditional Chinese.

Explore Sky to Porch

Try the live app, watch the demo, or read the code.

Live app GitHub repo Video demo