Inspiration
A booking request can reach a service even when its confirmation never comes back. Should a person try again, wait, or assume it worked? A confident answer from an assistant is not enough if it creates a duplicate reservation or hides an uncertain result.
I started EasyLayer with a practical accessibility question: How can an assistant help someone complete a booking while keeping them informed and in control? The project focuses on people who find multi-step forms difficult or tiring, and on recovering from interruptions without losing track of what has actually happened.
What it does
EasyLayer is an Alexa+ experience simulation built around clear choices, a recoverable draft, explicit approval, and an honest result.
In the interactive browser demo, a person selects a sample appointment, pauses and resumes the draft, reviews its details, and approves the exact appointment before submission. The difficult scenario is a lost submission response: EasyLayer keeps the result unknown, blocks a repeat submission, and checks the existing sample record before reporting success.
The latest demo compares the approved service and provider identifiers and names, date, time, timezone, duration, price, currency, contact, and expected record ID. Missing details, mismatches, or multiple records cannot produce a verified result. If browser storage cannot save progress, the interface says that progress may be lost or an older draft restored after refreshing or closing the tab.
The new Record details do not match scenario makes the verification boundary visible: an expected-versus-observed table identifies the different service while the result stays unknown. A semantic appointment summary is available at every screen size, and the guided summary includes the full date, provider, timezone, currency, and fictional contact.
The demo also detects when another tab has changed saved progress and asks the person to load it before continuing. This is a best-effort localStorage guard, not an atomic concurrency guarantee. Known unavailable times remain excluded through navigation and draft restoration.
Implementation scope: the browser demo is a deterministic simulation with fictional data. It does not call a generative model, connect to native Alexa, or create a real appointment. The repository separately includes a self-hosted Python MCP backend and its own simulator. The static browser demo and narrated film are not connected to that backend.
Why Alexa+
Booking illustrates an assistant moving from answering questions to helping complete tasks. Conversation can help a person express preferences and resume an interrupted activity; a visual summary keeps important facts available for careful review.
EasyLayer explores that interaction pattern through the hackathon's simulation path. The web interface demonstrates the proposed experience. It is not a deployed Alexa add-on or evidence of native Alexa compatibility.
How I built it
The browser demo uses JavaScript, HTML, CSS, SVG rendering, and browser local storage. A deterministic state machine makes normal submission, an unavailable time, a lost response, and a mismatched record repeatable. Node tests exercise its approval, verification, restoration, and storage behavior.
The separate v0.4 backend uses Python, the MCP Python SDK, Streamable HTTP, and SQLite. Eight tools cover service discovery, availability, draft creation, status, resuming, discarding an unsubmitted draft, completion, and verification. Its own simulator calls the actual local MCP endpoint and shares the backend's persisted draft state. Contact entry and approval occur on a separate review page. An optional MCP Apps resource supplies a booking summary for compatible hosts.
A narrow HTTP adapter targets Easy!Appointments 1.6.0, including session handling, CSRF, submission, and record read-back. Controlled contract tests exercise the adapter; end-to-end execution against the original PHP/MariaDB deployment remains an open validation gate. Backend duplicate suppression is limited to one retained database, owner, and exact booking target. A lost response may still require manual source inspection.
I used specialized AI-agent reviews to examine architecture, interaction design, booking safety, testing, and submission strategy. ElevenLabs generated the English narration, and FFmpeg assembled the walkthrough and captions.
Challenges I ran into
The hardest problem was distinguishing an unsuccessful action from an action whose result is unknown. Automatically repeating an uncertain write can be harmful. The backend records submission state before attempting the external request; the browser demo makes the same decision visible with a controlled sample scenario.
Another challenge was keeping approval meaningful. A person approves specific details, so verification must compare the whole appointment. A later review found that the browser demo could accept a record with a different service when other fields matched. I replaced that partial check with shared full-record matching for both normal submission and response-loss recovery, and added regression tests.
Storage also needed honest feedback. The updated demo checks storage read-back before claiming a save and explains the limitation when saving fails. Older saved records without complete approval evidence remain unverified.
Accomplishments that I am proud of
The project demonstrates a concrete safety behavior: when confirmation is lost, inspect the existing result before attempting another booking. It also makes selected, approved, submitted, and verified states visible instead of treating them as interchangeable.
The current browser demo passes 59 Node tests. Separately, the earlier v0.4 backend recorded 117 passing controlled tests on September 29, 2026, including MCP HTTP, lifecycle, source-adapter contract, and simulated DOM checks. These are different suites. They do not establish real-browser behavior, native Alexa compatibility, production booking reliability, or user-study outcomes.
The submitted 134-second English narrated video is an automated illustrated walkthrough of the sample flow. It predates the latest verification, stale-tab, unavailable-time, and accessible-review updates and has not been re-recorded for those changes. The public repository contains the current runnable code, assets, test instructions, and verification notes.
A follow-up backend change also requires receipt end time to match the approved start plus duration. 44 targeted Python tests passed across core, lifecycle, and source HTTP contract checks. The MCP-chain test was not rerun because its dependencies were absent; the historical 117-test result remains a separate earlier run. Keyboard-focus handling and semantic summary markup were improved, but real-browser and screen-reader validation remain open.
What I learned
A helpful assistant needs to communicate the difference between selected, approved, submitted, and verified. Preserving uncertainty can be more useful than giving a confident answer.
I also learned to separate interface simulation, protocol integration, source-system validation, and user experience. Each requires its own evidence. Accessibility includes understanding the next step, recovering from interruptions, and knowing whether an action actually happened.
What is next for EasyLayer
Next I plan to complete an end-to-end booking against an owned Easy!Appointments test instance, validate real-browser and voice behavior, and observe people using the workflow. Native Alexa integration and richer language support remain future work, with approval and execution grounded in explicit state.
The goal is to make everyday digital tasks easier to complete—with clear choices, recoverable progress, and results people can trust.
Log in or sign up for Devpost to join the conversation.