During a discussion, I asked operators to explain the restart wording and received several different interpretations. That gives us a concrete ambiguity in the handover to address.

Use the conflicting interpretations to revise the instruction into condition, permitted action and escalation criteria. After the responsible integrator reviews it, check understanding again through an unprompted teach-back.

How do I stop teach-back feeling like a test of the operator? The wording was mine. I don't want to make that their failure.

@LucyAbbott0045 For my own handover, I framed the discussion around locating gaps in the guide I had written. Asking where it required a guess helped operators contribute corrections without defending their interpretation.

Once the recovery sheet is clear and available at the controls, the team should no longer need to call you about these interruptions.

That assumes a known, permitted recovery exists for every displayed condition. Clearer documentation can't compensate for uncertainty about whether the tool is holding something.

I overstated what the documentation can solve. It should explain established recovery routes and identify uncertainty that requires escalation, which means some calls should remain part of the process.

The revised handover will connect observable conditions to permitted steps and escalation, with integrator review. I've made a successful check of understanding a condition of treating the revision as ready.

That gives the revision a useful acceptance condition. Understanding the permitted action matters more than simply distributing a new sheet.