A system has not been operationally accepted until someone else can use its maintained material to explain it and safely perform ordinary work.
I once reached the point in a handoff rehearsal where everything on the page was accurate and the other operator still couldn't begin. The service address was there. The routine procedure was there. The rollback notes were there. None of it answered the first question that mattered: which access belonged to the role, and who could grant it?
That pause changed the review. We weren't proofreading documentation anymore. We were testing whether the system could leave the orbit of the person who built it. In this case, that person was me, along with all the context I'd forgotten I was carrying.
A conventional handoff often starts with a tour. I share a screen, explain the components, perform the common action, and narrate the strange parts from memory. It feels efficient because the route through the system is smooth. It's also weak evidence. The recipient is following my path while I silently supply missing context, choose the right credential, avoid the stale link, and recognize when an output looks wrong.
For the rehearsal, the maintained material had to lead. I could answer questions about intent, but I couldn't operate the controls on someone else’s behalf. The other operator had to identify what the system did, where its source records lived, how to reach the operational surface, and what routine action was safe to attempt. If a sentence only made sense after I explained it aloud, it wasn't finished.
The first gap was access ownership. “Sign in with the operations account” sounds clear to the author who already has it. It doesn't say where that account is administered, whether it's personal or role-based, which permissions are actually required, or whom to contact when access fails. A procedure that begins after authentication has skipped part of the procedure.
We corrected the material around responsibility rather than adding a pile of credential trivia. The handoff identified the owner of access, the role needed for the routine task, and the route for resolving a denial. Secrets didn't belong in the document. The ownership model did.
Then the operator explained the system back to me. This works surprisingly well because recognition can masquerade as understanding. A diagram looks familiar after a walkthrough. Explaining the flow without my narration exposes whether the boundaries are actually clear: which record is authoritative, which surface coordinates work, which component performs it, and where evidence of completion appears.
It wasn't a memory contest. I was listening for operational consequences. If the coordinating view was unavailable, could work still be found in the source record? If a displayed status disagreed with delivered behavior, which evidence won? If the routine action stalled, who owned the next decision? Those answers showed whether the architecture survived outside my head.
Next came the ordinary action. We chose something representative and reversible, the kind of task a future operator would be expected to perform without assembling a committee. The material had to establish the starting condition, identify the correct control, describe the expected evidence, and name the point at which the operator should stop.
The stop point mattered as much as the happy path. Runbooks often become dangerously fluent near the end: click this, run that, confirm success. Real operations includes ambiguous results. The rehearsal had to tell the operator what counted as completion and what required escalation. Otherwise we'd written choreography, not guidance.
Rollback produced a different kind of discussion. It's easy to write “roll back if needed.” The useful questions are concrete. Who's allowed to make that decision? What state must be preserved before reversal? Which dependency may have changed since the original action? How will the operator show that the rollback restored service rather than merely reversing a configuration value?
We didn't manufacture a failure to make the rehearsal dramatic. We walked the rollback path far enough to establish authority, prerequisites, and proof. That was enough to expose assumptions hiding in the forward procedure.
By the end, the other operator could describe the system in their own words, obtain the right access through its owner, perform the routine action from the maintained material, recognize the resulting evidence, and explain how rollback would be decided and checked. I had spoken less than I would during a polished demo, which made the result much more credible.
This kind of rehearsal changes architecture decisions upstream. A component with unclear ownership becomes visible before it is buried in prose. A control surface that requires the builder’s personal account becomes an explicit liability. A source-of-truth relationship that takes ten minutes of verbal explanation is probably not represented well enough in the system.
Documentation still matters, but page count is a poor proxy for transfer. So is a recorded walkthrough that preserves the builder’s perfect route forever. I need another operator who can act without borrowing my memory.
The corrected handoff package got shorter in some places and more precise in others. More importantly, it began before the login screen and continued past the button press. We accepted the handoff when the other operator could get access, do the routine work, read the evidence, know when to escalate, and explain how we'd get back if the change went wrong.