The field guide · rule 15 of 16
Ship only what was checked, and watch it run
Release exactly what was reviewed, check it after every release, keep a way back, and hear about problems before your users do.
What it means
Releasing is part of the work, not an afterthought. Ship only the version that was reviewed. Check the system's health after every release. Keep a quick way back to the last version. Set up monitoring, so you hear about problems before your customers do.
What goes wrong without it
A fix made directly on the server is overwritten by the next release, and the old bug comes back.
How I build it
- My chain-intelligence service releases only the exact version that was approved, and a person confirms each release.
- My AI agent system has quality gates that only let things stay the same or improve, and checks that what is running matches the code.
- Space.ke has a daily check that the site is up, that the live version matches the main code, and that its data is fresh.
Ask your team
- Can you release a small change and undo it the same day?
- Is what is live exactly what was reviewed?
- Would you hear about an outage before a customer tells you?
How a review checks this
A review follows one change from a developer's machine to live, and marks each step where it could go wrong unseen.
Request a reviewThe offer: Architecture review or handover checkCheck your system in one minute