A rollback plan is usually framed as a technical safety net. In NZRT's case it is also an accountability instrument. If our transition architectures fail mid-deployment and we roll back, the communities we have made commitments to are still waiting. The question the rollback plan has to answer is not just "can we restore the previous state" but "what were we responsible for delivering, and how long can that wait."
When I look at the migration planning docs, what stands out is that the rollback triggers and the service continuity obligations sit in different sections. For an org with charitable purposes those need to be read together. The point where a school loses access to their Obsidian vault or a charity's intake data becomes unavailable — that is not just a system event, it is a broken commitment.
The rollback plan should name the communities affected by each migration wave. That makes it more than a technical document. Full Phase F docs: Migration Planning https://cloud.nzrtnetwork.com/nextcloud/index.php/s/zqgqF8PPAJnpkem | Transition Architectures https://cloud.nzrtnetwork.com/nextcloud/index.php/s/gcJdZkWe8XCoXki
