Check the stage and its requirements
Open the project’s current stage and Requirements panel before preparing a submission. Workspace governance settings define the stage requirements and SLA limits. Document requirements come from the project’s applicable document template. The panel links unmet items to the part of the project where the team can address them.
Separate mandatory requirements from advisory ones. Unmet mandatory requirements block stage submission. The readiness checklist presents requirement states including provided, pending approval, waived and missing, with the actual blockers called out. Read the individual requirement: providing a document and obtaining an approval are separate checks when the configured requirement says they are.
Prepare document evidence in its project context
Use the project’s Documents tab and the correct folder or template placeholder for the required artefact. A returned document does not satisfy the document requirement. Where the template permits Log a note instead, a bypass note can represent the item; it is not an automatic PMO approval or a general waiver of every requirement.
For a separate document review, a file or note must be present and client sign-off must be recorded before Send for review becomes available. The Actions document queue then lets an authorized reviewer decide it. Keep the document’s status, revision and review outcome clear rather than treating the existence of any attachment as an approved artefact.
Keep external links distinct from evidence
Linked files lets the team reference SharePoint, OneDrive or Google Drive material alongside the project’s documents. That is useful context, but a link does not satisfy a mandatory document requirement or become verified approval evidence. The linked file stays subject to its provider’s access rules.
If a required charter exists only as a SharePoint link, attaching the link alone will not clear its document gap. Provide the file or permitted note through the document workflow. This distinction matters in a review: the team should be able to tell what was supplied in AEVU and what is only a pointer to material elsewhere.
Use readiness explanations to understand the gaps
On the stage review, Why is this gate ready or blocked? exposes the deterministic checklist. This checklist works independently of AI. When the relevant capability, permissions and budget allow it, Ari can create a private explanation from the same evidence, with references to the checklist’s requirements and blockers.
The explanation does not submit or approve the stage, and it cannot turn a blocked verdict into an approval recommendation. A draft can become out of date when evidence or requirement decisions change. Recheck the current checklist and its cited records before using the explanation in a review conversation.
Submit, review and record the outcome
A person with stage submission permission sends the active stage for review once mandatory requirements are met. The stage appears in the Actions queue for authorized reviewers. The reviewer examines the evidence, plan and relevant risks or issues, then approves or returns it for modification with a meaningful reason.
Approval opens the next lifecycle stage; approval of Closing completes the project. A return keeps the reason visible so the team can correct the work and submit again. Decisions re-evaluate requirements. Some outstanding items can be recorded as an approval override, but the Closing payments-settled rule cannot be overridden. Readiness is therefore preparation for a human decision, rather than a promise that every decision is mechanically blocked by every gap.