Street AI Project
An embedded intelligence layer that appliance manufacturers integrate into their machines. The machine measures what it just produced, works out what went wrong, corrects itself and takes instruction in plain speech. Everything runs on the device, with no internet connection, no account and no application. The first domain is espresso.
Artificial Domain Intelligence gives a single-purpose machine real intelligence within its own domain. A domain is the scope of what the machine is for. A washing machine's domain is washing clothes. An espresso machine's domain is making espresso.
It reads the physical state of what it is working on, through sensors the machine already has.
It applies expert knowledge of one job to decide what to do next.
It adapts to how this particular owner likes things done.
It understands plain speech and accepts correction in ordinary language.
The intelligence is bounded to one domain. It is not general intelligence, and the narrow scope is what makes it work.
Restricting the system to one job has five consequences, and each one is a reason a manufacturer can ship it.
The machine publishes a list of what it can physically do. Set grind. Dose by mass. Start extraction. Stop at weight. Dispense milk. Eject. The intelligence acts by invoking those declared actions and nothing else.
Every action their machine can perform, with its parameters and limits, written as a data file. They build the mechanism however they like.
It reads that declaration, works out which actions serve what the owner asked for, and invokes them.
An action that was not built and declared cannot be taken. The declared list is the boundary of what can happen.
This is the same mechanism by which language models already operate software tools, applied to a physical machine. The difference is that the action list on an appliance is short and every entry has declared limits, which is what makes the behaviour bounded and testable.
The intelligence may decide freely. It may act only through declared actions, and every action is checked at two levels.
Extraction quality depends on grind size, dose, water temperature, pressure and time, and these variables interact. Owners converge on settings by trial and error, typically 5 to 10 attempts for each new coffee. Bean properties change with age, so the settings need correcting again. The machine measures none of this and remembers none of it.
Convergence in 2 to 3 cycles in place of 5 to 10, on every bag of coffee.
The system also identifies channeling from the flow data and attributes it to preparation rather than to grind size. That distinction matters, because telling someone to grind finer when the puck is channeling makes the next cup worse.
Integration is defined by ADI-P, a published contract covering the capability declaration, the safety envelope and the execution model. The scope of work on the manufacturer's side is small.
One declaring the available actions and their limits. One describing how the machine responds. Neither requires programming.
Implemented in the manufacturer's existing firmware, in their own language and on their own schedule. Usually C, and usually code they already have.
Anything they invent works the day they declare it. No reasoning, no models and no domain knowledge are implemented on their side.
The protocol never limits the appliance. A manufacturer may declare any functionality it can build, including functionality the specification never anticipated. No part of adding new capability depends on a release from Street AI, so a manufacturer's product timeline is never gated on ours.
Espresso is the first implementation. Moving to a further domain changes three components, and the remainder is reused without modification.
Candidate domains include ovens, laundry, dishwashers, HVAC, controlled-environment agriculture, aquaria, additive manufacturing and laboratory equipment.
For manufacturer integration, partnership or investment enquiries, get in touch.