Ask Siargao

Ask Siargao is a chat-first travel decision system for accommodation, itinerary, immediate-plan, surf-session, and disruption questions. It turns request-time evidence into a bounded keep, change, avoid, or needs-confirmation recommendation.

Siargao travel advice changes with weather, tides, surf conditions, place status, transport, and a traveler's real constraints. A generic answer can sound decisive while relying on stale evidence, hiding missing checks, or overstating what the product can verify.

I designed and implemented the product, Next.js application, agent runtime, governed evidence tools, Reality Check contract, provider and cache boundaries, traveler privacy model, Trip Pass lifecycle, deployment path, and verification harness.

• A Next.js App Router API accepts an explicit chat submission and delegates it to a Responses-compatible agent runtime. The model chooses typed tools and writes the answer; deterministic code validates request shape, access, source labels, evidence references, and public artifact selection.
• Governed tools combine Open-Meteo weather, marine, and tide data; Google Places identity and place evidence; public-web research; and repository-backed local knowledge. PostgreSQL stores durable facts and traveler-owned artifacts, while Redis supports shared operational controls such as rate limiting.
• A structured final payload identifies the tool calls and artifacts used. The server validates source sufficiency, creates the public decision summary and source list, and persists only sanitized traveler-visible history without raw provider payloads or exact browser coordinates.

bun run verify
bun run verify:foundation

• The model owns tool choice, synthesis, and final wording; the backend owns provider access, source governance, privacy, and evidence validation.
• Reality Checks run only after explicit message submission and finish inside that request, keeping the evidence timestamp, cost, result, and failure state observable together.
• The model references completed evidence calls, but the server derives public sources and decision IDs so a generated answer cannot declare its own evidence trustworthy.

• Different questions require different evidence contracts: surf decisions need current marine or tide data and a condition judgment, while named stays need successful place-identity evidence.
• Provider success is partial and time-sensitive, so the runtime must preserve useful checked evidence, expose meaningful gaps, and prevent failed or stale sources from supporting a decisive claim.
• Anonymous chat, signed-in history, saved plans, sharing, browser location, payments, and account closure need distinct ownership and retention boundaries without leaking private tool arguments into public artifacts.

• The synchronous, on-demand workflow gives one evidence-backed answer at a time; it does not monitor conditions, contact operators, book activities, or guarantee future availability.
• Typed tool contracts, source policies, caches, and artifact allowlists add backend complexity, but make answer provenance and degraded states reviewable.
• When required evidence is unavailable, needs confirmation is deliberately less satisfying than a confident recommendation but more accurate than inventing a checked result.

The public repository is actively maintained and the Vercel deployment returned HTTP 200 on August 14, 2026. The live product exposes the landing page, chat workspace, Reality Checks, traveler settings, saved-trip sharing, and a free-to-paid Trip Pass allowance; no tagged release is published.

• Live Ask Siargao product
• Public GitHub repository
• Product and local-run overview

• Reality Check contract reference
• Chat routing and source-governance explanation
• On-demand Reality Check lifecycle

August 14, 2026