A software change in a growing room needs acceptance and a way back
A software change in a controlled growing room is a production decision, not an IT task. When a batch is in the room, the climate running through it must not drift because of a change nobody accepted — and if the change misbehaves, someone must be able to put the room back to a known working state. Specify both before the change lands: who accepts it, and how the room comes back.
Name the acceptor before anything is built
Keep proposal, test evidence, review, acceptance and authorised deployment as separate stages. Develop and test the candidate where a failure cannot disturb a running batch. The acceptor is the technical operating owner of the installation: the person accountable for that room's climate and equipment, not the person who wrote the code. For a change that reaches climate control or equipment, the acceptor must be qualified for the system concerned; no general checklist substitutes for that competence.
Record the working version first
Before anything changes, record which software and configuration were effective, what will change, and which evidence will confirm the new state. Keep the recovery material available and compatible with what is actually deployed.
The industry mechanism behind this is the fail-safe OTA pattern: the update is written to an inactive partition while the active system keeps running, the device switches over on success, and it falls back to the previous partition on failure (Mender). Confirmation criteria — startup, application execution, connectivity — should be checked before an update is confirmed successful, otherwise the device rolls back.
Decide what the batch stage can tolerate
Timing is part of the decision. A change during a stable stretch of a long batch is a different proposition from one during a stage transition, when the room is most sensitive and attention is already committed elsewhere. Name who decides the timing, and what would make them postpone it.
Test recovery, not only installation
Agree in advance how a failed deployment is detected, who may pause or reverse it, and how the recovered room is verified: the room's own readings, the batch record and the alarm path. Fleet update tooling can automate part of this — an automatic rollback policy triggers rollback to a named previous update once failed devices pass a set threshold, alongside scheduled start times and retries (Microsoft Learn). Managed device-update platforms advertise resilient A/B updates for seamless rollback, with automatic rollback to a defined fallback version for devices meeting rollback criteria (Microsoft Learn).
A rollback command completing is still not a verified recovered room. Someone accepts the recovery with the same authority that accepted the change. If data or configuration changes make reversal harder, keep that explicit in the plan. What acceptance must establish before a system first goes live is a related, separate question (bench test vs site commissioning).
The change packet
Specify, in one place: the rooms affected, the stage the batch is in, the acceptor, the test evidence, the recovery steps and the signal that stops the change. That packet makes the decision visible without replaying the meeting that produced it — and it turns "we updated the controller" into a record you can audit batch against batch.
How this looks in MIND
MIND works the same way: software changes are tested and accepted before reaching production (MIND platform). The MIND Agentic Server is configured around an existing MIND installation or a growing system we integrate with you in a scoped project. If you are specifying who accepts software changes in your growing rooms and how a room returns to a known state, describe your installation to us and we can discuss what that specification would need to cover. Contact Manna Insect.
Prepared with AI assistance for Manna Insect Oy.