Utterance

In plain words: Companion: One spoken request

Designed 1 min read 8 glossary terms 6 connected pages
The short version written for the Snayu team

How one push-to-talk utterance is authenticated, transcribed, reviewed and submitted as a request handoff, and how the result is later presented as text or speech.

Why read it: Read this when working on the voice request flow from phone to workflow and back.
  1. 1Each utterance gets a fresh identity with fixed size, duration and expiry limits.
  2. 2Raw audio is dropped after transcription per retention; low confidence asks for clarification.
  3. 3Submitting ends Companion's job; the workflow engine separately decides whether to run the work.

Designed Contract; transcription and handoff are not live.

Words on this page, decoded click one for its card

The original text Underlined words open their plain-English card.

One deliberate utterance starts a bounded foreground route. It can settle a request handoff even when the destination has not yet admitted work.

When push-to-talk opens, the client creates a fresh utterance identity and fixes its frame sequence, codec, byte/duration limits, and expiry. Tether may make the host reachable, but WardSecurity Desk independently proves application, device, Principal, scopes, and object authority.

EchoVoice then admits the frames, retains an attributed transcript, and drops raw audio under the chosen retention. Low confidence returns clarification. Where preview is required, the person reviews the words before submitting them.

companion.submit_turn@1 commits an idempotent CompanionTurnHandoff@1 binding exact IntentRequest, requested PatternWorkflow, Principal, device/session/utterance identities, expiry, disclosure, and correlation. That submission action then ends. SpellweaverWorkflow Engine independently decides whether to admit the exact registered destination; its owner handles clarification, consent, work, cancellation, and recovery.

push-to-talk → authenticate → transcribe → preview or clarify
→ typed Intent → settled CompanionTurnHandoff@1
                     || independently admitted destination Invocation
settled terminal-result reference → Companion presentation under its admitted output policy

Once a terminal-result reference has settled elsewhere, a fresh authorized companion.present_result@1 may present it against this utterance/device. The presentation has its own finish. Committed text survives synthesis or playback failure, but text alone cannot complete a presentation that requires speech.

Text-only fallback counts as completion only when the admitted configuration explicitly accepts it. Otherwise return exact partial or non-completion for the presentation. This leaves the independently settled destination result unchanged: Companion cannot reopen or relabel it and owns no wait, cancellation, retry, or recovery for that destination InvocationJob Request.

The two handoffs therefore promise separate settled results. A ProductPackaged Offer needing one coordinated round trip must pin a named SuiteApp Bundle with aggregate wait, cancellation, recovery, and settlement. Return explains what reconnect can retrieve without replaying the request.