Certify Production Runtime Health with Evidence-Backed Verdicts

Produces an evidence-backed release verdict that keeps code quality, CI success, deployment success, and live runtime health as separate, independently-tested gates - so a green pipeline or a successful deploy event is never treated as proof a service is actually usable in its target environment. It works through eight gates in order: pin the immutable source revision and artifact (a branch name or "latest deployment" label doesn't count), verify source validation and CI on that exact pinned revision, verify the deployment identity (that the target environment actually reports the expected revision or artifact digest), verify database migration state via a read-only schema-version query, probe liveness and readiness separately (liveness proves the process responds, readiness proves it can handle traffic with dependencies available), exercise the smallest authorized smoke suite covering the agreed critical user journeys, check operational signals in the deployment window for crash loops, unhandled exceptions, or elevated error rates, and finally publish the evidence matrix and one overall verdict.

Each gate is scored PASS (fresh evidence satisfies the criterion), FAIL (fresh evidence disproves it), BLOCKED (couldn't be tested - access, tooling, or a dependency was unavailable), or NOT APPLICABLE (deliberately excluded, with a written reason) - BLOCKED is explicitly not treated as PASS. The overall certification is GREEN only when every required gate passes; any required failure makes it RED; any required BLOCKED gate with no failure makes it BLOCKED.

Use it before declaring a release, environment, or migration production-ready; after a deployment when CI is green but runtime health is unknown or failing; during release audits that need a concise PASS/FAIL/BLOCKED decision with reproducible evidence; or when handing a deployed service from engineering to operations or a client.

It is not a substitute for feature acceptance, security review, load testing, disaster-recovery exercises, or regulatory approval. It stays read-only unless a separate change request authorizes remediation, never applies, rolls back, or repairs migrations without separate authorization and a recovery plan, and stops rather than probing an unrelated environment, exposing credentials, or modifying production data merely to obtain a passing result.

Inputs agreed before testing: the exact source revision, repository, and target environment; the deployment identifier and expected artifact/image digest; health and readiness endpoints with expected success semantics; the migration mechanism and expected schema version; the critical user journeys or routes to probe; and the authorized, non-destructive probes and credential boundaries. If the target, authorization, or success criteria are ambiguous, it stops and asks rather than guessing.

Output is the certification report itself: environment, source revision, deployment/artifact identifier, and observation timestamp, followed by a PASS/FAIL/BLOCKED/NOT APPLICABLE line for each of the eight gates, the overall GREEN/RED/BLOCKED verdict, the supporting evidence (commands, run IDs, timestamps, bounded results with secrets and personal data redacted), and any unresolved risks stated explicitly rather than omitted.

Related to @verification-before-completion (verifies a completion claim has fresh supporting evidence generally - this skill supplies the production-specific gate model and verdict) and @deployment-procedures (used to execute the deployment itself; this skill certifies the runtime afterward).

Engineering and operations teams who need a release or environment certified as actually working in production - not just built and deployed - with a reproducible, evidence-backed verdict that survives handoff to another engineer or to a client.