Initiatives and Tasks

A task is the durable business record of work. It is distinct from the temporary worker process that executes it and from any individual attempt.

Task Information

A useful task identifies:

• the owning profile or department;
• the desired outcome;
• the current status;
• dependencies;
• execution mode;
• attempt limits;
• blockers;
• expected artifacts; and
• evidence used to verify completion.

Initiatives

Use an initiative to group related outcomes while keeping each executable task bounded. Avoid a single enormous task whose success cannot be verified. Child work should have clear stopping points and dependencies rather than relying on sequence hidden in prose.

Dependencies

Dependencies can require another task’s success, completion, or artifact. Oblive rejects self-links and dependency cycles. A dependent task becomes runnable only when its requirements are satisfied. If required work in another task tree fails, Oblive creates one recovery review instead of leaving the dependent blocked forever. Same-department recovery stays with that department; recovery across departments is coordinated by Operator. The dependent resumes after the review closes and uses its recorded result to decide how to proceed.

Attempts and Retries

Each attempt is preserved. A retry does not overwrite the failed or timed-out attempt, and only the latest retryable attempt can be retried within the configured limit.

Tasks expose two run counts: total runs is the complete attempt history, while consumed runs is the number charged to the task budget. A run that stops cleanly for human input or action approval stays in history but refunds its consumed run credit. Failures, timeouts, and invalid output remain charged. Initiative and task budgets default to 12 consumed runs; research, review, and learning budgets default to 6. Each run request still has its independent three-attempt retry ceiling. Cost-denominated task caps are rejected until runtime usage has a real billing meter; token and tool usage remain observable but are not treated as currency.

The task page keeps this history in a compact run ledger. Open a run to review its agent, mode, status, outcome summary, artifacts or evidence, timing, and token/tool usage. The owner view is a deliberately safe projection: execution prompts, hydrated context, worker leases, and workspace or log storage locations are not exposed.

Transport wakeups may be duplicated, but the worker rechecks durable state before starting an attempt. This prevents a duplicate notification from becoming duplicate work.

Retryable failures use exponential backoff from 5 seconds up to 5 minutes. A stale heartbeat is closed together with its request and task state; an exhausted final attempt fails the task instead of leaving it running. Organization and profile concurrency limits are checked under one serialized admission boundary. Capacity deferral creates no attempt and consumes no run credit.

Coordination tasks may replan up to three times. If another amendment is needed, Oblive asks once for a human decision. An approved final amendment is recorded as the task’s single override; a later attempt to amend again fails cleanly rather than repeatedly asking or stalling the task.

Waiting for a Human

When execution needs information or approval, the task moves to a human-waiting state. Answering the item advances the task version and queues fresh execution rather than reviving an expired process. Human waits do not consume the task’s aggregate run allowance.

Cancellation

Cancelling a task also cancels its unfinished child work, queued requests, active runs, open questions, and actions that have not started. Completed child records and already executing or uncertain actions remain visible as history. A task waiting on another task’s completion may continue after that prerequisite is cancelled; requirements for success or an artifact remain blocked.

Completion

Completion should include a concise outcome, evidence, artifacts, blockers that remain, and useful next actions. A task run can synchronize at most 100 changed files beneath its declared output roots. The worker validates the complete set before uploading any file, so 101 files fail as one deterministic non-retryable output error rather than producing a partial result. A run is not successful until validated workspace output has been synchronized.