Product specification What Aside does — and why it does it

Aside is built for people for whom traditional smartphones are a barrier — blind & low-vision users, deaf & hard-of-hearing users, motor-impaired users, users with cognitive load or memory differences, situational disability (driving, hands full, low light), and older users who never built fluency with touch UI. Every capability below is paired with the specific accessibility need it solves. Step-by-step instructions for using each feature live in the How-to guides.

Audience

Six categories Aside is designed for

Every capability and action below is tagged with one or more of these categories. The tags answer the question “why is this in the product?” — never as decoration.

Vision Blind, low-vision, partially-sighted, light-sensitive. Cannot rely on reading the screen, finding small UI targets, or distinguishing tightly-spaced colors.
Hearing Deaf or hard-of-hearing. Replies must be readable; chat history is the canonical transcript; no information is audio-only.
Motor Limited fine-motor control, tremor, pain, or limb difference. Cannot reliably tap small targets, swipe gestures, or hold the phone steady to type.
Cognitive Memory differences, ADHD, traumatic brain injury, executive-function load, dyslexia. Benefits from offloading remembered facts and from one clear input modality.
Situational Driving, walking, carrying things, holding a child, riding a bike, dim or wet conditions. Same accommodations a permanently-disabled user needs, in the moment.
Age-related Older users who never built fluency with gesture nav, app drawers, or system Settings hierarchies. Wants to ask for what they need in plain language.
Trust / privacy Users who can’t risk their assistant leaking sensitive data. The architecture treats this as a primary requirement, not a feature.

Voice & conversation

How Aside listens and replies

The shell of every interaction. These primitives compose into “hands-free, eyes-free, no apps” — the load-bearing premise.

CapabilityWhat it doesWhy it’s in the product
Push-to-talk + text input Hold the orb to speak, or type into the chat input. Replies stream live as both text and audio.
MotorVisionHearingCognitive
Voice is mandatory for blind / motor users; text is mandatory for deaf users; both being equal-class first-tier inputs avoids forcing anyone into a modality that doesn’t fit them. How to push-to-talk · How to type
Streaming reply (audio + text) Audio starts at the first sentence boundary, not after the full reply has been generated. Feels roughly twice as fast as batch reply.
VisionCognitiveAge
Replaces reading entirely — the user hears the answer beginning before they could possibly read it. Lower perceived latency cuts cognitive load on every turn. How to use streaming reply
“Hey Aside” wake word While the app is open Aside perpetually listens for the wake phrase (“Hey Aside” plus 7 phonetic variants). The post-wake substring becomes the active turn — “Hey Aside what’s the weather” fires the turn on what’s the weather with no taps.
VisionMotorSituational
A blind user can’t find an on-screen button. A user with no fine-motor control can’t tap one. A driver shouldn’t. The wake word makes the assistant fully buttonless from any state where the app is foregrounded. How to use the wake word
Default Digital Assistant Aside plugs into Android’s VoiceInteractionService. Once set as the user’s default assistant, the system assist gesture (long-press home, Bixby key, Pixel power+home) bypasses Bixby/Gemini and routes straight to Aside — already listening, even from the lock screen.
VisionMotorSituationalAge
A whole-OS voice trigger that works from any app, any screen state, with zero visual targeting. The most accessible affordance the platform exposes. How to make Aside your default
Continuous conversation After a voice-initiated turn, when speech finishes the mic auto-restarts. Hands-free chained turns until the user taps stop or there’s an error.
MotorSituationalVision
Removes the per-turn tap. A motor-impaired user, a driver, or anyone with their hands on something else can hold a real back-and-forth conversation. How to use continuous conversation
Multi-turn session continuity The server maintains per-session message history in memory, passed as the messages array to OpenAI’s API on each turn; the client also persists chat history.
CognitiveAge
Users with memory differences or executive-function load don’t have to re-state context every turn. “Now what about Tuesday?” works. How to ask follow-up questions
Capabilities self-tour “What can you do?” / “give me a tour” / “show me what you got” — Aside recites a canonical capabilities list out loud.
VisionCognitiveAge
Discoverability without a settings menu. A blind or older user finds out what the app can do by asking, not by reading. How to ask Aside what it can do

Core capabilities

Standing features available on every turn

Persistent surfaces — always available, no command needed.

CapabilityWhat it doesWhy it’s in the product
Voice-first orb UI An animated centerpiece orb conveys app state through color and motion (idle / listening / thinking / speaking / error). Mic-level RMS modulates the orb radius live. Chat history collapses into an on-demand bottom sheet.
VisionCognitive
A single high-contrast focal point replaces a wall of small chat bubbles. State is glanceable — partially-sighted users can confirm “the app is listening to me” without reading. How to read the orb
Persistent memory “Remember my address is …” / “Remember Jason’s number is …” — survives session resets, app reinstalls, server restarts. Auto-injected into the system prompt every turn so “text Jason” / “navigate me home” works with no re-statement. “What do you know about me?” recites it. “Forget …” / “forget everything” deletes.
CognitiveMotorVision
Users with memory differences, fatigue, or speech difficulty state a fact once. They never re-dictate their address, their kid’s phone number, their pharmacy, their wake-up time. Teach Aside · Ask what it knows · Forget
Live device context Phone ships time + battery + last-known location + today’s calendar events + top contacts + recent notifications in every turn. Server pre-fetches real-time weather (open-meteo, 5-min cache) and merges in.
VisionCognitiveMotor
“What’s the weather” / “call mom” / “what was Sarah’s last text” resolve with zero apps opened and zero hallucination. Ask about now without opening apps
Daily briefing “Give me my morning briefing” → composite spoken summary covering time, weather, today’s calendar, recent notifications, and battery state.
VisionCognitiveAge
Replaces the “open four apps to figure out my day” routine with a single spoken request. Get a morning briefing
Quick Settings tile Once added to the QS tray, tapping the tile launches Aside straight into mic-on mode. One-tap voice access from anywhere on the phone.
MotorVision
The QS tray is system-level, larger than any app icon, and reachable from the lock screen. Add the QS tile
Cost counter Subtle title-bar indicator showing the dollar amount spent today. Persists across app restarts; rolls over at local midnight.
CognitiveTrust / privacy
Users on fixed income or with cognitive load around money see usage at a glance, no surprise bills. Read the cost counter

Action surface

Curated, audited Android Intent wrappers

Every action is a small Kotlin function around a known-safe Android Intent or system call — never a generic “agent that can do anything.” Each one is a deliberate, reviewable change. Step-by-step guides for every action live in the How-to guides.

Navigation: open_maps · navigate_to

Communication (drafts only — never auto-sends): dial · compose_email · compose_sms · share_text · add_note

Time, calendar & reminders: set_timer · set_alarm · reminder_at · create_calendar_event · open_calendar_today

App launch & system navigation: open_app · open_settings · open_url · open_web_search · go_home / go_back

Media & capture: youtube_search · spotify_search · open_camera · take_selfie · record_voice_memo · copy_to_clipboard

System controls & safety: flashlight · set_volume · set_ringer · find_my_phone

Memory ops (server-side & on-device): remember · forget

Memory architecture (v2)

Ambient, on-device, never logged

Memory is the single most defensible pillar for an assistant — and the highest-risk feature for trust collapse if done badly. Privacy posture is load-bearing: memories live on the user’s phone, period.

  • On-device storage (Room v1 schema). Bi-temporal schema: memory(id, category, content, observed_at, valid_from, valid_to, source_turn_id, source_quote, confidence, status, format_version). AES-GCM at rest via Android Keystore. Categories: semantic (facts), procedural (preferences), episodic (events), vault (verbatim items), sensitive (health / finance / legal — explicit-only).
  • Per-turn extraction (/v1/memory/extract). Async after the done event, client posts the last N user turns + running summary; server runs a Haiku-class meta-prompt with a four-op vocabulary (ADD / UPDATE / DELETE / NONE); returns ops with provenance quotes; client commits to Room as status=candidate. Server retains nothing.
  • Tainted-source guard. Only the user’s spoken or typed turns are eligible to write memory. External content (web fetches, NotificationListenerService, email bodies, calendar invite descriptions, document bodies) is flagged and excluded from extraction input. Blocks the indirect-prompt-injection class.
  • Sensitive-tier guard. Health, finance, sexual, legal, precise-location categories are explicit-only; auto-extraction is blocked.
  • Memory tab UI. Direct on-device queries — instant, offline-capable. Per-row Forget; candidate-only Keep; top-bar “Forget all.” How to use the Memory tab.
  • “Memory updated” canary. Audible chime + visible toast on every memory write. Trust + a poisoning canary — the absence of the chime when memory was written would be the attack vector.
  • Decay & consolidation. Decay worker runs at 3am local, daily. TTL: episodic 60d, candidates 14d unprompted; semantic / procedural / vault / sensitive durable.
  • Backup & export. Android Auto Backup with E2E encryption (device passcode is the unlock key). Explicit Export / Import pair → AES-GCM .aside-memory file the user saves where they choose.

Per-turn injection: full semantic + procedural + vault + top-k episodic. Sensitive tier never injected unless the query semantically requires it. Wire field is memory_block on POST /v1/turn, capped at ~3.5 KB; server logs record only the memory_block_hash + size, never contents.

Accessibility-first UI primitives

UI v3 — calm warm paper, brand-locked tokens

None of this is “a11y settings” bolted onto a finished design — it’s the design.

  • Bundled fonts. Plus Jakarta Sans (display + body) + JetBrains Mono (eyebrow / metadata / status). Bundled as Android assets — runtime never hits Google Fonts. Zero third-party font fetches.
  • Live text-size slider on the Accessibility settings page with a real-time preview card. How to enlarge the text.
  • High-contrast toggle for partial-vision users + bright outdoor lighting. How to turn it on.
  • Reduce-motion toggle that folds system pref OR user pref. Orb breathe + status-dot pulse become static when active. How to turn motion off.
  • ≥ 56dp hit targets, ≥ 18sp body type. Above the WCAG 2.5.5 AAA threshold (44×44px). A user with a tremor or arthritis can still hit the right thing.
  • 5-screen plain-language onboarding. Welcome → Permissions in plain language → Teach me about you → Voice setup with live waveform → Ready. Walk through onboarding.
  • Empty home state — just the orb + the prompt “Tell me everything.” No tutorials, no buttons, no menus. Removes every decision before the user can start.
  • Mic-denied banner — if microphone permission is denied, an inline banner deep-links to the Application info screen. How to recover.
  • Offline banner via Android’s connectivity callback. Users get explicit feedback that the assistant won’t work right now — never a silent failure.
  • Memory taxonomy in plain language. In-sheet groupings: About you / People / Routines / Sensitive. The underlying schema is preserved; only the labels are user-facing.

Privacy & trust posture

What the architecture promises the user, by construction

Every commitment below is enforced at the code or operational layer — not as policy text.

  • Your model on your server. Aside speaks to OpenAI’s API directly from the operator’s VPS. Prompts and replies are never proxied through a third-party “AI assistant” product surface.
  • No tools at the model. The server calls OpenAI’s chat completions endpoint with no tools or functions defined — the model has no filesystem, no shell, and no outbound network access. Even a successful prompt-injection attack cannot escape the API boundary.
  • Curated, auditable action surface. Each action is a small Kotlin function around a known-safe Android Intent. The set of actions is enumerable.
  • Defense in depth. Tools off at the model. Concurrency cap = 1. Body size cap. URL scheme allowlist. One action per turn. None of the actions sends, calls, or spends money silently.
  • Per-bearer auth, rate-limited. Bearer token in /etc/aside/token (file-mode 600). 30 req/min per token. Concurrency cap of 1 per token.
  • No memory contents in logs. Server log writes record memory_block_hash + size, never the contents. log_redact_memory: true at every layer.
  • No bootloader unlock, no root. Runs on a stock device with a permanently-locked bootloader. No Magisk, no Shizuku, no custom ROMs. Anyone who depends on their phone can install Aside without operator-level work.

Distribution & onboarding

From a website visit to a working app, fully automated

Two channels, no manual onboarding work. A user signs up and is in the app, regardless of their familiarity with Play.

  • Self-serve waitlist form on g3nr8.ai. Replaces the prior mailto: CTAs that required manual onboarding for every tester.
  • Auto-onboarding pipeline. Every signup triggers three parallel actions: a Postgres write, a Gmail SMTP send (with the Play opt-in URL + sideload fallback), and a Workspace Group members.insert via the Admin SDK Directory API.
  • Play tester-source wiring attaches the Workspace Group directly to the Closed Testing alpha track via the Play Developer API.
  • Play arm readiness gate. A “Aside is ready” email is gated by a server-side sentinel that’s set only after a real install via the Play Closed Testing alpha roster has been verified end-to-end.

Build & operational discipline

The discipline that lets a solo founder ship a high-trust accessibility product

Each rule below exists because of a specific past incident or a specific class of mistake we can’t afford with this user base.

  • Single sanctioned release path. One script is the only way an APK or AAB reaches a tester. Refuses to run on a dirty git tree.
  • Branding sanity check on the built artifact. Aborts unless package, label, and absence of legacy strings all check out. Born of an incident where a renamed-but-not-rebuilt artifact reached a tester.
  • Build identity stamping. Every build carries the 12-char short commit SHA + UTC timestamp, rendered on the main screen. A tester screenshot is enough to identify the exact commit.
  • Signing key custody. PKCS12 release keystore + 40-char password live in a credential vault, never in git.
  • 3-region HA, automatic failover. Two app + DB regions plus a witness region. Cloudflare Tunnel auto-routes around dead origins; Postgres auto-promotes the secondary in <30s on primary unreachable.
  • Nightly encrypted backups + weekly automated restore drill. Off-region storage, validated end-to-end without operator presence.
  • Observability. Metrics + logs into Grafana Cloud; backend + frontend exceptions into Sentry. User-impacting issues are detected before the user reports them.

Non-goals

What Aside is deliberately not

Each non-goal is load-bearing: ruling these out is what lets the things above be true.

  • Not a full agent OS. Every action is a deliberate addition. There is no “general tool execution.” The action surface is enumerable.
  • Not a third-party-vendor product surface. The user’s prompts are never proxied through a vendor’s “AI assistant” product. We use OpenAI’s API for inference (gpt-5-mini) and nothing else leaves the operator’s VPS.
  • Not permission-greedy. No permission is requested “just in case.” Each new permission has to be justified by an action that needs it.
  • Not a rooted-phone product. No bootloader unlock, no Magisk, no Shizuku, no custom ROMs. Runs on a stock device a disabled user cannot afford to brick.

Step-by-step instructions for using each capability and action live in the How-to guides, with a real screenshot at every step.