What a model would do here — and what it would not be allowed to

The view

Shown on the band saw in cutting, because that is where the most interesting case lies: this machine has no manipulated variable. A model cannot adjust anything here — it can only know earlier what will happen anyway.

Where the model docks on

The model replaces nothing. It sits alongside the rule set and produces the same kind of finding — everything after that stays as it is. The socket for it is built; what was missing is the plug.

That is the real statement: the value of the existing architecture is that it does not have to take a learning component on trust. Forecast, gate, approval, trial run, watchdog and ledger are already there — and they do not ask where a proposal comes from. As of this version that is no longer only stated here but sits in loop/adapter.py.

1. M

   Monitor

   unchanged

   Reads the AAS twin, time-weighted. The same source from which the model would also draw its features.

2. +

   Adapter

   built, empty

   The docking point exists: an adapter is anything that masters beurteile(Beobachtung, Schwellen) and returns a finding or None. A model would be a service that serves exactly that — it writes nowhere and calls nothing. It is plugged in at loop/analyze.py, where the rule set is already chosen today.

3. A

   Assess and plan

   unchanged

   The finding becomes a limited proposal with a predicted effect. Whether the finding came from a rule or a model changes nothing about that.

4. 1

   The gate

   unchanged

   Limits, step size, minimum confidence, observation period, spacing, repeat lockout. A YAML file that also applies to model proposals.

5. 2

   The human

   unchanged

   Approval required. A model does not shift this threshold — it would first have to earn it over weeks of confirmed forecasts, just as the rules did.

6. 3

   Trial run and watchdog

   unchanged

   The measured effect decides, not the predicted one. Whatever delivers less than announced goes back — even if a model proposed it.

7. K

   Ledger

   one more field

   Every proposal carries its provenance in the evidence: rule or the adapter’s name@version. It is written by the loop, not by the adapter — whoever may write down their own provenance will at some point write down the wrong one. That is the only change to the chain of evidence, and it is the reason why it can later be said which version was responsible for what.

# loop/adapter.py — what an adapter must be able to do
class Befundgeber(Protocol):
    name: str
    fassung: str
    def beurteile(b, schwellen) -> Befund | None: ...

# loop/analyze.py — the order is the whole promise
befund = adapter.beurteile(b, schwellen)   # if it returns None or fails:
befund = regelwerk.beurteile(b, schwellen) # the rule answers

# plug in without changing a line
ZENFACTORY_ADAPTER=LINIE_A=pruefstecker

# and prove that the socket holds
.venv/bin/python -m pytest tests/test_loop.py -k adapter   9 passed

What the model really says today

The model has existed since 24 August 2026. It is not a neural network, it needs no GPU and not a single additional library — it is a straight line through a point cloud, calculated in pure Python.

# .venv/bin/python ml/train_standzeit.py --tage 2
Model       remaining cuts = 1286.9 - 78.6 · current[A]
Learned on  89 blades, 4,854 examples
Verified on 30 held-out blades, 1,647 examples
Error       0.9 cuts on average (mean alone: 96.2)
Resolution  7.9 cuts per 0.1 A step — the limit of the line

# .venv/bin/python ml/train_standzeit.py --jetzt
20:59:26  Motor current 13.3 A
Remaining life  241 cuts
Model           zf-standzeit@0.1.0

A classification nobody else supplies: The 0.9 cuts apply to a clean signal. On the replica plant the current follows the wear exactly — without scatter from material, feed or temperature. How much of that is left on a machine with real noise, we have measured rather than left open:

What remains when the signal scatters

The saw can put scatter on the motor current — two thirds as a material batch that carries over sixty cuts, one third as measurement noise. Out of the box this is switched off, so that the other numbers on these pages match the pure formula. When it is switched on, the same model is retrained at each level and verified on held-out blades:

All in cuts, 28 blade lives per level, current rounded to 0.1 A. Recompute with scripts/sweep_streuung.py.

Five percent scatter is not a large number on a band saw — a different material batch shifts the current slightly, by a third of an ampere. There the forecast lies at ±30 cuts instead of ±1. That is still three times better than the mean, but it is no longer an appointment you plan to the day — it is a shift. This number belongs in a quotation, not the 0.9.

Where the data would come from

For a tool-life forecast the historian is enough: wear curves arise by themselves, every blade change is an example with a known outcome. For a model that proposes manipulated variables it looks different. Its labels would be the verdicts from the evidence ledger — and so far there are too few.

The status in three sentences. The docking point is built and secured: contract, fallback to the rule, provenance in the ledger, plus tests for failure, silence and wrong answers. The model is trained and captures the saw’s physics; it delivers findings for maintenance and adjusts nothing because this machine has no manipulated variable. It learned on the replica plant — when used on your machine it is retrained on your data, and the measurement for that runs exactly as it does here.