TROUT FUTURE MAP

Keep the spot secret. Make the river visible.

Comment

Inspiration

Anglers spend time on rivers that researchers cannot continuously monitor. They notice fish, water conditions, and environmental change, but their photographs and field notes are often inconsistent and difficult to reuse for research.

Publishing an exact fishing spot can also expose fragile habitats, rare fish, and places that communities have good reason to protect.

TROUT FUTURE MAP began with one principle:

Keep the spot secret. Make the river visible.

The core citizen-science concept existed before OpenAI Build Week, including the idea of connecting anglers, researchers, fisheries cooperatives, and public institutions.

During Build Week, we built and meaningfully extended that concept into a working software product: an end-to-end observation workflow, a controlled GPT-5.6 integration, human review, browser-local persistence, privacy transformations, a public aggregate map, a research demo, CSV/JSON exports, and automated privacy tests.

What it does

TROUT FUTURE MAP turns a responsible angler observation into a research-ready candidate record without publishing the exact fishing location.

The Golden Path is:

  1. Load a synthetic fish photograph and observation note.
  2. Add optional observer-reported information such as a sample kit ID.
  3. Structure explicitly stated facts into research fields.
  4. Review source excerpts, confidence, missing information, and photo usability.
  5. Edit the candidate and explicitly approve it.
  6. Submit the synthetic record.
  7. Watch a Privacy Collapse explain the protected-private-to-public boundary.
  8. View a watershed-level signal on the Public Map.
  9. Open the same Record ID in the Research Demo.
  10. Export the browser-local record as CSV or JSON.

The public deployment runs in explicit Demo Mode. Demo records are synthetic, and submitted demo records are stored only in the current browser through IndexedDB.

Public Demo Mode uses a deterministic, visibly labelled fixture. It does not call OpenAI and is never presented as Live GPT-5.6 output.

The Public Map is schematic and uses synthetic watershed regions. It never renders an individual fishing pin. Regions with fewer than three eligible records are suppressed using a prototype k ≥ 3 publication rule, and published counts are shown as bands rather than individual events.

Every structured result remains a candidate waiting for human and researcher review. The deployed app does not perform or claim DNA or genetic classification. A sample kit ID is only an observer-reported reference; it is not a DNA result.

How we built it

We built the application with Next.js, React, TypeScript, Zod, native IndexedDB and Canvas APIs, the OpenAI JavaScript SDK, the server-side OpenAI Responses API integration path, and Vercel.

The experience has four primary surfaces:

  • / — documentary-style project introduction
  • /record — three-step observation, structuring, and human-review workflow
  • /map — Privacy Collapse and aggregate-only Public Map
  • /research/demo — synthetic research-candidate dashboard and exports

The public judging flow does not require an account, API key, production database, or cloud storage.

Submitted synthetic records are written to an allowlisted IndexedDB schema. They persist across navigation and reloads in that browser profile but are not shared with another browser, device, user, Vercel instance, or research institution.

The browser derives a separate public aggregate from those records. Public output excludes exact coordinates, observer identifiers, sample kit IDs, original notes, and image URLs.

Images are re-encoded in the browser to remove source metadata, reduced to a maximum long edge of approximately 1,600 pixels, and checked against a processed-size limit below 3 MB. In public Demo Mode, the processed image and observation note are not sent to the structuring API.

The Research Demo reads consented synthetic records from the same browser and generates CSV and JSON downloads client-side.

We added focused tests for structured-output validation, prompt-injection boundaries, human approval, IndexedDB persistence, public-data allowlisting, k ≥ 3 suppression, image processing, Vercel filesystem boundaries, CSV safety, exports, reset behavior, and prohibited genetic-classification fields.

How GPT-5.6 and Codex were used

GPT-5.6 has a deliberately narrow role in the controlled Live pathway.

It is instructed to:

  • structure only facts explicitly stated by the observer;
  • leave unknown information as null or unknown;
  • identify ambiguity and ask at most three missing-information questions;
  • assess whether a photograph is usable as documentation;
  • produce cautious public and researcher summaries;
  • preserve provenance and uncertainty.

It is prohibited from inferring a fishing location or generating claims about native, wild, stocked, hybrid, pure-lineage, DNA, genetic traits, or scientifically confirmed species status.

Its output is not saved automatically. The observer can edit every candidate field and must explicitly approve the record before submission.

GPT-5.6 Live Mode was validated once during development using synthetic data and the server-side OpenAI Responses API. The request returned HTTP 200 with model gpt-5.6. It structured only explicitly stated facts and generated one question about missing river-condition information.

That controlled validation excluded exact GPS coordinates, used a metadata-removed image, set store: false, and saved no observation record.

The public deployment keeps Live Mode disabled to prevent API-key exposure and uncontrolled API usage. No OpenAI API key is configured for the public demo.

Codex was used throughout Build Week as a product engineering and QA collaborator. It helped with product-flow design, UI implementation, GPT-5.6 schema and prompt boundaries, privacy architecture, automated tests, accessibility and responsive QA, browser walkthroughs, secret auditing, documentation, GitHub preparation, and Vercel deployment.

The pre-existing TROUT FUTURE MAP concept is not presented as Codex-created or Build Week-created work. The working software implementation and its meaningful extensions are the Build Week contribution.

Privacy by design

Privacy is implemented as product behavior rather than only described in a policy.

  • The public deployment runs in explicit Demo Mode.
  • Every public-demo record and watershed is synthetic.
  • Submitted demo records are stored only in the current browser through IndexedDB.
  • The public demo does not request real browser geolocation.
  • No real fishing GPS locations are uploaded, sent to GPT-5.6, stored in browser records, or published.
  • Browser-added records have no latitude, longitude, exact-location, observer-ID, or user-ID field.
  • Public output is aggregated by a synthetic watershed region.
  • Regions below k ≥ 3 are suppressed.
  • Public counts are displayed as bands.
  • Public output excludes Record IDs, observer identifiers, sample kit IDs, original notes, detailed timestamps, and image URLs.
  • Images are re-encoded to remove source metadata.
  • Human approval is required before a record is saved.
  • Live GPT-5.6 is disabled in the public deployment.
  • No OpenAI API key is exposed to the browser or configured for the public demo.

The Privacy Collapse is a conceptual explanation of the intended data boundary. In the public browser demo, the safest implementation goes further: exact coordinates are never collected or stored.

The Research Demo contains more detail than the Public Map, but it still uses synthetic browser-local data. It is not an authenticated researcher portal, a shared cloud database, or an operational research system.

We do not claim encryption, formal k-anonymity, scientific validation, or production-grade anonymity that has not been implemented.

Challenges we ran into

The first challenge was preserving scientific usefulness without creating a tool that reveals sensitive fishing locations. Adding random jitter would still expose an individual-location pattern, so we built a separate aggregate data model with coarse synthetic regions, count bands, and low-count suppression.

The second challenge was making AI assistance useful without presenting model output as scientific fact. We constrained the prompt and schema, rejected prohibited fields, represented uncertainty explicitly, and required human approval.

The third challenge was creating a reliable public demonstration without exposing an API key or adding a production database. Explicit Demo Mode and browser-local IndexedDB persistence let judges complete the entire flow, reload the application, and export records without a paid API request or shared backend.

We also had to distinguish the separately validated Live GPT-5.6 pathway from the deterministic public fixture. The interface clearly labels which mode is active and never silently substitutes Demo output after a Live failure.

Finally, browser image processing, responsive field use, accessible focus states, reduced-motion behavior, secure exports, serverless deployment boundaries, and state continuity across multiple views required extensive QA beyond a visual prototype.

Accomplishments that we're proud of

We are proud that TROUT FUTURE MAP is a working and testable product rather than only a concept page.

  • The Golden Path works from observation entry through CSV/JSON export.
  • One Record ID follows the synthetic observation across the Public Map and Research Demo.
  • Submitted records survive navigation and reloads in the same browser.
  • Every structured candidate remains editable and requires explicit approval.
  • Demo Mode is visibly distinct from the separately validated Live GPT-5.6 pathway.
  • The Privacy Collapse makes an otherwise invisible data decision understandable.
  • Public-data allowlisting and k ≥ 3 suppression are enforced in code and tests.
  • Exact GPS is absent from the public-demo storage schema.
  • CSV and JSON exports contain an intentional research-demo field set.
  • Reset removes only browser-added records and preserves built-in synthetic seeds.
  • The deployed experience works without an API key, production database, or real location upload.

What we learned

We learned that trustworthy AI products depend as much on boundaries and interface language as on model capability.

Labels such as “Demo-structured,” “AI-structured,” “Observer-reported,” and “Waiting for researcher review” help users understand what the system knows, what a person supplied, and what still requires expert judgment.

We also learned that privacy transformations should be visible. Showing the movement from protected private handling to an aggregated signal communicates the product’s values more clearly than a privacy-policy paragraph alone.

Browser-local storage can be useful for an honest, isolated hackathon demonstration, but it is not a substitute for authenticated durable infrastructure.

Most importantly, AI should not replace scientific verification. Its strongest role here is reducing the formatting burden on observers while preserving uncertainty for researchers.

What's next for Trout Future Map

The current release is a browser-local hackathon demonstration, not a production research database.

A future production version would require:

  • authenticated observers and researchers;
  • role-based access control;
  • durable and appropriately encrypted storage;
  • consent, withdrawal, retention, and deletion workflows;
  • auditability and institutional governance;
  • rate limiting, moderation, and abuse prevention;
  • reviewed GIS aggregation and temporal-release policies;
  • field pilots with anglers, fisheries cooperatives, researchers, and public institutions;
  • privacy, ethics, and security review before accepting real observations.

Real watershed GIS, cross-device synchronization, laboratory integration, and production researcher workflows are not implemented in this submission.

DNA analysis would remain outside GPT-5.6. If approved research institutions later return laboratory results, those externally verified results could be linked to authorized sample records with clear provenance and access controls.

We would also explore offline-first field capture, multilingual research schemas, controlled follow-up workflows, and carefully governed Live GPT-5.6 assistance—while preserving the principle that a useful river-level signal should never require publishing someone’s exact fishing spot.

Built With

Share this project:

Updates