Put the unsupported workload beside the onboarding button. A team should learn that its recovery requirement falls outside a golden path before it has integrated the path into its service.
The platform's boundary needs to be specific enough to change that decision. An approved-language list will not tell a consumer whether a half-completed job can restart, who recovers it, or which business effects may be repeated.
State the workload the path was designed for
Consider a hypothetical deployment path designed for request-serving applications. Its defaults may be sensible for services that start quickly, respond to health checks, and keep durable state elsewhere. A long-running batch workload may need different completion and recovery behavior.
The mismatch does not establish that either design is poor. It establishes that the platform needs a visible boundary. Without one, a team can discover the difference only after adopting the path and attempting to force its workload through it.
Describe the assumptions in language consumers can use. “Supported workload” should explain the relevant behavior, not merely list an approved framework. The platform should distinguish an unsupported preference from an unmet requirement that changes the outcome or the risk.
A preference for a familiar tool may be insufficient reason to leave. A recovery requirement the path cannot satisfy deserves a different discussion. The evidence needed for each decision should be proportionate to the consequence.
For the illustrative batch workload, the consumer guide could carry a short suitability card:
| Requirement | What this route promises | Decision when it does not fit |
|---|---|---|
| Work survives a worker restart | State outside the worker remains available; the consumer must define safe resumption | Review the state and recovery contract before adoption |
| A completed business action is not repeated | No promise follows merely from restarting the process | Name the owner of duplicate-action prevention |
| Someone resolves an incomplete job | Identify the platform duty and the consumer duty separately | Assign the unresolved duty or use another route |
These are questions to settle for the actual design, not claims that a deployment platform necessarily offers these guarantees. The card makes the adoption decision inspectable before it becomes a support dispute.
Make guarantees conditional where they are conditional
A promise of automated recovery is incomplete if it applies only to stateless workloads. A promise of supported migration needs to state which versions and interfaces remain inside that support. Consumers should not have to infer these limits from an incident.
Place important limits beside the guarantee. Separate what the platform will do from what the consumer must provide. In the hypothetical batch case, the consumer may remain responsible for deciding whether partially completed business work can be safely repeated.
The CNCF Platforms White Paper defines a platform around user needs and consistent experiences. It does not require one implementation for every use. The defined-edge test is an owned conceptual application of that distinction.
Give a mismatch a destination
Documentation of a limit helps only if the organization can act on it. A team discovering an unmet requirement needs a route to one of several decisions: use the path as designed, extend it, accept a bounded exception, or place the capability elsewhere.
The route needs an owner who can resolve the choice. An open discussion channel may collect context, but it should not leave accountability dependent on which engineer happens to answer.
For an exception, identify the work that transfers. That may include deployment operations, incident response, upgrade support, or retirement. Common security and identity controls can remain mandatory. Leaving one implementation should not silently remove unrelated obligations.
A clear transfer protects the platform too. It prevents the team from claiming to support every workload while receiving unfunded responsibility for variations it does not control.
A visible edge does not invite unlimited variation
The concern about fragmentation is legitimate. Supporting every difference can multiply testing, documentation, and specialist knowledge. A platform may need to reject a request when the standard already satisfies the material requirement or when the exceptional path cannot be operated responsibly.
Make that rejection explainable. State the requirement examined and the evidence that the common route meets it. A decision based only on adoption targets tells the consumer little about whether their workload will succeed.
Repeated mismatches should also change the product discussion. If several teams bring the same material need, review the platform boundary before approving another private workaround. The right answer may be a second supported path with a narrower promise.
Choose one golden path and write its most consequential assumption at the top of the consumer guide. Follow it with the relevant guarantee, the consumer responsibility, and the destination for a mismatch. That small change makes adoption a more informed commitment and gives the platform a clearer basis for saying both yes and no.