A system is not operationally ready while recovery depends on an unrecorded intervention by its implementer. Before expansion, the local team should demonstrate spare handover, consistent backup restoration, clock recovery, supplier escalation and supervisor release under authorised conditions. Recovery guidance connects playbook development with testing and improvement, making the people and their instructions part of the capability being assessed.[S06] The relevant question is not whether a supplier can eventually repair the system. It is whether the assigned roles can restore the promised boundary with the resources actually available.
The spare-handover drill should begin with the approved replacement, image and configuration rather than an improvised device. The team must establish firmware and software integrity, compatible storage and interfaces, trusted credentials and a controlled transfer of source identity. NIST firmware resiliency guidance supports attention to platform protection and recovery, but it does not demonstrate that a particular spare fits or boots.[S04] The drill record should show who authorised the substitution, how the original source was prevented from duplicating authority and which checks released the replacement into service.
Backup creation likewise needs a matching restoration result. SQLite's online backup mechanism supports making a consistent backup while other database users continue, but a completed backup file does not prove a usable restore.[S17] The team should restore into the approved isolated state, check database integrity and configuration, reconcile the event and outbox ledgers, and only then request operating release. The exercise should include a backup that predates later live events, because restored replay state can otherwise create duplicates or false pending work.
Clock recovery requires the same practical treatment. Chrony documents a mechanism for compensating real-time-clock drift through rtcfile with -s, but the chosen device still needs disconnected and restart measurements to establish its behaviour.[S30] The drill should record the clock state before recovery, the approved source or manual authority used to correct it, the uncertainty attached to intervening events and the point at which remote trust can be re-established. Disabling authentication or silently rewriting event history is not an acceptable shortcut.
Supervisor drills should test interpretation as well as execution. The shift team must recognise stale data, missing sequences, an unavailable inspection input and an unreconciled manual record. It should be able to select the approved degraded state, preserve the required identifiers and explain why production is running, restricted or held. Any coaching, remote login or specialist action should appear in the evidence as assistance. Repeating a drill after coaching is useful, but the first attempt must not be erased from the learning record.
Expansion should then replicate an accepted configuration rather than improvise a new one at each line or site. The rollout pack should contain the versioned image, configuration, requirement register, test evidence, local runbook, spares list, escalation route and training record. A change in storage, firmware, network path or inspection duty triggers a dependency review and targeted repetition of the affected evidence. Technician and supervisor development belongs to the wider skills programme in wp09; this paper treats that development, spare availability and drill time as funded operating requirements, not assumed GFT capabilities.[S04][S06]
The scale decision should also define reverse motion. If the replicated system loses its required record behaviour, if the team cannot complete restoration or if assistance exceeds the accepted operating model, the programme returns to the last supported boundary. That response is not a failure of the roadmap. It is the mechanism that prevents a local defect from becoming a fleet-wide condition.