A team should be able to reject a golden path before it spends a week integrating with it. That requires more than a list of supported languages and a start button. The team needs to see which operating promises it is accepting.
Take an illustrative deployment path designed for request-serving applications. A consumer wants to run a long-lived job that changes durable state. The integration might succeed while a restart leaves unfinished work that neither side knows how to recover. The mismatch belongs in the adoption decision, before a production incident forces the discussion.
For that workload, write a short agreement beside the onboarding instructions:
The platform restarts the process; the consumer determines which unfinished operations can be repeated.
Durable state must live in a supported store, with a named recovery owner.
A workload that cannot satisfy those conditions needs an explicit exception decision.
Leaving the path transfers the listed operating duties to an owner who accepts them.
Those are illustrative terms, not universal deployment requirements. Their value is that the two teams can inspect and dispute an actual commitment. “Supported” becomes a statement about behavior rather than a label attached to a successful setup.
Now read the exit section against the same workload. List the state that must move, the unfinished actions that need reconciliation, and the controls that still apply. An export file does not establish that the receiving system can interpret the state or that someone will operate it after the move.
Rehearse the uncertain part. For example, transfer a representative record with pending work and ask the receiving owner to explain its next safe action. Record what that exercise establishes and what remains untested. There is no need to maintain a second platform merely to perform this check.
An exception should preserve the reason the common path does not fit. When the platform later changes, compare its new guarantee with that requirement. A review date can start the conversation; it cannot make the workload compatible.
The useful onboarding document is therefore also an account of departure. It tells a consumer what the platform will carry, what the consumer must carry, and what changes when the relationship ends. That is the agreement to settle before adoption spreads.