Assistant & Kitchen Ears

Assistance should end in an understandable action

ShoppyCat can request meal suggestions, answer bounded household questions, coach a recipe step, transform leftovers, and produce waste-reduction nudges through callable functions. Suggested recipes are saved explicitly and proposed meal slots merge only into the days and meal types the person selected.

The model does not receive permission to rewrite the whole household. Authentication, premium entitlement, data loading, safety context, result validation, and persistence remain ordinary application code.

Hands-free when hands are occupied

Deterministic navigation and grocery-add voice intents
Wake-cue and spoken-wake detectors based on bounded local audio features
Kitchen sessions with next, previous, repeat, timer, and help commands
Foreground service state coordinated with the active cooking session
Clarification when a destination or item phrase is incomplete
Assistant handoff only for questions outside deterministic commands

Route commands before asking a model

A spoken phrase such as “add two cans of tomatoes to the pantry” has a clear operational shape. ShoppyCat checks deterministic commands first, extracts destination and items, and asks for clarification when required information is missing. Open-ended cooking questions can then use the assistant path without making basic navigation probabilistic.

ArcoBASICArcoBASIC communication example: deterministic kitchen command routing

' Route predictable commands without pretending every phrase needs AI.
FUNCTION InterpretKitchenCommand(text)
    normalized = Lower(String.Trim(text))

    IF String.Contains(normalized, "next step") THEN
        RETURN {"Command": "NEXT_STEP", "NeedsAssistant": FALSE}
    END IF

    IF String.Contains(normalized, "previous step") THEN
        RETURN {"Command": "PREVIOUS_STEP", "NeedsAssistant": FALSE}
    END IF

    IF String.Contains(normalized, "repeat") THEN
        RETURN {"Command": "REPEAT_STEP", "NeedsAssistant": FALSE}
    END IF

    IF String.Contains(normalized, "timer") THEN
        RETURN {"Command": "START_TIMER", "NeedsAssistant": FALSE}
    END IF

    ' A genuine question may use the bounded assistant service.
    RETURN {"Command": "ASK_FOR_HELP", "NeedsAssistant": TRUE}
END FUNCTION

command = InterpretKitchenCommand("next step")
PRINT command.Command

Safety context is product context

Allergen profiles and household context can accompany suggestion requests. Premium entitlement is verified rather than trusted from one client flag, callable functions validate their inputs, and generated structures are normalized before becoming application data.

The goal is useful assistance with clear ownership. Suggested output remains a proposal the household can inspect, apply selectively, edit, or ignore.

Let the deterministic path go first

The specific commands here, next step, repeat, timer, are kitchen-session vocabulary. A different assistant-backed product will route different intents. The reason to check deterministic paths before calling a model at all is what is worth carrying elsewhere.

This is the same argument for keeping a chatbot's slash commands out of the language model entirely, for having a voice assistant handle set a timer for five minutes with a regex instead of an API call, and for any product bolting AI onto an existing workflow: the model should get the questions nothing else can already answer, not all of them.

InterpretKitchenCommand checks for next step, previous step, repeat, and timer before ever falling through to ASK_FOR_HELP. Any system pairing a language model with well-understood, high-frequency actions should route the predictable cases deterministically first and reserve the model for what is actually open-ended.
Suggested recipes are saved explicitly, and proposed meal slots merge only into the days and meal types a person actually selected, never overwriting slots nobody asked about. A model’s output should default to proposal rather than commit, scoped as narrowly as the request that produced it.
Premium entitlement is verified server-side rather than trusted from a client flag, even though the assistant call feels like a convenience feature. Anywhere a paid or gated feature reaches a model or external service, checking entitlement close to the expensive call matters more than checking it in the interface.
Allergen profiles and household context travel with a suggestion request as safety context, not as decoration. When a model’s output can cause real harm if wrong, the constraints that bound its answer belong in the request itself, not in a disclaimer attached to the response afterward.

LEARNING LAYER

Key terms, in plain language

You do not need a systems background to follow the work. These are the specialized terms used on this page.

Callable function: A server-side operation invoked by an authenticated application client. It is useful for protected work such as entitlement checks, notifications, and bounded model-assisted requests.
Confidence level: A visible estimate of how strongly the available evidence supports a result. It helps a person decide whether to accept, inspect, or correct a recognition.
Schema validation: Checking that proposed data has the expected fields, types, ownership, and limits before accepting it. This protects shared collections from malformed or overpowered writes.