morletdb

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 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.

ScoreAUROC, worn insert
Score built for the task (our earlier study C1)0.966
Jev, zero-shot from the decision state0.948
Time in use0.909

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.

MethodAUROCDecisions on unseen inserts (balanced accuracy)
Jev, no examples0.9480.826
Jev with four labelled example cuts0.9770.859
Local logistic regression, no cloud0.9690.904
Score built for the task0.9660.859
Time in use0.9090.795

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:

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

Read it

Data: NASA PCoE "3. Milling" (A. Agogino and K. Goebel), NASA Prognostics Data Repository.