Rerouted

Inspiration

This project started on the way to Cal Hacks. As a student, my flight from San Diego to San Francisco for the hackathon was canceled, and I had to rebook it myself.

It was a pain. I was trying to find a new flight on my phone while also figuring out what the airline would rebook for free, what I would have to pay for, whether I could still make it in time, and whether I was getting a fair price. Every option meant comparing times, prices and fare rules across different sites, and the good options were going fast while I was still deciding. On a student budget, I also did not want to overpay because I was panicking.

That is when we realized a canceled flight turns a traveler into a shopper under pressure, with no one on their side. We wanted to see what that moment looks like when an AI agent does the searching, ranking and explaining, while the traveler and their card stay in charge of the money: nothing is bought until you tap, and only at a price you saw and within limits you set.

What it does

When your flight is canceled, Rerouted:

1. Searches real flights home. Live Google Flights results through SerpApi, for tonight and tomorrow.
2. Ranks them against your deadline. Flights that land in time come first, then the cheaper ones.
3. Checks each one against your card's rules. A trip cap, an ask-before-buying limit and allowed categories (airlines and hotels). Anything over the cap is set aside with the reason.
4. Explains each option in one sentence. Written by Claude.
5. Waits for your one tap. The agent can never buy on its own. You approve an exact price, and if the airline changes the price before you tap, your old approval no longer works.
6. Leaves a receipt. Every purchase is recorded in a tamper-evident, hash-chained receipt. Rerouted also tracks the refund you are owed for the canceled ticket.

For the demo, "Another flight" cancels a random real flight on a random route between 16 major US airports, with a random arrive-by deadline. "New card limits" sets a random cap and ask-first limit, so judges can see the rules re-sort the options live.

How we built it

• SpacetimeDB is the backend. Every rule lives in a reducer, the only way to write data. Each reducer is one atomic transaction:
  • The agent and the traveler have separate identities.
  • approve_offer checks, in one transaction: who is calling, the option's tier, the quote hash, its expiry, the trip cap, one flight per trip, and the mock card token. Any failed check reverts everything.
  • Because roles are checked on the caller's identity inside the database, no client can bypass them.
  • The dashboard updates live through subscriptions.
• The rules engine is plain TypeScript. It sets each option's tier (auto, ask, block) and its rank, and it is unit tested. Claude can flag an option to raise its tier, but it can never lower one.
• Claude (claude-sonnet-5-5, one call per run, output validated with zod) writes a reason for each option and flags anything suspicious. Listing text is treated as untrusted input: it is wrapped in tags, and Claude is told to flag instructions inside it rather than follow them.
• Quote-bound approval. Each offer carries a SHA-256 hash of its ID, merchant, price and expiry. A price change produces a new hash, so an approval of the old price is refused.
• Privacy by design. The traveler's name, email, booking reference and card data live only in private tables. They never appear in public rows, agent steps, receipts or the text sent to Claude.
• Next.js server routes hold every secret and run the agent. The frontend is a dashboard with a 3D "deadline corridor" in three.js: every way home is an arc, and the deadline is a sign frame you either land in front of or past.
• A check script (demo-check) replays the whole flow against the live database with no UI. It confirms that the agent's own purchase is refused, a stale quote is refused, the cap holds, the receipt chain verifies, and no personal data is public.

Challenges we ran into

• Real data is messy. Flight search sandboxes returned flights that had already departed, so we filter out anything leaving within the next hour. Real fares also make the demo unpredictable: some runs have nothing over the cap, others have nothing that lands in time. We leaned into that with the random flight and random card buttons.
• Time zones. Departures are in the origin's time and arrivals in the destination's. Our first version assumed every trip was West Coast to New York. Random routes broke that, and we had to put every time on the destination's clock.
• Search budget. On a free plan of 250 searches, every search counts. A shuffle runs one live search and the cancel that follows reuses it, so a full run costs two searches.
• Being honest about what is simulated. We wanted real flights, but buying real tickets during a hackathon was off the table. The search is real, the rules are enforced for real, and the booking is a recorded mock with every check applied. The app says so.

Accomplishments that we're proud of

• The agent tries to buy a flight on its own, and the database refuses it live: "Refused: the agent cannot approve its own purchase."
• A price change voids the old approval, so you only ever pay a price you saw.
• Every flight and fare on screen is real, and so is every rule check.
• The whole flow, from cancellation to ranked real options, takes a few seconds.

What we learned

• Where an AI agent helps: searching, comparing and explaining are where it adds the most. The decision to spend money should stay a human tap with rules that are enforced, not suggested.
• Rules in the database: putting the rules in the database rather than the UI made the trust story simple. Even our own server code cannot approve a purchase as the agent.
• Untrusted text: text from a third-party listing has to be treated as input to check, never as instructions to follow.

What's next for Rerouted

• Real cancellations: detect them from a flight-status feed instead of a demo button.
• The airline's free rebooking: check it first, before spending anything.
• Hotels: search them for overnight delays.
• Accounts: real traveler sign-in.
• Real payments: card-network rules, such as a real spending control on the card, instead of our mock token.
• A second check before ticketing: before any real ticket is issued, confirm the fare and seat once more.

Built With

• 3jss
• anthropic
• claude
• next.js
• node.js
• react
• serpapi
• spacetimedb
• typescript
• vitest
• zod