Weekly planning
Goal Review Checklist: Keep, Change, Reduce, Extend, or Stop
Review a stalled goal using evidence, identify the constraint, and make one explicit decision: keep, change, reduce, extend, or stop.
A goal review is necessary when editing next week's task list no longer solves the problem. The same work keeps slipping, the deadline is approaching, or the goal loses every time it competes with something urgent.
At that point, asking “What task should I move?” preserves the old plan. A better question is: Should this goal continue in its current form?
This checklist is based on the review contract we use in Aimo. It separates evidence from interpretation and ends with one of five decisions: keep, change, reduce, extend, or stop. The agent can suggest the review; the user approves the decision.
Do not confuse a weekly review with a goal review
A weekly review adjusts the plan inside an accepted goal.
Weekly review
What was completed?
What slipped?
What belongs in the next planning window?
A goal review questions the goal's current contract.
Goal review
Does this outcome still matter?
Does the scope still fit?
Does the deadline still fit?
Should the goal continue in this form?
Run weekly reviews on a schedule. Trigger a goal review when the evidence says task-level replanning is not enough.
Trigger a goal review from observable signals
Use a goal review when at least one of these is true:
- the same action has slipped twice;
- there has been no measurable progress for two planning windows;
- the remaining scope no longer fits the time before the deadline;
- completed tasks are not producing the expected outcome;
- another commitment repeatedly consumes the goal's capacity;
- you would not choose the goal again with what you know now.
These are not universal thresholds. They are prompts to inspect the goal. The important part is that the review begins from a signal, not from a vague feeling of guilt.
Step 1: Build the evidence record
Write what happened before explaining why.
| Evidence | Record |
|---|---|
| Original outcome | Launch a paid beta by November 30 |
| Planned in the last two weeks | 7 invitations, 2 observations, fix 1 blocker |
| Completed | 4 invitations, 2 observations |
| Missed | Blocker selection and fix |
| Measured result | 2 replies, 1 completed onboarding |
| Repeating pattern | Product polishing displaces outreach |
| Remaining capacity | Two 90-minute blocks per week |
Avoid interpretations such as I was lazy or the plan failed. They do not tell you what to change. Record actions, outcomes, dates, and constraints.
Step 2: Identify the violated assumption
Every plan contains assumptions. A stalled goal usually exposes one of them.
| Assumption | Evidence that violates it |
|---|---|
| Seven invitations fit in one block | Only four fit in 90 minutes |
| More features will improve activation | Observed users failed before reaching those features |
| November 30 allows a polished beta | Current capacity supports only one tested flow |
| The goal still wins priority conflicts | Client work has displaced it for three weeks |
This step prevents the common response of shrinking every task while leaving a broken goal unchanged.
Step 3: Choose exactly one decision
Keep
Choose keep when the outcome, scope, and deadline still fit. Change the next actions, not the goal.
Decision: Keep
Reason: The goal still matters and two observations confirmed the core problem.
Next plan: Reduce invitation batches and schedule note cleanup before analysis.
Change
Choose change when new evidence points to a different outcome.
Old outcome: Launch a paid beta.
New evidence: Users need a manual service before the workflow can be automated.
Decision: Change to a concierge beta for five users.
Reduce
Choose reduce when the goal matters but the current scope is larger than the available capacity.
Old scope: Dashboard, billing, automation, and onboarding.
Decision: Launch one paid workflow with manual onboarding.
Extend
Choose extend when the outcome and scope still matter but the deadline no longer fits for a specific reason.
An extension should include a new date and the evidence behind it. “Later” is not a review decision.
Stop
Choose stop when the goal is no longer worth its cost or repeatedly loses to commitments that genuinely matter more.
Stopping is not the same as forgetting. Record the reason and what happens to unfinished work so the goal does not remain as permanent background debt.
Copy this goal review checklist
GOAL
Original outcome:
Deadline:
Why it mattered:
EVIDENCE
Planned:
Completed:
Missed:
Measured result:
Repeating pattern:
Available capacity:
ASSUMPTION
What did the plan assume?
What evidence contradicted it?
DECISION
[ ] Keep
[ ] Change
[ ] Reduce
[ ] Extend
[ ] Stop
Reason:
Updated outcome or deadline:
Next observable action:
Review date:
A completed review has one checked decision and one next observable action. If every box remains possible, the review has not finished.
Example: review a side-project launch
Goal
Launch a polished paid beta by November 30.
Evidence
Four of seven invitations sent.
Two onboarding attempts observed.
Both users stopped at account setup.
Dashboard polish consumed the Saturday block.
Violated assumption
More product surface was needed before testing.
Decision
Reduce.
Updated goal
Launch one paid workflow with manual onboarding by November 30.
Next action
Thursday: remove optional setup fields.
Done when: a new user can reach the core workflow with email only.
The review does not produce a more ambitious plan. It protects the important part of the goal by removing unsupported scope.
How Aimo uses the same boundary
Aimo stores tasks under goals, so completed and missed work can become review evidence. When progress falls behind, the agent can surface goal-level options instead of endlessly moving overdue tasks.
The product is intentionally approval-based at this point. An AI system may detect that pace is behind; it cannot decide that a founder should abandon a project or extend a personal commitment. It drafts the consequences of each option, and the user chooses.
After the decision, use the rolling weekly planning template to build the next window. If you need the larger system, start with the goal execution loop.