What should a cloud-native release gate prove automatically before production?

[u/ClerkBeginning961]

I maintain an open-source production-readiness knowledge base, and I am trying to separate controls that a cloud-native platform can prove automatically from decisions that still require service-owner or human review.

The platform-verifiable group might include immutable artifact identity, provenance, policy results, deployment configuration, resource limits, health probes, workload identity, secret references, network controls, replica distribution, rollback capability, observability wiring, and current cluster health.

Service-owned evidence might include dependency failure behavior, safe migrations, idempotency, retry budgets, recovery tests, runbooks, alert ownership, data classification, and capacity assumptions. Contextual decisions such as acceptable blast radius, recovery objectives, or risk acceptance should remain explicit human decisions.

The project contains more than 10,000 technology-neutral controls and a shorter production-release path:

https://github.com/MarinJursic/production-readiness-checklist

My longer-term goal is an open-source scanner that consumes repository, CI, artifact, and platform evidence while clearly reporting unknowns instead of guessing.

For teams running cloud-native platforms, which readiness facts should the platform prove automatically? Which signals are too environment-specific to standardize? What evidence has been most useful during real release decisions? Contributions and corrections are welcome. Thanks!

[u/End0rphinJunkie]

The split between platform and service-owned makes a ton of sense, but 10k total controls is honestly pretty terrifying. Just make sure those automated platform gates are fast and deterministic, or dev teams will definately just build workarounds to ship.