A working demonstration answers a useful question: can the proposed software express the workflow? Before a business depends on it, there are further questions. Can the right people use it from beginning to end? Can the wrong people access its records? What happens when a connection fails, a release changes the data or the person operating it is unavailable?
AI-assisted development changes how quickly a team can produce and revise software. It does not settle these operating questions. A release readiness review connects the intended use of the system to evidence that the particular version being released can support it.
Define what the release is meant to support
Name the users, organisations, workflows and integrations included in the release. A limited internal pilot and an application accepting public customers need different scopes of evidence. Make that distinction explicit so a successful small trial is not silently treated as approval for unrestricted use.
Write acceptance criteria in terms of completed work. For a request-and-approval application, that might mean an invited employee can enter the correct organisation, submit a request, receive a decision and retrieve the resulting record later. Specify which exceptions and denied actions are part of that journey.
Our article on AI-native business systems explains the relationship between the workflow and its intelligence layer. A release review applies that design to the version about to be used.
Ask for evidence tied to the actual version
A screenshot from an earlier demonstration does not establish how a new release behaves. Record the software version, environment, configuration relevant to the check, time of execution and result. Include a reference to the evidence and the person or service that produced it.
Separate what was tested from what was asserted. A manual note saying that account isolation works is different from a recorded attempt to access another organisation's record. Both may belong in a review, but they should not carry the same evidential weight.
When a relevant change occurs after testing, identify the affected checks. Evidence remains useful only within its scope. The reviewer should be able to tell whether a result applies to the application, a preview environment or the production configuration that will actually serve users.
Exercise the complete user journey
Test how users enter the system, recover access, join an organisation and reach the work they are authorised to do. An application can have a polished dashboard while invitations, verification or role assignment prevent people from reaching it.
Then follow a realistic record through the workflow. Save it, return to it in a fresh session and verify the next authorised person's view. Include attachments, exports and notifications where those are part of the intended use. Check the devices and screen sizes the real users need.
Introduce failures that operators will encounter: a duplicate submission, a missing document, an interrupted upload and an unavailable integration. A useful error state explains what happened and how the work can continue without creating duplicate commitments or losing the record.
Verify permissions through the data paths
Hiding a button is not sufficient evidence that an action is forbidden. Test the underlying data access and update paths using identities with different roles. Where the product serves separate organisations, verify that each can access only the records it is entitled to use.
Include search, exports, storage and AI retrieval in the review when those features exist. Check what happens when a member is removed or a role changes. For privileged accounts, verify the required authentication controls and the recovery procedure.
Cyclotron's security and engineering principles describe these design concerns. The evidence for an individual release must still demonstrate the controls implemented in that system. A principles page cannot substitute for a release-specific check.
Plan for data changes and recovery
A code rollback and a data recovery are different operations. Restoring an older application version may not undo a database change, an external message or a posted transaction. Identify these consequences before approving the deployment.
For a release that changes stored data, review the migration, try it in an appropriate non-production environment and reconcile the result. Confirm what backup or recovery point exists, whether restoration has been tested and what data could be lost under the agreed recovery approach.
Assign the person authorised to pause the rollout and the person who can carry out recovery. Document the decision conditions. During an incident, a short procedure with named responsibilities is more useful than an assumption that somebody will know which version to restore.
Include the work of operating the system
Identify how failed jobs, unusual access, integration errors and incomplete business transactions will become visible. Alerts need an owner, and that owner needs a practical next action. Avoid placing sensitive record contents in logs merely to make investigation easier.
Review dependencies and known vulnerabilities according to the system's risk. Confirm how fixes will be assessed and released after launch. NIST's Secure Software Development Framework, version 1.1, recommends integrating secure development practices into the software lifecycle and provides a vocabulary for discussions between producers and purchasers. The checks here are a practical release review, not a claim of certification against that framework.
Record the decision and its conditions
Keep a release record that identifies the initiator, approver, deployment executor and verifier. In a small team, one person may hold more than one responsibility where the applicable policy allows it; record the actual arrangement. Do not imply independent review if it did not occur.
List unresolved findings with their impact, owner and deadline. State whether they block release or support only a limited deployment with defined conditions. Verify the important journey again after deployment, because a successful build does not establish that the production environment is configured correctly.
The result is a decision the business can explain: this version is approved for this use, on this evidence, with these responsibilities. That record provides a firmer basis for expanding the system than confidence in the demonstration alone.