Production Runtime Certification

Overview

Produce an evidence-backed release verdict that distinguishes code quality, CI success, deployment success, and live runtime health. The skill prevents a green pipeline or successful deploy event from being treated as proof that a service is usable in its target environment.

When to Use This Skill

• 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 require a concise PASS, FAIL, or BLOCKED decision with reproducible evidence.
• When handing a deployed service from engineering to operations or a client.

Do not use this skill as a substitute for feature acceptance, security review, load testing, disaster-recovery exercises, or regulatory approval.

Certification Contract

Agree on these inputs before testing:

• exact source revision, repository, and target environment;
• deployment identifier and expected artifact or image digest when available;
• health and readiness endpoints plus expected success semantics;
• migration mechanism and expected schema version;
• critical user journeys or routes;
• authorized, non-destructive probes and credential boundaries.

If the target, authorization, or success criteria are ambiguous, stop and request clarification. Never probe an unrelated environment, expose credentials in output, or modify production data merely to obtain a passing result.

Evidence Model

Record every gate as one of:

• PASS — fresh evidence satisfies the agreed criterion.
• FAIL — fresh evidence disproves the criterion.
• BLOCKED — the gate could not be tested because access, tooling, configuration, or an upstream dependency is unavailable.
• NOT APPLICABLE — the gate is deliberately excluded with a written reason.

BLOCKED is not PASS. An overall certification can be GREEN only when every required gate passes. Any required failure produces RED; any required blocked gate with no failure produces BLOCKED.

Workflow

1. Pin the Subject

Capture the immutable source revision and intended runtime artifact. Confirm that the deployed artifact maps to that revision. A branch name, local working tree, or “latest deployment” label is not immutable evidence.

2. Verify Source and CI

Run the repository's current validation and test commands on the pinned revision. Inspect the required CI jobs for the same revision, including conclusion and timestamp. Do not infer full CI success from one job or from an older run.

3. Verify Deployment Identity

Confirm that the target environment reports the expected deployment, revision, or artifact digest. Record the environment and deployment identifiers without copying secrets or sensitive configuration values.

4. Verify Database State

Use the application's supported migration status or a read-only schema-version query. Confirm migrations completed on the target database and that the application is not running against an unexpected database or schema.

Do not apply, roll back, repair, or stamp migrations unless the user separately authorizes that mutation and a recovery plan exists.

5. Probe Liveness and Readiness

Test liveness and readiness separately when both exist:

• Liveness shows that the process can respond.
• Readiness shows that the service can handle intended traffic and required dependencies are available.

Record timestamp, target, status code, bounded response summary, and latency. Redact tokens, cookies, internal hostnames, database addresses, and response fields that contain secrets or personal data.

6. Exercise Critical Routes

Run the smallest authorized smoke suite that proves the agreed critical journeys. Prefer synthetic or test records and read-only probes. For authenticated routes, use designated test identities with least privilege and never place credentials in commands, logs, or the report.

7. Check Operational Signals

Inspect the bounded deployment window for crash loops, unhandled exceptions, dependency failures, elevated error rates, or resource exhaustion. Absence of log access is BLOCKED, not proof of health.

8. Issue the Verdict

Publish the evidence matrix, unresolved risks, and exact overall verdict. Keep observations separate from inference. Include enough identifiers and timestamps for another engineer to reproduce the decision without exposing sensitive data.

…