• 

• 

• 

Alexia Plus — Pizzaiolo Copilot

The kitchen changed. Alexia kept up.

Inspiration

A professional kitchen is a constantly changing environment. Ingredients, temperatures, equipment, timing, and production plans can change while work is already underway.

For a pizzaiolo, the challenge is not simply obtaining a calculation. It is knowing which information is still valid, which decision can still be used, and what must be checked before continuing.

Alexia Plus began with a larger ambition: to build a hands-free culinary copilot that understands what a person wants to prepare, what ingredients and equipment are available, what information is missing, and how to guide the next step.

Our guiding principle is simple:

The cook should focus on cooking. The software should manage the complexity.

What We Built

Alexia Plus is a prototype professional pizza-making copilot. This submission demonstrates a simulated Alexa+ web experience, developed with AI-assisted coding tools, using a bounded natural-language router, real deterministic production tools, explicit confirmations, and persistent preparation history.

The current demonstration is text-based and uses clearly identified fictional exercise data.

It demonstrates six connected capabilities:

• Preparation context: Keep an identified preparation active and retrieve its current state.
• Intent routing: Recognize supported natural-language requests and direct them to the appropriate existing tool.
• Controlled production calculations: Collect inputs with their declared provenance and use a real calculation engine.
• Explicit authorization: Separate a proposed operation from the human confirmation that permits it.
• Correction awareness: Immediately withdraw the applicability of an older decision when a confirmed input changes.
• History and continuity: Preserve previous decisions and resume the preparation without silently repeating a calculation.

These capabilities operate together rather than as unrelated demonstrations.

The Demonstration: When the Kitchen Changes

Our reproducible exercise starts with a fictional pizza preparation and a set of explicitly confirmed inputs.

The operator asks Alexia to calculate a target water temperature.

The actual calculation engine returns 26.00°C.

Then an important condition changes: the flour temperature is corrected.

Alexia does not silently continue presenting the previous calculation as current. The original decision remains available in the history, but its applicability changes to HISTORICAL.

There is now no current water-temperature recommendation.

Only after a new request and a separate explicit confirmation does the engine return the updated target: 24.625°C.

The operator can inspect both decisions and resume the preparation without triggering another calculation.

The innovation demonstrated here is not the temperature formula itself. It is the continuity of authority, context, and decisions when the underlying information changes.

All quantities and results in this demonstration belong to a synthetic exercise. They are not claims about physical measurements or a validated real-world pizza recipe.

How We Built It

The runnable submission uses:

Python 3.12 for the local application server and production logic, HTML, CSS, and JavaScript for the browser interface, and SQLite for persistent exercise state and journals.

A bounded text router interprets supported requests and connects them to existing tools. It is deliberately not presented as a general-purpose language model.

The system distinguishes draft data, recorded facts, pending proposals, confirmation receipts, applicable decisions, and historical results.

Preparation identity, journal revisions, source information, and explicit confirmation help prevent a response belonging to an older state from being treated as an instruction for the current state.

Development and testing were assisted by OpenAI Codex, including isolated test environments and adversarial checks of the boundaries between interface actions and actual business decisions.

During the submission period, we built and refined the integrated operator experience. The Operator Experience 002 iteration brought the preparation and four input cards into one workspace, separated drafts from recorded values, improved confirmation visibility, and made technical evidence secondary to the operator's next action.

An independent bounded audit reported 117 passing candidate tests, including nine newly designed counterchecks, alongside real Chrome exercise journeys. This supports the tested technical behavior; it is not a claim of general usability or scientific certification.

Challenges We Faced

One of our biggest challenges was discovering that technical reliability does not automatically create a good user experience.

Our early interface exposed too many internal details: provenance fields, technical identifiers, timestamps, confirmations, and journal data.

We improved the navigation, but the current prototype still requires substantial manual input. The long-term goal is to let the system handle that complexity through natural interaction without weakening its safeguards.

Another challenge was distinguishing a calculation that was correctly performed in the past from a recommendation that remains applicable now.

We also learned that retrieving a document or producing a plausible AI-generated sentence does not establish scientific correctness or permission to publish that material.

These lessons shaped the design of Alexia's boundaries.

Research Beyond the Submitted Demo

The broader Alexia research project has explored a private culinary knowledge library containing 170 transcriptions still requiring review, a controlled local Mistral generation workflow, and future voice interaction.

A separate FlourScan project has also demonstrated physical barcode acquisition from a real flour bag using an Android smartphone.

These efforts inform our longer-term architecture, but they are not bundled as functioning culinary-generation, voice, or scanner integrations in this submission.

The distributed demo contains synthetic exercise content, runs without an active generative model, and does not claim native Alexa+ connectivity.

What Makes Alexia Different

Our goal is not to build another chatbot that always produces a confident answer.

We are exploring a kitchen assistant that can distinguish:

What the user wants. What is actually known. What is missing. What has changed. And which assistance is still applicable.

The current simulation demonstrates that principle through a real, inspectable operator workflow with preserved decisions and controlled corrections.

What's Next

Our next major milestone is natural, two-way, hands-free conversation.

A professional should eventually be able to say:

"Alexia, I'm preparing forty dough balls for tonight. Here's the flour I'm using. What else do you need to know?"

Alexia should identify the missing information, ask relevant follow-up questions, preserve confirmed facts, and explain the next appropriate action.

We plan to extend the experience toward flour characteristics, ingredient availability, hydration, kneading, fermentation, maturation, dough problems, cooking, and culinary education.

Future integrations may include qualified mixer profiles, the FlourScan identification workflow, and camera-assisted observation.

Those are development goals, not features claimed as operational in this submission.

Our Vision

A cooking copilot should not force a professional to become the administrator of a technical system.

It should make sophisticated tools easier to use while keeping their limitations visible.

Alexia Plus — The kitchen changed. Alexia kept up.

Built With

• css3
• html5
• javascript
• openai
• playwright
• powershell
• pytest
• python
• sqlite