Task: Generate VOICEIA.md — Voice Information Architecture Registry

Task: Generate VOICE_IA.md — Voice Information Architecture Registry

Objective

Produce a VOICE_IA.md that serves as the single source of truth for a voice-driven conversational application's information architecture: the invocation model (wake word, invocation name, launch intents, deep-invocation phrases), the full intent inventory, per-intent blueprint (purpose, sample utterances, slots, primary response role, confirmation rules, failure matrix, context effects, multimodal expansion), multi-turn dialog flows, shared surfaces (re-prompt, fallback, disambiguation, confirmation, handoff, linking), context model (what is remembered within and across sessions), platform strategy (Alexa / Google / Siri / custom), multimodal expansion strategy, account-linking strategy, privacy and safety constraints, and bidirectional traceability from product use cases to intents. An agent or designer reading this document knows exactly what intents exist, how users invoke them, what slots they consume, how the dialog carries state across turns, how each intent fails, and how every use case is realized on the voice surface — without making any independent grammar, naming, or confirmation decisions. VOICE_IA sits between product requirements (proposal, use cases) and per-unit voice SPECs, the same way WEB_IA sits between product requirements and per-unit web SPECs.

This skill covers voice-first conversational interfaces — surfaces where voice input is the primary modality and voice output is a primary modality. It does not cover text chatbots (a future CHAT_IA.md would handle those) unless the chatbot shares the same intent model; in that case, scope it in explicitly in Phase 1.

Inputs

1. Product / proposal document (required) — product purpose, target users, and rationale. Sets the scope and audience frame for the IA.
2. Use cases document (required) — enumerates user interactions and jobs-to-be-done. Primary input. Every use case with a voice surface must map to one or more intents in the inventory.
3. Architecture document (optional but recommended) — target voice platforms (Alexa Skill, Google Action, Siri App Intents, custom stack with ASR / NLU / TTS), dialog framework, backend endpoints the voice app hits, account-linking model. Informs the platform strategy, slot model, and fallback design. If absent, infer conservative defaults and flag non-obvious choices as open questions.
4. Existing voice codebase (auto-discovered) — discover current intents, sample utterances, slot types, and dialog-delegation configs from source (e.g., interactionModel.json for Alexa, action.json or intents/* for Google, App Intent declarations for Siri, YAML NLU configs for custom stacks). Treat as reference only — VOICE_IA is the target state, not a mirror of the current state.
5. Decision documents (optional) — architectural decisions that constrain the IA (e.g., "always confirm before any destructive action", "never give medical advice — always hand off", "account linking required for all personal-data intents").
6. Sibling IAs (optional) — if MOBILE_IA.md, WEB_IA.md, or CLI_IA.md exist, use-case traceability must be consistent across all channels. MOBILE_IA.md is especially important for App Intent overlap — App Intents / Siri Shortcuts invoked from inside a mobile app are owned by MOBILE_IA.md; full voice dialog architecture is owned here.
7. Interface contract (optional) — if INTERFACES.md is present, per-intent data dependencies may reference endpoints by EP-name; wire formats are owned by INTERFACES.md, not redefined here.

The user may override scope (e.g., "only the Alexa skill, not the Google Action"). Support that by recording the narrowed scope in the Identity & Context section and excluding out-of-scope platforms from the inventory.

Workflow

Voice IA generation proceeds in seven phases: scope, centralized-strategies (platform / invocation / slot / dialog), cross-cutting rules (confirmation / fallback / privacy), inventory, per-intent blueprint, flows and shared surfaces, traceability and validation. Phases are sequential — later phases depend on earlier decisions — but revisit earlier phases if a later phase reveals a gap.

Phase 1: Scope & Audience

Derive from the product doc and use cases document the target voice surface (single platform, multi-platform, voice-only vs voice+screen, embedded in a mobile app vs standalone) and the audiences the IA serves (at-home, driving, hands-busy, accessibility-primary, multitasking). Record explicitly what is not in scope for this VOICE_IA document — text chatbots, App Intents owned by a sibling mobile IA, voice-writing copy, specific TTS voice selection. Keep audience treatment thin — named user types and their 3–7 top tasks per audience. No deep persona work.

Phase 2: Centralized Strategies — Platform, Invocation, Slot, Dialog & Context

Decide the cross-cutting strategies before enumerating intents. This prevents per-intent drift where each intent invents its own slot types, confirmation policy, or context rules. Each strategy is declared exactly once (Rules 9–11) and referenced by name from every intent that uses it.

Decide, in order:

1. Platform strategy — which platforms are targeted; what feature-parity rules apply (identical across platforms vs platform-specific extensions); which platform-specific capabilities are in scope (Alexa Reminders API, Google App Actions, Siri App Intents, custom-stack features).
2. Invocation model — wake word / activation per platform; invocation name; bare-launch intent (opens the app with a greeting); deep-invocation phrasings ("ask {app} to {action}"); one-shot vs session-based interaction; session-end conditions (explicit stop, silence timeout, fulfilled intent with session-end, user-initiated exit).