Tasks and recovery
Turn unresolved decisions and failed system actions into visible operational work.
Why tasks exist
Praxis turns operational ambiguity into explicit work. A reply is not considered sufficient when the underlying problem still needs an action, and a connector failure is never allowed to disappear into a log line.
Tasks can come from an organic evaluation, a manual action, or the adapter layer that handles system failures and queue timeouts.
Task lifecycle
| Field | Values or meaning |
|---|---|
| Status | open, in-progress, done, cancelled |
| Priority | low, medium, high, urgent |
| Links | Optional profile, owner, message, and decision ids |
| Timing | Created, optional due, started, and completed timestamps |
| Source | organic-evaluation, manual, adapter |
Recovery policy
| Failure | Recovery intent |
|---|---|
system-unavailable | Retry when the remote system returns |
access-denied | Review connector permissions or the request |
configuration-needed | Complete missing connector setup |
invalid-request | Fix or enrich the request |
unknown | Keep the operation visible for investigation |
Recovery wording is connector-agnostic so the operational queue remains understandable regardless of which system of record failed.
Automatic draining
When AI is enabled and the evaluator mode is ask-ai, the task queue agent can progress pending work after each tick. Other modes leave tasks visible for explicit handling.