Skip to main content

Task lifecycle

Customer-visible states for a labeling task:

pending → in_progress → verified → settled
   ↑          ↑             ↑          ↑
 Created   Claimed by    Consensus   BSV payment
           first worker  reached     completed

pending​

Task was accepted by the Gateway and written to storage. No worker has claimed it yet (or routing is still in progress).

Customer API: GET /v1/tasks/{id} shows status: "pending". GET .../result returns 202 while pending or in progress.

in_progress​

At least one worker is working on the task; labels may still be arriving. Consensus has not finalized.

Customer API: GET .../result → 202 with message: "Task is still being labeled."

verified​

Consensus has selected a consensus label; the task is logically complete from a labeling perspective. Settlement may still be in flight depending on pipeline timing.

Customer API: GET .../result → 200 with consensus_label, confidence, etc.

settled​

BSV micropayment completed; bsv_txid is populated on the task record.

The settled_at timestamp records the exact moment the BSV payment completed. Use settled_at - created_at to measure end-to-end pipeline latency per task.

Customer API: GET .../result → 200 with settlement.bsv_txid and settlement.settled_at (when available).

tip

For production, prefer webhooks for task.settled instead of tight polling loops.