Shared
Production Readiness Checklist
This checklist applies to every capability in the handbook before it is considered production-ready.
- An accountable owner and technical contract are documented.
- At least one successful and one failing end-to-end scenario is reproducible.
- Access controls, retention, and audit requirements are verified where relevant.
- Release monitoring includes a measurable success or failure signal.
Project qualification from capability criteria
For a project-wide assessment, each capability in this handbook is a top-level criterion with its own stable capability id. Its concept, decisions, practices, failure modes, and patterns supply candidate acceptance checks. The project's deployment scope determines which checks apply and which are required before production release. A capability inventory is therefore a source of criteria, not a requirement to implement every capability.
The default qualification target is production readiness. Bind an assessment to the project revision, deployment configuration/environment, and knowledge-base snapshot. Establish applicability and release importance from the intended user journeys and architecture before scoring implementation. A missing implementation cannot justify calling a needed capability not applicable. Controls delegated to a gateway, platform, or operator need evidence of that delegation and its behavior within the assessed deployment.
Turn guidance into a checkable contract
For each applicable capability, derive concrete checks with an id, condition, expected behavior or justified threshold, minimum evidence, and release importance. Use these four readiness obligations where they bear on that capability; shared project evidence may support several capabilities when its scope is explicit. Link each check to the handbook passage that motivated it and record the reviewer interpretation separately.
Do not derive an acceptance threshold from a heading or generic template alone. Record an underdefined criterion, obtain a project-specific requirement or verified technical source, and preserve the unresolved question until its contract is clear. Advice about a possible architecture does not automatically become a production requirement.
| Criterion/check status | Meaning | Required explanation |
|---|---|---|
| pass | Inspected evidence satisfies the stated condition at the required level | Evidence locations, observation, revision, and method |
| fail | Evidence contradicts a stated applicable condition | Reproducible or inspectable counterexample and its impact |
| not_verified | Evidence, applicability, or acceptance conditions remain insufficient | What is missing and how to establish it |
| not_applicable | The capability or check is outside the declared architecture/goal | Scope-based reason and supporting evidence |
Maintain separate evidence levels: documented intent, inspected implementation, executed behavior, and deployment/operational observations. A README claim cannot establish an implemented guard; a guard in source does not establish that the intended deployment uses it. The presence of test files does not establish that they ran or what paths they cover.
Docs and source support a useful preliminary assessment. Production requirements about load, restoration, external effects, operational response, and AI task quality require appropriate observed results. Those can come from reproducible executions or inspected records tied to the candidate revision and representative deployment conditions. Never invent a passing run when execution is unavailable.
Qualification verdict
Determine required versus advisory checks before judging results and preserve that profile. Apply these rules without averaging a blocking defect away:
- A demonstrated failure of an applicable required check yields not_qualified for the assessed profile; report unresolved evidence separately as well.
- If no required failure is established but a required check, applicability decision, or deployment context is unresolved, readiness is not_verified.
- qualified_for_profile requires all applicable required checks to pass with adequate evidence, justified exclusions, and a defined project/deployment/KB revision. Disclose advisory findings and inspection limits alongside the verdict.
A capability-level pass requires all of its applicable acceptance checks to pass; no checks defined is not a pass. A project-wide verdict concerns the selected release profile, not all future deployments. The assessment informs the release decision; it does not perform a deploy.
A knowledge-base update evolves the assessment
Adding a capability adds a top-level assessment criterion. Deepening an existing capability can add, refine, or retire acceptance checks within its existing id. Reference or stack edits may change technology guidance without introducing a new mandatory requirement. A review-date edit alone need not alter acceptance conditions.
Keep previous reports bound to their original KB snapshot. Compare the current capability inventory and source fingerprints to that snapshot: new criteria need applicability review; changed guidance needs semantic review and possibly new evidence; removed criteria need an explicit scope/retirement decision. A changed document is a review signal, not automatic proof that the project fails. Shared-guidance changes can affect checks across several capabilities.
Use the project assessment workflow for repository-assistant instructions and the report template for findings. The capability criteria remain in the indexed handbook; project evidence and assessment reports stay outside the knowledge corpus.