How tasks work
Every task in the implementation checklist follows a governed lifecycle:Task is created with requirements
Each task has acceptance criteria, evidence requirements, dependencies, an owner, and optionally an approval gate
Dependencies are checked
A task cannot start until its upstream dependencies are completed. Blocked tasks are visible in the dependency graph.
Work is executed
The owner works through the task — manually, with AI assistance, or through bounded automated execution in a sandboxed environment
Evidence is attached
Completion requires proof: files, screenshots, test results, configuration exports, links, or verification output. Tasks cannot be marked done without evidence.
Approval is routed
If the task has an approval gate, it routes to the named approver. The approver can approve, request changes, or escalate.
Evidence model
Evidence is not optional documentation. It is structured proof linked to specific tasks:| Evidence type | Examples |
|---|---|
| Files | Configuration exports, Terraform plans, test reports, architecture screenshots |
| Links | Dashboard URLs, monitoring endpoints, ticket references |
| Execution results | Output from AI-assisted task execution in sandboxed environments |
| Verification results | Automated checks confirming acceptance criteria are met |
Approval chains
Approvals in Panaptico are explicit:- Each approval gate has a named approver — not “someone from the team”
- Approvers see the task context, evidence, and execution results
- Three outcomes: approved, changes requested, or escalated
- Approval history is recorded in the audit trail
- Unresolved approvals are surfaced in the project overview as risks
AI-assisted execution
For tasks that benefit from automation, Panaptico provides AI-assisted execution:- Task-scoped agents can generate diagnostics, remediation plans, and configuration files
- Execution runs in sandboxed environments with explicit dependency handling
- Output is captured as evidence and linked to the task
- Agents cannot bypass approval gates or modify blueprint-wide state without explicit request
Risk and blocker management
When work is blocked:- Tasks can be marked as blocked with a reason and downstream impact
- Risks are tracked with severity, ownership, and resolution status
- Blocking risks surface in the project overview intelligence dashboard
- The dependency graph shows which downstream tasks are affected
- Risk resolution is recorded with evidence
What makes this different from a ticket system
| Dimension | Ticket system (Jira, Linear) | Panaptico governed execution |
|---|---|---|
| Structure | Flat or loosely grouped tickets | Phased tasks with formal dependencies |
| Evidence | Optional attachments | Required proof linked to acceptance criteria |
| Approvals | Comment-based or external | Named approvers with explicit routing |
| Context | Isolated per ticket | Every task sees the full implementation graph |
| Audit | Activity log per ticket | Full cross-task, cross-surface audit trail |
| Health | Manual status reports | Automated scoring, trend detection, A–F grading |
| Post-completion | Ticket is closed | Task state feeds into post-implementation monitoring |
Next steps
Post-implementation
What happens after go-live
Executing tasks
Step-by-step task execution guide