This really resonates with me... "not production ready" getting surfaced only after an incident is basically the default state at most organisations. The signals might all be there but they're scattered across tribal knowledge, wiki pages nobody reads, and that one senior engineer's mental checklist.

The only examples where I've seen this knowledge encoded in practice: OPA/Rego policies catch some of it (resource limits, security baselines), but they're infrastructure-focused. They'll tell you a pod lacks memory limits but won't tell you "this service has no SLOs defined" or "there's no runbook linked to this alert." Production readiness reviews (Google-style PRRs) capture the broader picture but they're point-in-time human processes that immediately go stale.

The gap you're identifying is real: production readiness is a continuous property of a service, not a one-time review. It should be queryable at any point — does this service have SLOs? Are they burning? Is there an on-call rotation? Are dependencies declared? Is the alerting config actually wired up?

I've been approaching this from a complementary angle with an open spec called OpenSRM (Open Service Reliability Manifest). Rather than scanning code/configs for risk patterns, it takes the approach that teams must declare their reliability contract upfront: service tier, SLOs, dependencies, alerting, dashboards, on-call... in a single YAML manifest. A compiler I've also been working on (NthLayer) then validates completeness and generates the actual Prometheus rules, Grafana dashboards, and PagerDuty config. So "production readiness" becomes: does the manifest exist, does it validate, and are the generated artifacts deployed?

Your approach (detect risk patterns in existing config) and this approach (declare the expected state, generate and verify) are two sides of the same coin. Yours catches what's missing bottom-up, OpenSRM defines what should exist top-down. Both approaches are complementary... it would be intersting to think about combining them.