# Release Review Checklist Fone · Version 1.1 · Prepared 2026-10-27 Free to copy and adapt for your own projects and client work. ## Identify this review | Field | Your entry | | --- | --- | | Product and workflow | | | Release candidate or commit | | | Environment | | | Review date | | | Decision owner | | | Reviewers | | | Model, prompt and retrieval configuration, if applicable | | | Evaluation set and version | | | Chain ID, token and contract addresses, if applicable | | | Confirmation/finality policy and indexing source | | | Agreed latency, usage and retry limits | | Start each applicable check as NOT RUN. Use PASS only after reviewing evidence. Mark a failed check or unresolved decision OPEN. N/A requires a reason tied to the scope. For every applicable check, record the actual result, evidence and reviewer in the evidence register below. A tick in the agenda alone does not establish a pass. Keep credentials and confidential customer information out of public copies. Use synthetic or approved, minimized test data. This is a review aid, not an exhaustive audit or certification. ## Scope and acceptance - [ ] Agreed user journeys demonstrated to the reviewer. - [ ] Failure states and recovery actions reviewed. - [ ] Known limitations and deferred work recorded. - [ ] Supported devices and environments documented and checked. - [ ] Critical content, links and contact paths reviewed. ## Access and data - [ ] Account, workspace and object-level permission boundaries checked. - [ ] Sensitive operations require the intended permissions. - [ ] Secrets stay outside source control and public documents. - [ ] Client owns or has agreed access to operational accounts. - [ ] Data retention, deletion and access responsibilities are clear. ## Release and recovery - [ ] Setup instructions followed in a clean environment. - [ ] Relevant checks pass against the release candidate. - [ ] Deployment steps and production verification documented. - [ ] Rollback procedure reviewed, including data migration limitations. - [ ] Backup restoration rehearsed in an isolated environment. - [ ] Background jobs, storage and external dependencies included in review. ## Operations and handover - [ ] Errors and operating signals have a named owner. - [ ] Escalation and support contacts documented. - [ ] Recurring costs and renewal ownership recorded. - [ ] Documentation and repository access handed over. - [ ] Support scope and future changes handled separately. ## Additional review for AI workflows - [ ] Representative evaluation examples and pass criteria agreed. - [ ] Failure/refusal and human-review paths tested. - [ ] Retrieved content respects source permissions. - [ ] Tool actions have bounded permissions and explicit approvals where needed. - [ ] Cost, latency and usage limits checked with representative inputs. - [ ] Model/configuration version recorded; change review process agreed. ## Five AI workflow scenarios to adapt These proposed cases assume an application drafts a reply from permitted source material, then requires human review before an explicit send action. Adapt the expected behaviour to your workflow before running them. The default entries below record no completed tests. ### AI-01 Missing answer Set up an enquiry whose required fact, such as a price, is absent from the permitted source set. Keep a record of that source set. Expected behaviour is that the draft leaves the missing fact unresolved and lets the reviewer see what needs a decision. Record the source set and the actual draft. An invented fact should leave this case OPEN. ### AI-02 Denied access Use two synthetic workspaces. Ask a user from one workspace to retrieve a known record in the other, including a direct application request that bypasses the interface. Also run an authorized control request. Expected behaviour is that the server blocks unauthorized content before it reaches the model. Record the access decision and which content was retrieved, using redacted evidence. A hidden button alone is insufficient evidence. Include the equivalent execution-time check if the workflow can write to another system. ### AI-03 Provider timeout In a non-production environment, inject a model-provider timeout. Agree the time and retry budget first, then observe the request until it reaches a recoverable state. The original enquiry should remain available. Record the visible status, retry attempts and the outcome after recovery. If an external action might already have occurred, preserve that uncertainty for reconciliation before retrying the effect. ### AI-04 Repeated action Submit the same intended send action twice using its recorded action identifier. Include a case where the first response is lost. Check the downstream service's actual idempotency and lookup contract before defining a pass. Record each attempt and the observed effect. Where the contract permits deduplication, verify it. Where the downstream outcome cannot be determined, the application should flag it for reconciliation rather than silently resending or claiming exactly-once delivery. A local database record alone does not prove that an external effect occurred once. ### AI-05 Human handoff Route an unsupported or unresolved request to a named reviewer. Have that person locate the original enquiry and the permitted context, then complete or reject the task without requesting another model answer. Record whether the task was discoverable, who took ownership and what final state was shown. If a notification is part of this handoff, check actual receipt separately from acceptance by the notification service. ## AI case results | Case | Status | Actual result and evidence reference | | --- | --- | --- | | AI-01 | NOT RUN | | | AI-02 | NOT RUN | | | AI-03 | NOT RUN | | | AI-04 | NOT RUN | | | AI-05 | NOT RUN | | ## Five Web3 workflow scenarios to adapt Run these cases on a local chain or testnet with test assets. Record the contract and application versions. Adapt the expected result to the actual payment, membership or agent workflow before running a case. | Case | Setup and expected result | Evidence to retain | | --- | --- | --- | | W3-01 Sign-in replay | Reuse a consumed sign-in challenge, then try a mismatched domain and expired message. Server verification rejects each request without creating a session. Include a valid control request. | Redacted challenge, validation outcome and session state | | W3-02 Payment terms | Submit test payments using a wrong chain, token contract, amount or recipient. Each mismatch remains unresolved and grants no entitlement; compare with a matching payment under the agreed finality policy. | Order terms, chain ID, transaction receipt and order state | | W3-03 Duplicate delivery | Deliver the same verified payment event twice and retry after an interrupted fulfillment step. One payment grants one entitlement; recovery completes missing work without a second grant. | Event identity, processing attempts and entitlement record | | W3-04 Revoked authority | Revoke an agent session, then attempt execution with that session, including an earlier signature. Execution is rejected by the enforcing application or contract. Already completed transfers remain recorded. | Policy version, revocation receipt and rejected execution result | | W3-05 Recovery after submission | Lose the RPC response or delay the indexer after submission. Recover using the recorded transaction identity and receipt. Keep pending, failed and confirmed states distinct; reconcile changes under the selected network policy before fulfillment. | Transaction/receipt, indexer position, recovery steps and resulting order state | For sign-in validation, use [ERC-4361](https://eips.ethereum.org/EIPS/eip-4361) and the appropriate contract-account verification path. Review permissions again at execution. An AI response must not be the authority for changing a payment or access state. | Case | Status | Actual result and evidence reference | | --- | --- | --- | | W3-01 | NOT RUN | | | W3-02 | NOT RUN | | | W3-03 | NOT RUN | | | W3-04 | NOT RUN | | | W3-05 | NOT RUN | | ## Evidence and open decisions Add a row for each general check and applicable AI or Web3 case. Store the evidence in an appropriate private location when it contains restricted information. | Check or case | Status | Actual result and evidence | Owner or reviewer | Next action and due date | | --- | --- | --- | --- | --- | | | NOT RUN | | | | Record a reason for each N/A decision. Do not turn an untested check into PASS to complete the table. ## Release decision | Decision field | Your entry | | --- | --- | | Release, limited release or hold | | | Approved scope and release candidate | | | Blocking issues | | | Accepted limitations, rationale and owner | | | Initial rollout group | | | Stop conditions and person who can disable the feature | | | Recovery procedure and migration limits | | | Next review date | | | Decision owner and date | | An unresolved critical access failure holds the affected feature back. Disabling a feature does not reverse effects already completed. Recheck relevant cases after changes to the model, prompt, retrieval configuration or action code. ## Background [AI production guide](https://fone.cc/insights/from-ai-prototype-to-production/) [Software handover guide](https://fone.cc/insights/software-handover-checklist/) [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) [AWS guidance on safe retries](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) Version 1.1 retains the version 1.0 review topics and adds explicit test status, five AI cases, five Web3 cases and a release decision record. The document contains no results from a customer deployment.