A fast model decides, Claude explains
Our MCP examples show Claude investigating recordings: finding when a bearing started to change, or where an earthquake signal appeared before. That is slow, careful work, minutes per question. A plant also needs decisions that are fast and cheap: after every part, every cut, every alarm. Psychology calls the two modes System 2 and System 1.
TypeSafe AI recently released Jev, which it calls a System One model. It does not chat. It takes a block of state and a few typed questions, and answers with a choice, a score or a probability in a fraction of a second, for a fraction of a cent. It also never says why, and it does not read waveforms. That is exactly the gap MorletDB can fill.
The split
- MorletDB is the memory. It keeps every sample losslessly, with context: which program, tool, material, part.
- System 1 decides from a compact decision state MorletDB builds for a segment: how each value deviates from earlier segments with the same context, a summary score, and the nearest earlier cases with their labels. No waveform, no part number.
- The decision is logged on the recordings it is about, with the model, the probability, the threshold and the exact state.
- System 2 explains later, over MCP, from the same recordings.
MorletDB never sits in a control or safety loop; the PLC and the drive own everything below a millisecond. This is for decisions per part or per event, with seconds to spare.
Does a general model decide well from that state?
We tested it before building anything on top (study J1, protocol frozen before the first call). The data is NASA's milling set: 64 cuts over the lives of five sets of cutting inserts, the replaceable cutting edges of the milling tool. In 33 cuts the inserts were worn past 0.3 mm, the usual point to replace them. Jev got each cut's decision state, 48 deviations from earlier cuts of the same setting with a sharp insert, and one question: should the insert be replaced? No examples, no training.
| Score | AUROC, worn insert |
|---|---|
| Score built for the task (our earlier study C1) | 0.966 |
| Jev, zero-shot from the decision state | 0.948 |
| Time in use | 0.909 |
- Passed the frozen bar (at least 0.90, at most 0.05 below the purpose-built score), but the interval is wide: −0.08 to +0.04 against that score. 64 cuts show that Jev comes close, not that it is as good.
- Reliable: 192 calls, no HTTP or schema error; three calls per cut differed by 0.012 on average.
- Poorly calibrated: every probability fell between 0.3 and 0.8. It ranks well, but the threshold has to be set on known cases (about 0.6 here, not 0.5).
- Fast and cheap: 245 ms per call at the median, plus 0.4 s to build the state (0.13 s since we made the state cheaper); USD 0.03 for the whole study.
The point is not Jev. The state carries the information: a general model with no examples gets close to a score designed for the job, without seeing a waveform. The state is model-neutral, so an on-premises model can take Jev's place, which matters on shop floors that allow no cloud calls.
Follow-up: unseen inserts, a local model, four examples
J1 left three questions a real deployment has to answer. In study J2 (frozen before any analysis), every decision was tested on an insert the method had not been tuned on: whatever was fitted came from the other four inserts.
| Method | AUROC | Decisions on unseen inserts (balanced accuracy) |
|---|---|---|
| Jev, no examples | 0.948 | 0.826 |
| Jev with four labelled example cuts | 0.977 | 0.859 |
| Local logistic regression, no cloud | 0.969 | 0.904 |
| Score built for the task | 0.966 | 0.859 |
| Time in use | 0.909 | 0.795 |
- The threshold carries over. Set on four inserts, it worked on the fifth, and it barely moved between rounds (0.60 to 0.63).
- No cloud needed. A plain logistic regression on the same decision state made the best decisions on unseen inserts and was by far the best calibrated. Its lead over Jev is not significant.
- Examples help Jev, narrowly. Four labelled cuts from other inserts in the state lifted it above the purpose-built score, and made a plain 0.5 threshold usable (balanced accuracy 0.855 instead of 0.677). The improvement only just cleared the frozen rule.
So the comparison with the same context is what carries the decision. Any model can use it, a cloud model or a few lines of code on the machine.
Then Claude explained a decision
In the demo, Jev decided cut by cut over one insert's life. It said continue for cuts 1 to 4 and replace from cut 5 on, at a probability of exactly 0.60, the threshold. The measured wear at cut 5 was 0.25 mm, so by the 0.3 mm rule that was one cut early.
We asked Claude, with only MorletDB's read-only tools, to explain that first replace decision. One unattended run, 26 tool calls, 88 seconds. It found:
- The loudest number was weak evidence. The state's largest deviation, spindle-vibration kurtosis 38 times the history, came from a half-second transient, compared with only three earlier cuts. A similar spike at cut 2 had not triggered anything.
- The real wear sign was elsewhere. Spindle-motor current rose every cut, 43% from cut 1 to cut 5, as a blunting insert needs more force.
- A judgement, with its own caveat. Comparing with an earlier insert of the same setting, it judged the decision justified. That comparison rested on a label meaning "no longer sharp" (wear above 0.2 mm), not the 0.3 mm limit, and Claude said itself that the analogy was not ground truth.
So the fast model was roughly right, possibly for a fragile reason, and the explanation found both the stronger evidence and a weakness in our decision state: three history cuts inflate any one-off transient. A minimum history size is now an open point.
What this is, and what not
- One machine, one task, 64 cuts, a public baseline. Replayed recordings, no machine was controlled.
- Jev is a cloud service in early access, and its speed claims are the company's. We measured ours from one Mac.
- What improves the decisions is the context, not a clever model. Compared with earlier cuts of the same setting, wear stood out far more clearly than against all history (C1: ρ 0.91 against 0.60). Every model we put on that state ranked worn inserts at an AUROC of 0.95 to 0.98, above time in use (0.91), and in the follow-up study J2 a plain local logistic regression, with no cloud, decided as well as Jev on held-out inserts. Where we tested our own signal features or own-history alarms against simple baselines elsewhere (FFT bands, an RMS alarm), they did not win.
Read it
- Study J1: protocol, raw responses, results ↗
- The demo: worker and README ↗
- Claude's full session ↗
- Study J2: held-out thresholds, a local model, labelled examples ↗
- Issue #328: decision state, log, next steps ↗
Data: NASA PCoE "3. Milling" (A. Agogino and K. Goebel), NASA Prognostics Data Repository.