Ground work

• 

• 

• 

• 

• 

Inspiration

What it does

Inspiration

I walked past a creek behind a library and saw plastic bottles and a shopping bag snagged on the rocks. The water was cloudy. Two birds were standing right next to the mess. I felt something about it, and then I kept walking, because I had an email to send and a call I had been avoiding.

That gap is the whole idea. Most people notice something wrong in the world around them and have nowhere to put it. The noticing is real, the care is real, and then it evaporates because the next step is unclear and the day is already full. Existing citizen science tools ask you to pick a project, create an account, learn a taxonomy and fill in a form. That is a lot of friction to put in front of a feeling that lasts about thirty seconds.

I wanted something that met the moment where it actually happens: outside, hands full, mildly upset, with no intention of filling in a form.

What it does

Groundwork listens to one messy spoken ramble and turns it into something you can act on.

You say everything in one go. The trash, the cloudy water, the birds, how it made you feel, and the two errands you are dreading. No forms, no categories, no account.

From that single input it produces three things:

1. A field dataset. Observations are separated from feelings and errands, then structured into records with evidence IDs, categories and confidence levels. Exportable as CSV, GeoJSON, a spreadsheet or a printable PDF.
2. A day plan that respects your state. Tasks become time blocks with real breaks and one clear next action. Amazon Comprehend reads the sentiment in the ramble, so an upset, low energy day gets a gentler schedule than a focused one.
3. An actionable workbook. A field summary that is honest about what is missing, five to seven safe citizen science missions, the named environmental problems your observations might relate to, and challenge briefs a developer could start on this weekend.

That last part is the piece I care most about. A bag in a creek becomes a 48 hour project brief with a problem statement, the data needed, team roles and a measurable success test, with every claim linked back to the observation that prompted it.

How we built it

A TypeScript monorepo with two halves.

The MCP server is the reusable core. It exposes seven tools over Streamable HTTP: parse_dump, log_observation, block_schedule, suggest_mission, match_problems, build_workbook and export_dataset. Because it is a standard MCP server rather than application specific glue, the same tools work with any MCP client, not just this web app.

The web app is Next.js with the App Router. It runs an MCP client, lets the model orchestrate tool calls, and renders the results live. The tool activity chips in the UI are not decoration; they are the real call log streaming as the pipeline runs.

AWS does two jobs. Amazon Comprehend reads sentiment and key phrases from the ramble, which is what lets the schedule adapt to how you felt rather than only to what you said. Amazon Polly reads the plan back, which matters for a tool designed to be used outdoors.

Grounding is enforced in code, not only in prompts. Named problems come from a fixed seed catalog and the model cannot invent new ones. Every claim about your data must cite an observation ID that actually exists, and a verification script fails the build if one does not. Every mission carries a safety note. Location is stored only as the words you spoke, never geocoded.

State lives in the browser. No account, no database, no server side storage of anything you said.

Challenges we ran into

The MCP spec moves fast. The track requires spec 2025-11-25 or later over Streamable HTTP, and the older stdio and SSE transports are everywhere in examples and older tutorials. Getting a verified Streamable HTTP handshake negotiating the right protocol version took real time, and I ended up writing a dedicated verification script that asserts the transport and negotiated version rather than trusting that it worked.

Honesty is harder than capability. The easy version of this product tells you your cloudy water means pollution. That version is wrong and would do actual harm. Visible litter is not a microplastic measurement and cloudy water is not a diagnosis. Building the grounding layer, including the "what this cannot tell us" section and the evidence ID enforcement, took longer than the feature work and was the right trade.

One visit is not a pattern. The workbook has to be useful without overclaiming from a single walk. The answer was to make the data gaps a first class section rather than hiding them, and to make the missions specifically target what is missing.

The clock. This was built inside a very compressed window. That forced a strict priority order, a hard rule that no single problem could block the build for more than fifteen minutes, and fallback paths at every external dependency so a failed API call could never take down the demo.

Accomplishments that we're proud of

The MCP server is a genuinely reusable asset rather than a hackathon prop. Seven tools, standard transport, works with any MCP client.

The sentiment to schedule link works and is not a gimmick. Reading how someone felt and planning a gentler day in response is a small thing that changes whether a tool gets used on a bad day.

The grounding layer holds. Claims are tied to evidence IDs, problems come from a fixed catalog, and the verification script fails the build if either rule is broken. The workbook will tell you what it cannot prove, which is rare in this category.

The handoff from noticing to building actually closes. A walk past a creek produces a challenge brief a developer could pick up, and that is the loop I most wanted to exist.

What we learned

Voice is not a text box you talk at. The win is not transcription, it is that speaking removes the structuring burden entirely. People will say six observations, four tasks and a worry in one breath and never fill in a form with the same content.

Tone is signal. Treating sentiment as scheduling input rather than as an analytics metric made the product feel considerate instead of mechanical.

Constraints in code beat instructions in prompts. Every grounding rule that lived only in a prompt drifted. The ones enforced by a verification script did not.

Fallbacks are a design requirement, not polish. Every external dependency got a fallback path, and building those first meant no single outage could sink the demo.

What's next for Groundwork

Real data, carefully. Optional, explicit, coarse location so observations can become genuinely useful to local groups, with the no guessing rule intact.

Repeat visits. Patterns are the point. Returning to the same footbridge over six weeks is what turns anecdotes into something worth a researcher's attention, so the next build is longitudinal tracking of the same place.

Shared datasets. Letting a neighborhood pool observations, with contributor consent, so a street of individual walks becomes one body of evidence.

The brief pipeline. The challenge briefs want somewhere to go. Connecting them to real builder communities and hackathons would close the loop fully, from one person noticing something to a team shipping something about it.

On device. The mission flow belongs on a phone, outdoors, offline, with a camera. That is where the noticing actually happens.

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Ground work

Built With

• amazon-web-services
• claude
• codex
• polly
• zod