An Initiative Task is an operational work item within an Initiative that represents something the team needs to do — a review, a checklist item, or a custom action — to advance the Initiative through its stage lifecycle. Tasks live in the Delivery view of an Initiative.
Tasks are deliberately generic. They track execution work (did we do this thing?), while Change Proposals track substantive changes to the requirements catalog. This separation keeps the delivery view focused on completion, not content.
Task Types
Catalio supports three task types:
| Type | When to Use |
|---|---|
| checklist | Simple checkbox items: “Upload process documentation”, “Schedule stakeholder review” |
| review | Review an entity or set of changes: “Review AI-generated requirements for AP module” |
| custom | User-defined task type for anything that doesn’t fit the above |
Task Stage Alignment
Tasks are aligned to Initiative stages, indicating when they should be completed:
| Stage | Description |
|---|---|
| plan | Tasks for the Planning stage: discovery, artifact collection |
| review | Tasks for the Approval stage: stakeholder review, sign-off |
| build | Tasks for the Build stage: implementation oversight |
| release | Tasks for the Release stage: deployment verification |
| inspect | Tasks for the Retro stage: outcome measurement, lessons learned |
Task Lifecycle
Tasks follow a state machine lifecycle:
pending → in_progress → completed
↘ skipped
↘ rejected
pending — The task has been created but not yet started.
in_progress — Work on the task is underway. Assign a team member and set a due date.
completed — The task is done. Optional resolution notes document what was accomplished.
skipped — The task was deliberately bypassed (with documented reason).
rejected — The task is not applicable or cannot be completed (with documented reason).
Key Fields
| Field | Purpose |
|---|---|
| title | Short task name |
| description | What needs to be done and why |
| task_type | checklist, review, or custom |
| stage | Which stage this task belongs to |
| status | Current lifecycle state |
| required? | Whether this task must be completed before stage advancement |
| priority | Task urgency within the stage |
| assigned_to | Team member responsible |
| due_date | When the task should be completed |
| resolution_notes | Notes recorded when the task is completed, skipped, or rejected |
| initiative_id | Parent Initiative |
| change_proposal_id | Optional link to a specific Change Proposal |
Required Tasks and Stage Gates
Tasks marked required? true must be completed before the Initiative can advance to the next stage. Catalio’s readiness signals incorporate required task completion — an Initiative with outstanding required tasks in the current stage will show this as an unmet signal.
This gives you a lightweight, configurable gate system. For example:
Stage: review (Approval stage)
Required Tasks:
- [ ] Complete stakeholder sign-off session
- [ ] Review all AI-generated requirements for AP module
- [ ] Confirm out-of-scope items with sponsor
Optional Tasks:
- [ ] Attach signed scope document
- [ ] Update project management system
The Initiative cannot advance to Build until all three required tasks are checked off.
Linking Tasks to Change Proposals
When a Task is linked to a specific Change Proposal via change_proposal_id, it creates a direct connection between a delivery work item and the substantive change being proposed. This is useful for review tasks: “Review and approve change proposal #42 for the Invoice Matching requirement.”
Best Practices
Create tasks at stage entry, not at Initiative creation.
Tasks should be created when the Initiative enters a stage, not all upfront. The tasks relevant to Planning are different from those relevant to Build — and you may not know what Build tasks are needed until Planning is complete.
Use required? sparingly.
If everything is required, nothing is meaningfully gated. Reserve required? for the 2-4 tasks that truly must happen before the next stage is appropriate.
Assign tasks immediately.
Unassigned tasks float. The moment a task is created, assign it to a specific team member. Accountability drives completion.
Use resolution notes for institutional memory.
When closing a task, write a brief note about what was actually done. “Completed stakeholder sign-off” is useless. “Held sign-off session 2026-04-15; sponsor approved scope with one change: removed Linear integration from v1 scope” is valuable.
Pair review tasks with Change Proposals.
For every batch of AI-generated proposals, create a review task: “Review AP module proposals from Oracle EBS user guide extraction.” This keeps proposal review on the official task list rather than being informal.
Relationships at a Glance
| Related Concept | Relationship |
|---|---|
| Initiative | Tasks belong to an Initiative |
| Change Proposals | Tasks can be linked to a specific proposal |
Next Steps
- Understand Initiatives — Learn the stage lifecycle that Tasks support
- Review Change Proposals — Create review Tasks for proposal batches
- Track Risks — Manage threats alongside delivery tasks
Pro Tip: At the start of each stage, hold a 15-minute planning session to create the tasks for that stage. This makes the stage’s completion criteria explicit before work begins, not after.
Support
- Documentation: Continue reading about Initiatives and Change Proposals
- Email: support@catalio.ai
- Community: Share delivery workflow patterns with other Catalio users