Inspiration Smart technology is frequently celebrated for making life effortless, but for individuals with limited mobility, motor disabilities, or cognitive fatigue, modern technology is fraught with invisible barriers:

The Physical Vulnerability of Smart Living: For someone who cannot easily walk to the front door, commanding an assistant to "Lock the door" is not just a convenience—it is a critical safety matter. Traditional assistants often operate as black boxes, suffering from hallucinations or silent network dropouts where a user has no verifiable guarantee whether their deadbolt actually engaged. Ecosystem Fragmentation: A user needing to manage household appliances, order fresh groceries, check cloud backups, listen to audiobooks, and track shipments is forced to jump across dozens of siloed apps and websites. Each context switch increases motor fatigue and cognitive load. The E-Commerce Return Crisis: Over ( 30% ) of consumer electronics purchased online are returned due to preventable specification mismatches—such as buying a laptop that lacks dedicated GPU tensor cores for machine learning, or noise-canceling headphones without adequate battery life for long commutes. This generates massive reverse-logistics carbon emissions and billions in merchant waste. We built AccessAble and Amazon One to solve these exact challenges: creating a safety-governed, accessible smart-home agent coupled with a unified ecosystem super-app that benchmarks hardware compatibility mathematically before checkout.

What It Does Accessible Smart-Home Control (AccessAble): Enables hands-free, natural language control over home devices (lights, fans, curtains, door locks) using either conversational voice or text. Deterministic Two-Phase Safety Gate: Sensitive physical security operations (like locking or unlocking doors) are never executed blindly. They require explicit, time-bounded user confirmation with idempotency guards to eliminate accidental actuations. 100% Offline Resilience: If the cloud LLM is throttled or the internet disconnects, a local rule-based AST clause parser instantly takes over so users are never locked out or left in the dark. Unified Ecosystem Super-App (Amazon One): Unifies 18 distinct Amazon services across 7 pillars (Shopping, Payments, Entertainment, Reading, Smart Devices, AWS Cloud & Bedrock AI, and Business) into one single, accessible portal. AI Purchase Risk & Compatibility Engine (ReturnWise): Compares customer requirements (budget, RAM, storage, battery, specialized workloads) against hardware specifications to calculate a deterministic Compatibility Score and flag return risks before buying. How We Built It We designed the solution across three decoupled layers: a high-performance React 19 frontend, an asynchronous FastAPI backend with SQLite database persistence, and an intelligent Hybrid AI Agent planning pipeline.

System Architecture User Voice / Text Request │ ▼ [React 19 Accessible Frontend] ────► [FastAPI Persistence Layer] │ │ ▼ ▼ [AccessAble AI Agent Router] [SQLite Database] ├── 1. Primary: Groq LLM Planner ├── Device States └── 2. Fallback: Local Regex Parser ├── Action Plans │ ├── Cart & Favorites ▼ └── Audit History [Deterministic Safety Gate] ├── Non-sensitive: Execute immediately └── Sensitive (Locks): Issue token & await confirmation (POST /actions/confirm) Mathematical Formulations

  1. Hardware Specification Compatibility Index ( S_{\text{compat}} ) To prevent post-purchase returns, we formulate the compatibility of candidate product ( P ) against user requirements ( R ) using Multi-Attribute Utility Theory (MAUT):

$$S_{\text{compat}}(P, R) = \frac{\sum_{i=1}^{N} w_i \cdot \delta_i(P_i, R_i)}{\sum_{i=1}^{N} w_i} \times 100$$

Where attribute weights are defined by vector ( \mathbf{w} ):

$$\mathbf{w} = \begin{bmatrix} w_{\text{budget}} \ w_{\text{RAM}} \ w_{\text{storage}} \ w_{\text{battery}} \ w_{\text{workload}} \end{bmatrix} = \begin{bmatrix} 25 \ 25 \ 20 \ 15 \ 15 \end{bmatrix}, \quad \sum_{i=1}^{5} w_i = 100$$

The budget satisfaction sub-function ( \delta_{\text{budget}} ) penalizes overruns to prevent buyer remorse:

$$\delta_{\text{budget}}(P_{\text{price}}, R_{\text{budget}}) = \begin{cases} 1 & \text{if } P_{\text{price}} \le R_{\text{budget}} \ \max\left(0, 1 - \frac{P_{\text{price}} - R_{\text{budget}}}{R_{\text{budget}}}\right) & \text{if } P_{\text{price}} > R_{\text{budget}} \end{cases}$$

Hardware attribute metrics ( \delta_{\text{hardware}} ) (e.g., RAM capacity ( M ), storage capacity ( S ), battery run-time ( T )) satisfy:

$$\delta_{\text{hardware}}(X_{\text{spec}}, X_{\text{req}}) = \begin{cases} 1 & \text{if } X_{\text{spec}} \ge X_{\text{req}} \ \frac{X_{\text{spec}}}{X_{\text{req}}} & \text{if } X_{\text{spec}} < X_{\text{req}} \end{cases}$$

  1. Predicted Return Risk Probability ( P(\text{Return}) ) We model the empirical likelihood of a purchase return through a logistic function driven by compatibility score deficits and unfulfilled workload constraints:

$$P(\text{Return} \mid P, R) = \frac{1}{1 + e^{-\left(\beta_0 - \beta_1 S_{\text{compat}} + \sum_{k} \gamma_k \mathbb{I}_{[\text{deficit}_k]}\right)}}$$

Where ( \beta_0 \approx 0.30 ) represents baseline category return rate, ( \beta_1 > 0 ) scales compatibility gain, and ( \mathbb{I}_{[\text{deficit}_k]} \in {0, 1} ) signals critical hardware bottlenecks (such as lacking dedicated NVIDIA CUDA cores when ( R ) requires machine learning).

  1. Deterministic Safety Gate State Transitions Every generated action ( a_j = \langle d_j, c_j, \theta_j, \kappa_j \rangle ) has a device ( d_j ), command ( c_j ), parameters ( \theta_j ), and confirmation requirement ( \kappa_j \in {0, 1} ). Device state ( \mathbf{S}_t ) transitions according to:

$$\mathbf{S}{t+1} = \begin{cases} f(d_j, \theta_j) & \text{if } \kappa_j = 0 \ f(d_j, \theta_j) & \text{if } \kappa_j = 1 \land \text{TokenValid}(\tau_j, t) \land a_j \in \mathcal{U}{\text{confirmed}} \ \mathbf{S}_t & \text{otherwise (action remains pending)} \end{cases}$$

Where the temporal validity check enforces automatic token expiration:

$$\text{TokenValid}(\tau_j, t) = \mathbb{I}\left(0 \le t - t_{\text{issued}}(\tau_j) \le T_{\text{expiry}}\right), \quad T_{\text{expiry}} = 300\text{ s}$$

Challenges We Faced Eliminating Hallucinatory Actuations in Physical Security: Problem: Generative LLMs sometimes assume an action is already executed, or accidentally toggle door locks when handling ambiguous phrasing like "Check the front door." Solution: We decoupled the LLM planner from execution. The planner only produces an abstract JSON proposal. Our programmatic safety validator forces ( \kappa_j = 1 ) for all front_door_lock operations regardless of LLM output, preventing any state modification without explicit, tokenized user confirmation. Guaranteeing 100% Offline Availability: Problem: A cloud-only assistant leaves mobility-impaired individuals stranded if internet connectivity drops. Solution: We wrote an offline fallback planner with regex clause-splitting and intent classification. If Groq API throws any network error or timeout, the local planner generates the exact same verified Pydantic schema in under ( 2\text{ ms} ). Consolidating 18 Services Without Visual Overload: Problem: Merging shopping, payments, streaming media, Kindle, AWS Bedrock AI, and smart home controls into one web app risked creating an overwhelming, high-cognitive-load UI. Solution: We engineered a modular architecture centered on React 19 Contexts (OneContext and ProductContext), organizing services into 7 clear pillars with high-contrast accessibility options, keyboard navigability, and screen-reader-friendly attributes. Handling Partial Routine Failures Gracefully: Problem: In complex multi-action commands (e.g., bedtime routine turning off lights, turning on the fan, and locking the door), failing one action or leaving one pending confirmation must not falsely report the entire routine as completed. Solution: We implemented atomic sub-action tracking where the overarching execution status is marked partial_success, clearly informing the user which devices changed state and which action awaits verification. Accomplishments That We're Proud Of 68/68 Automated Tests Passing: Complete test coverage verifying device state transitions, safety confirmation gates, token expiration, routine lifecycles, and edge-case accessibility features. Zero Accidental Actuation Guarantee: Proven mathematical and programmatic barrier ensuring deadbolts and access doors cannot be actuated without confirmed user intent. Sub-200ms Execution Latency: Ultra-fast planning pipeline combining Groq hardware acceleration with instantaneous local fallback. End-to-End Assistive Ecosystem: Successfully bridging hands-free smart-home assistance with retail purchase protection in a unified, accessible experience. What We Learned Physical AI Demands Deterministic Guardrails: Generative AI is outstanding for natural language understanding, but physical execution must always be governed by hard-coded, deterministic safety logic. Accessibility-First Design Improves the Experience for Everyone: High-contrast modes, concise language settings, and zero-panic confirmation gates don't just help users with disabilities—they make technology significantly more reliable for everyone. Mathematical Pre-Purchase Analysis Saves Resources: Preventing e-commerce returns upstream through specification matching is exponentially more sustainable than streamlining post-purchase return shipping. What's Next for AccessAble & Amazon One Matter & Zigbee Hardware Bridging: Extending our simulated device engine into real-world smart-home controllers using Matter over Thread protocols. On-Device Small Language Models (SLMs): Deploying quantized edge models (like Gemma 2 2B or LLaMA 3.2 1B) directly onto local hubs for zero-cloud voice autonomy. Computer Vision Compatibility Scans: Adding multimodal visual verification to check hardware port layouts and physical space dimensions before purchase.

Built With

Share this project:

Updates

Submission history