Fictional family-visit plan: five simulated services share state, with explicit costs and lifecycle status.
Fee changed after approval: Ripple re-quotes the $75 cancellation and requires a fresh decision.
The complete plan and supported fact editor, with browser-local persistence and an explicit simulated clock.

Inspiration

One changed flight can leave a whole visit out of sync. The calendar moves, but groceries are already dispatched, dinner is booked for the wrong night, and the pickup reminder still fires on Friday. A useful agentic assistant should understand those dependencies, explain the consequences, and ask before a costly change.

Ripple explores that experience through a clearly labelled Alexa+ simulation: change one fact, repair what depends on it, and leave unrelated commitments alone.

What it does

Ripple coordinates a fictional three-day family visit across five simulated services: calendar, grocery delivery, restaurant reservations, household routines, and pickup reminders.

A changed arrival, departure, guest count, or budget produces a preview before anything executes. The dependency graph identifies affected commitments and shows the rest as untouched. Each operation carries its cause, price, lifecycle state, and an approve/decline decision.

The difficult cases are the point:

A dispatched grocery order cannot be undone. Its cost remains, and a separately priced top-up needs a separate decision.
A cancellation fee that changes after approval triggers a fresh quote and consent. It is never silently charged at the new price.
Declined choices stay declined while the facts remain unchanged.
Pending decisions and the causal ledger survive a reload. Later, “What changed because of the flight?” distinguishes proposed, approved, and applied effects using persisted per-operation provenance and status.
Repeating an unchanged absolute fact is a no-op. Arbitrary supported values can also be entered through the fact editor.

How I built it

The TypeScript engine owns typed facts, desired-state reconciliation, lifecycle policies, consent binding, and a replayable journal. It has no external I/O. A React/Vite app presents the plan, natural-language composer, direct fact editor, explicit simulated clock, and causal receipts.

Alongside the offline preview, a separate local Connected MCP demo uses the MCP SDK’s browser client and a localhost-only server over Streamable HTTP. It sends initialize, tools/list and tools/call requests and records the JSON-RPC exchanges for proposal, exact payload-hash/facts-revision approval, and separate execution. The public GitHub Pages app remains an offline simulation; its Local MCP setup view explains how to run the connected demo locally. Both use fictional service state, with no Alexa runtime integration or real transactions.

Development was AI-assisted with Devin, followed by separate source review and browser acceptance testing. Review uncovered real implementation defects around stale facts, repeated approvals, fee drift, declined alternatives, persistence, and historical attribution; those were corrected and checked with targeted automated regressions and repeat browser tests.

Verification and challenges

The October 13, 2026 deployed merge commit 2050e46285a5a68a1fe0db4d9a21020509e87e54 passed lint, strict type checking, 117 automated tests (77 engine, 28 simulator/DOM, and 12 MCP), and the production build; its GitHub Pages deployment succeeded. The property suite exercises 1,200 randomized action sequences per run. Tests cover idempotence, unaffected commitments, consent and fees, replay equality, and provenance. These are regression checks, not a proof of correctness or a user study.

October 19 update: merge 68a1f2d passed 234 automated tests (94 engine, 121 simulator/DOM, 19 MCP), lint, type checking and build, with successful Pages deployment. Cancellation cards now distinguish an uncharged quote from a fee charged by a simulated execution, and the named Event ledger supports keyboard focus and scrolling. These changes strengthen the design and technical implementation: people can check the cost and inspect the record without a mouse. PR #21 validation covered 14 Firefox/WebKit cases and 170 checks, including reload, focus and reduced motion; 14 full-page axe scans reported no violations. This does not establish full accessibility: native Safari/iOS and assistive-technology speech were not verified.

Browser checks covered the deployed offline flow, reload persistence, unsupported-command clarification, mobile overflow, and keyboard modal focus. The linked 1:48 demo shows the local Connected MCP prototype: proposal, approval of one exact action, then a separate execution step. Services and money are simulated; the public offline preview is available through Try it out.

The hardest design decision was making partial success honest. A changed plan does not guarantee that every service can comply, and a fee is not a saving. Ripple keeps those consequences visible instead of pretending that recovery always succeeds.

What I learned and what's next

Deterministic state and an injected clock make subtle agentic failures reproducible. The next engineering work is concurrent-session handling, richer fictional refund/waitlist policies, and validation against official Alexa+ preview tooling if entrant access becomes available.

Honest limits

This is a simulated Alexa+ experience, with no Alexa runtime connection, AWS service use, real bookings, purchases, calendar writes, or private household data. Prices and policies are fictional. State is browser-local and intended for one tab. The intent parser is bounded; voice input is not implemented, and optional text-to-speech uses the browser. The simulated clock is UTC-labelled and does not model daylight saving. No human user study or additional teammate contributions are claimed.

Product feedback: https://github.com/sharonbasovich/ripple-alexa/blob/main/docs/feedback.md Friction log: https://github.com/sharonbasovich/ripple-alexa/blob/main/docs/friction-log.md