SYSE.29:11 - SoTA-Echoing

For “When can an old platform capability be removed?”, adapt the outcome-driven evolution and feature-removal line in the CNCF Platform Engineering Maturity Model. Sections 4.1–4.5 turn that orientation into an affected-use transition. The serious defaults are date-only removal and indefinite coexistence; each hides a different cost. A maturity label settles neither.

The Kubernetes deprecation policy is a concrete provider-policy comparator, not a universal timetable. Its distinction between a served API version, compatibility and the ability to interpret stored data changes the retirement question in section 4.5. Adopt that distinction for the actual consumer; do not copy Kubernetes deadlines or assume its guarantees from an internal version label. The preview example exposes the corresponding recovery/retained-state failure.

Reopen the transition when an overlooked consumer appears, a receiving result fails, new state crosses the return boundary, or the provider’s support/withdrawal conditions change. These software sources do not qualify physical transfer or restoration.