The Handover Documents Look Complete. Ask Someone Else to Use Them.

The folder contains an architecture diagram, environment list, credentials inventory, release runbook, and incident guide. Every item on the handover checklist is marked complete.

The incoming operator follows the deployment steps and stops at an account the company does not control. A command refers to an old service. The health check is green, but nobody outside the vendor knows which customer journey must be tested before traffic returns.

The documents existed. The operating knowledge did not transfer far enough for another person to act.

Documentation proves transfer readiness through use, not volume. Choose one representative task and ask an authorized second operator to perform it without live rescue. Every moment the vendor must explain, grant access, interpret a step, or repair the path becomes evidence of a gap.

The result is not a verdict on the whole system. It is a precise test of one capability the company needs after the vendor leaves.

Documents can be accurate at the sentence level and still fail as an operating path.

Prerequisites may be spread across private messages. Credentials may exist but belong to the vendor. A runbook may list commands without saying which environment, version, or state makes them safe. An architecture diagram may show components while omitting the provider account, data flow, or business journey needed to judge success.

The author fills those gaps automatically because the missing context lives in memory. A second operator reveals them by stopping, choosing the wrong path, or asking for help.

Counting files rewards visible completeness. The company needs usable capability: can someone else perform the work, recognize failure, and recover under the conditions the product actually has?

Choose the task before reviewing the folder. It should matter enough to test a real operating dependency and remain safe enough to perform under controlled conditions.

The task may be a repeatable build, a deployment to a representative environment, diagnosis of a seeded failure, restoration from a backup, credential rotation, or a small product change. Pick one path tied to a critical journey or transition risk.

Give the second operator the same authorized access and documents the company expects to retain. The vendor can observe silently. Intervention should occur only for safety or when the exercise is blocked.

The test asks whether the documentation, artifacts, access, and ownership work together. No single file can prove that system.

Record the start state, intended result, environment, artifact versions, accounts, and people involved. Preserve the exact document version used.

During the exercise, log every missing prerequisite, ambiguous instruction, stale command, inaccessible account, undocumented decision, unexpected dependency, and vendor intervention. Distinguish a documentation gap from a skill gap or a product defect because each needs a different response.

Verify the outcome through the customer or operating journey, not only the final command. A deployment is not complete because the process exited successfully if billing, access, data, or monitoring is wrong.

Where predictable failure is part of the task, ask the second operator to diagnose or recover. A happy path alone may leave the most important knowledge with the vendor.

Tacit knowledge hides between written steps.

The author knows which command is obsolete, which warning can be ignored, which account owns the resource, which provider takes time to converge, and which signal proves the product is healthy. The document may never state those decisions because they feel obvious to the person who wrote it.

A second operator turns that hidden context into observable friction. Each pause shows where the operating model still depends on interpretation that has not transferred.

Repairing the document is only part of the response. The gap may require company owned access, a repeatable artifact, clearer responsibility, a safer recovery path, or a product change that removes vendor only knowledge.

Select one representative task and define success, safety boundaries, and stop conditions. Confirm that the second operator is authorized and that the exercise cannot create uncontrolled customer harm.

Freeze the document set for the test. Ask the operator to narrate decisions and record where evidence is missing. Keep the vendor silent unless safety or a hard block requires intervention.

After the exercise, convert every intervention into a tracked gap with an owner and acceptance test. Repair access, artifacts, instructions, responsibility, or system behavior. Then repeat the same task with a different qualified operator where the consequence justifies it.

Accept the handover only for the capability demonstrated. Schedule other representative tests according to critical journeys, likely changes, recovery needs, and the vendor exit date.

One successful exercise does not prove that every subsystem, rare incident, future change, or specialist judgment is documented.

Some expert knowledge can remain external by design. That dependency should still have an owner, access model, response expectation, continuity plan, and evidence that the arrangement works.

A failed exercise does not always mean the document is poor. The operator may lack required skill, the product may be defective, or the chosen environment may not represent normal conditions. Classify the failure before prescribing more documentation.

Legal ownership, license transfer, privacy, security, and contractual obligations may require qualified review beyond this operational test.

Accept the handover for the tested capability when the second operator completes it with company controlled access, current artifacts, usable instructions, clear ownership, and sufficient recovery evidence.

Condition acceptance when bounded gaps have owners and repeatable tests before the vendor exit. Escalate when critical access remains with the vendor, the result cannot be verified, or predictable failure still requires live rescue.

Keep the claim narrow. A successful deployment proves one deployment path under the tested conditions. It does not prove total maintainability.

The document is not the handover. The successful second use is the evidence.