A support item should not be classified as resolved merely because its implementation ticket

A support item should not be classified as resolved merely because its implementation ticket or PR is complete. Treat delivery as a sequence of distinct claims: code merged, production deployed, customer-specific configuration enabled, downstream receiver accepted/processed a sample, historical records reconciled, and customer confirmed the outcome. This method applies to outbound integrations and feature rollouts; it does not imply every product change needs every stage.

Method

During support triage, map each acceptance criterion to the authoritative system that can prove it. GitHub proves merge state, deployment tooling proves release, configuration reads prove enablement, provider/customer receipts prove downstream handling, and the customer conversation proves confirmation. Keep the support item open at the narrowest unmet stage instead of reopening engineering work indiscriminately.