Where Tamoz fits: four use cases, and how far each one is proven
Tamoz fits where equipment streams sensor data, or can with added sensors; a fault has a deadline and a known repair; and a wrong action costs more than a late one. Manufacturing is full of these. Here are four, and exactly how far each one has been shown. We would rather lose a pilot to an honest label than win one with a vague claim.
How to read the labels
Every use case carries one or two evidence labels. Each label is a word, not only a colour.
Demonstrated in simulation ran in the simulator, with sealed ground truthDemonstrated on a real bench ran on real hardware, small scale, without an independent measurementPlausible next world or spec material exists, but no run yet
What makes a good fit
- The sensors already stream, or a gateway can be added.
- A fault has a deadline and a known repair.
- The repair can start as a low-risk, reversible action (a ticket, a work order, a bounded setpoint request), and a person approves anything riskier.
- A false alarm has a cost worth measuring.
- A named person can approve rules.
Poor fit: hard real-time control loops, and anything that is itself a safety function. Tamoz sits above the control layer, and the learned-rule compiler refuses to recommend actions at risk class R3 or higher.
Demonstrated in simulation
1. Pumps and motors: catching a fault before it stops the line
- The problem
- Pumps and motors drift from their own normal in many ways: bearing wear, misalignment, a drifting sensor. Alarms fire late or not at all. Someone has to work out which repair to book before the deadline, and the lesson is rarely written down.
- What Tamoz does
- It notices when a machine drifts from its own 24-hour normal, works out the likely fault, and proposes the repair. Policy checks the proposal, and the outcome is checked for real recovery. After three verified repairs of the same kind, it drafts a rule for a person to approve. How rules are learned.
- What exists
- A simulated eight-pump trial with a real model. A learned misalignment rule made 5 of 5 correct, on-time decisions without calling the model, and took no false action. Limit: one of three fault types earned a rule, and sensor drift was mistaken for bearing wear.
- A pilot would measure
- Time from first drift to a booked work order. How many faults got the right repair booked before their deadline. False actions on healthy machines, with a target of zero. Model calls per fault. Whether each fault type earned a rule. How long approvers spend on each proposal.
Plausible next
2. Compressed air and utilities: telling look-alike faults apart
- The problem
- Compressed air, chilled water and power have faults that look alike. Pressure falls: is it a leak, or a worn compressor? Chilled water runs warm: is it a failing fan, or just a hot day? A wrong guess sends your team to the wrong place.
- What Tamoz would do
- The same as for pumps and motors: notice the change, work out the likely cause, and propose what to check. The value here is in telling look-alikes apart, and in not acting on the wrong one.
- What exists
- The simulator can already model these plants: a chiller plant, and a factory-utilities plant with 23 instances across five areas, shown below. Limit: Tamoz hasn't run on either, so this stays “plausible next”.
- A pilot would measure
- The same as for pumps and motors, plus how often one fault was mistaken for another.
Demonstrated on a real benchDemonstrated in simulation
3. Cold rooms and thermal zones: the use case that has run on real hardware
- The problem
- A cold room drifts warm at night. It could be the door, the weather, or a failing sensor, and a fan or cooler must never run without limits.
- What Tamoz does
- It reads temperature, humidity and, where available, ambient readings, and doesn't overreact to a rise that simply tracks the room around it. It proposes a mode, never a power setting. Policy and the device's firmware set the power and run time. If a sensor goes silent, Tamoz becomes less certain and risky actions are refused.
- What exists
- A small bench with a real board, a temperature sensor and a fan. The full route, from Tamoz's proposal to the board, has run in three recorded sessions with a person approving each command. Simulated examples cover a quiet night, a rise that tracks ambient, bad readings and a reboot. See the bench. Limit: confirmation came from the board's own report. With the motor disconnected, it still reported success, so no physical effect has been measured.
- A pilot would measure
- How long it takes to detect a sustained rise. How long a response takes after approval. False responses to rises that track ambient. What happens when a sensor goes silent. Independent feedback, such as an airflow or temperature reading, so that “commanded” isn't mistaken for “working”.
Demonstrated in simulation (scripted reasoner)
4. Aquaculture ponds: a fault with a hard physical deadline
- The problem
- Dissolved oxygen falls through the night, and low oxygen can kill stock quickly. The chain from reading to action has to finish inside a physical window, and the world won't wait for it.
- What Tamoz does
- It watches the ponds, tells a dip after feeding from a real fall, waits for a signed human approval before an emergency water exchange, refuses to act when a probe goes silent, and walks back an intervention after a late correction.
- What exists
- A simulated site with eight shrimp ponds, used in one of the simulator rounds. A quiet baseline started no reasoning, a silent probe failed closed, the emergency exchange waited for approval, and a second pond recalled what happened to the first. Limit: the reasoning in these runs was scripted, so this shows the machinery, not a model's judgment. Aquaculture hasn't run with a real model.
- A pilot would measure
- Reading-to-action time against the physical window. Whether approvals arrive in time. False interventions. What happens when a sensor goes silent.
Trying it on your equipment
A first pilot starts read-only, on one problem, with a result you can measure. The pilot page sets out the steps, what you'd come away with, and what we'd need from you.
Before anything connects to your equipment, we can replay a sample of your sensor history and build a simulated copy of your device, so you can see how it behaves first.
Where it doesn't fit
Tamoz isn't a safety function or a hard real-time controller, and it isn't certified. Nothing here is a savings claim. These results come from simulation or a small bench, and the evidence is on the overview and in the technical deep dive.
Think one of these fits what you run? Tell us what you operate and what a missed fault costs you, and we'll tell you honestly whether it's a fit.
Discuss your operation