There is a lot of software now that will let a language model decide what happens to your production site. This is not that.
What the model does
Before an update is installed, its changelog is fetched and read by a model, which returns a risk score and a short recommendation. This is genuinely useful work. A version number tells you nothing; the release notes are where “rewrote the REST endpoints” or “dropped support for PHP 8.1” is actually written down, in prose, differently by every author. Reading that quickly, across a whole portfolio, every night, is a good use of a model.
What the model is not allowed to do
The recommendation is an input. The decision is made by code, against rules written down per site before the run starts:
- Never-auto. Named plugins are never installed automatically, whatever the score says.
- Risk threshold. Above the site’s threshold, an update goes to a copy of the site on our server first. The live site sees it only if it survived there.
- Minor only. Major core releases wait for a person, on sites configured that way.
A confident, wrong model cannot push a major update onto a client’s site, because nothing in that code path asks it for permission. If the model is unreachable entirely, the run still completes — conservatively.
Rolling back is decided the same way
Whether an update is reverted comes from three independent signals: the HTTP health check, the test results, and the visual comparison. Any one of them saying “broken” is enough. No model is consulted, because this is the decision that must be explainable a week later, to a client, in a sentence.
Judgement where it helps, rules where it matters
Models are good at reading prose and bad at being accountable. Rules are the opposite: rigid, but you can read them, argue with them, and change them — and they behave the same on the four hundredth site as on the first. Putting the model on the advisory side of that line is not caution for its own sake. It is what makes the system safe to run unattended.
