Review an action before approval

1. Identify the exact change

An approval is useful when the reviewer can understand the action they are being asked to authorize. Start with a concrete proposal, such as updating a shared project record after a planning review. This tutorial is a practical review checklist based on Modeus's approval design, rather than a claim about a particular live integration.

Read the objective and the proposed change together. Which record is affected? Which fields will change? What values are being proposed? Who or what will perform the action? If the proposal is too broad to answer these questions, return it for clarification before making a decision.

2. Check the basis for the proposal

Open the sources that explain why the change is needed. A meeting note might establish a decision, while the current project record shows the state being updated. Compare them. If the source says a deadline is tentative but the proposal makes it firm, the problem is in the proposed change, even if the action itself appears routine.

Check that the proposal still matches the current situation. A correct request can become stale when a target changes, an owner is reassigned, or a newer decision supersedes the original one. Approval should apply to the specific change under review rather than serving as open-ended permission for later variations.

• Target: the exact object or destination affected by the action.
• Change: the content or state that will be added, replaced, or removed.
• Basis: the current source, objective, and decision supporting it.
• Impact: the relevant audience, cost, data exposure, and dependencies.

3. Understand the check and the recovery path

Before approving, ask how the result will be checked. For a record update, this could mean reading the resulting fields and comparing them with the intended values. For a document handoff, it could mean reviewing the exact artifact and its completion criteria. The check should address the requested outcome, not just the absence of an error message.

Consider what happens if the result is unclear or wrong. Some changes can be reversed; others require a follow-up action. A reviewer should understand the available recovery path and its limits. If an external action might have succeeded despite a lost response, inspecting the target is usually a better next question than immediately repeating it.

4. Decide, then review the outcome

Approve when the proposed change, its authority, and its expected evidence are clear enough for the decision you are responsible for. Reject or request revision when they are not. Include a concise reason when it will help the next contributor understand what needs to change. Some work may need more than one reviewer or a separate policy decision.

After execution, inspect the result against the same proposal. An approval records permission to proceed; it is not proof that the action succeeded. Close the loop by checking what changed, what evidence is available, and whether any uncertainty remains. This keeps both the decision and the outcome understandable to the next person who opens the work.