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. Asked a question about its own domain, it answers. 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 keeps what it made and what the owner said about it, so "half the sugar of last time" resolves against a real cycle.
It understands plain speech and accepts correction in ordinary language.
Asked a question, it answers from what it already knows and from what the manufacturer wrote down, and says which it drew on. Nothing is actuated.
The intelligence is bounded to one domain. It is not general intelligence.
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.
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, often over several 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.
Fewer attempts per bag, because the machine measures what it made and corrects from the measurement.
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.
The protocol and a working implementation of both halves are published under Apache 2.0. You can run the whole loop on a laptop, with no hardware, no account and no network.
git clone https://github.com/Tem-Degu/adi
cd adi/sdk
cargo build --release
cd c && make example && cd ..
cargo run -p adi-cli -- run --level d0Type cycle and the engine observes a finished extraction, judges it against the target, works out which declared action to change and by how much, checks the whole plan against the safety envelope, and sends it to a real build of the appliance library running as a separate process.
> cycle
observing an 18 s shot, described as sour
diagnosed shot_time
chose adi.espresso.grind.set_setting
sent setting = 20 Step
accepted by the appliance
explains Diagnosed shot_time and set setting to 20.The reasoning engine in Rust, and libadip for the appliance: freestanding C99, no allocation, about 12 KB of flash. They exchange real bytes on every build.
A complete appliance to copy. A manufacturer implements three platform functions and one handler.
Recorded inputs and the decisions they must produce, so an implementation can be held to the specification rather than to a reading of it.
A greenhouse profile, data only, kept to stop espresso assumptions leaking into the parts that claim to be general.
Note: The appliance library has not yet run on a microcontroller. The espresso rules have not been checked against real extractions. The programs that load speech models have been written and not yet run against real weights.
For manufacturer integration, partnership or investment enquiries, get in touch.