iotta / docs / design.md
📖 design.md

iotta — Design Concept

The engineering vision and the principles behind it. For customer-facing positioning and the feature catalog, see product.md; for the wire protocol, see protocol-spec.md and protocol-design.md.


What it is

iotta is a self-hosted voice AI server: it receives audio from an embedded device, runs it through a speech-recognition → language-model → speech-synthesis pipeline, dispatches tool calls, and streams synthesized speech back.

The same server is also the development environment for the teams building the assistant. One deployment spans the whole lifecycle — from pre-hardware simulation, through prototype bring-up, to the production fleet — so behavior validated at one stage carries forward without re-integration. There is no separate test tool.

iotta carries no product-specific knowledge. Any voice AI product is built on it without modifying the platform.


Goals

  1. A complete voice runtime. Session management, a streaming audio pipeline, tool dispatch, and device administration — production-capable, not a demo.

  2. Lifecycle continuity. The same deployment serves every stage of development, so a behavior proven in simulation is the behavior that ships to the field.

  3. A shared AI↔firmware contract. Tool schemas are the authoritative interface between what the LLM can invoke and what the firmware executes. iotta owns those schemas as versioned artifacts, so both teams build in parallel against one source of truth.

  4. A provider-agnostic runtime — pipeline or all-in-one. Every AI component — ASR, LLM, TTS — is pluggable, and the runtime supports both a multi-step ASR→LLM→TTS pipeline (swap any stage, run locally) and an all-in-one speech-to-speech model behind the same interface. Switching providers or runtime shape is a configuration change, not a code change — and both are traced and evaluated identically.

  5. Self-hostable by a small team. One container, local storage, no required cloud dependency for core operation.

  6. Operable in production by that same small team. Durable storage with one-file backup/restore, a one-command health preflight, structured logs and metrics exported to standard tooling, and a turnkey deployment with TLS on by default.

  7. Multi-user with appropriate authority. Application roles — admin, developer, PM — log in with permissions scoped to what they do, configurable by an admin, with every administrative change attributable. (Host-level operation — provisioning, install, backups — is served by deployment ergonomics, not application login.)


Design principles

Same server everywhere. Development and production run the identical binary and protocol. A software device client — and an in-browser simulator — speak the same wire protocol real firmware will, so the full pipeline is iterable before any hardware exists.

Two clean channels. A session carries audio and control on one WebSocket, and the LLM's device-side tool calls on a separate MCP WebSocket. Everything that controls the session transport lives on the session channel; everything the LLM might invoke lives on the tool channel. The tool channel is optional — losing it never stops the conversation. (The rationale is protocol-design.md.)

Versioned artifacts, deliberate promotion. Prompts, tool schemas, and runtime settings are immutable versions on a draft → staged → active lifecycle. Promotion is an explicit action, not an overwrite — so a change is reviewable, pinnable, and reversible.

Everything is observable. Every session — live or simulated — becomes a structured, replayable record, down to per-turn tokens, time-to-first-token, and per-stage/multi-hop timing. Changes are validated against scored eval suites before promotion. Devices report runtime health, and the fleet's crash-rate signal by firmware version drives safe rollout.

Safe by default. TLS for any non-loopback client, per-device session tokens, and OTA that is staged, gated, and auto-rolled-back on a health regression — a bad build never bricks the field.


How the platform is built

The same store-plus-thin-surface shape recurs across every subsystem: an import-light core with a stable API, wrapped by a CLI, a read/write HTTP surface, and an operator UI view. Records persist to embedded SQLite; large artifacts — firmware images, captured audio, trace and eval JSON — stay as files on the host. State is plain files in one directory, so a backup is a single archive.

The feature catalog those subsystems provide is in product.md. The licensing and open-core posture is in commercialization.md: iotta is source-available under the Functional Source License (FSL-1.1-ALv2), self-host first, with a paid edition for operating at fleet scale.