Skip to content

Co-work Verify durable dispatch and rechecks

Closed durable worker dispatch, fail-closed restart recovery, and proposal-linked re-evaluation obligations.

Details

Durable launch path

Starting Verify or Co-think creates:

  • the immutable Truth action/plan/run records;
  • a job-scoped model-call authorization receipt;
  • an operational runtime job bound to the exact run, role, provider/model, context hash, and worker session; and
  • a deterministic internal operation in the existing disk-backed queue.

The internal operation type is closed and non-discoverable. Agents cannot find or invoke the worker-launch primitive through wb_search or wb_run.

The queue operation ID is deterministic from the handler and job ID. Concurrent identical enqueues converge; conflicting reuse fails. RetrySweep provides the existing atomic lease. The runtime job then adds an atomic launch claim, preventing two sweepers from spawning the same worker.

For a mixed selected-check plan, admitted in-process checks finish first. Model-backed check assignments then run as a deterministic sequential chain of least-authority specialist jobs. Each job is bound to exactly one criterion, check, binding, configuration hash, and sequence position. Its normalized submission commits the exact check execution and result IDs, prepares the one deterministic successor, and then durably completes the parent with that exact next-job reference before enqueueing the successor. A crash during enqueue therefore leaves a completed parent and one recoverable prepared child, never a failed parent plus a viable duplicate path. The initial whole-context coordinator is the final specialist's one deterministic successor.

Portable coordination lifecycle records retain the sanitized specialist assignment plus consequence IDs, never raw worker prose. Replay validates the assignment against the frozen plan and returns only the already-bound next-job or coordinator consequence. Prepared-job reconciliation recreates a missing queue handoff for that same child without projecting the parent again or starting another specialist.

What recovery may do

On sidecar start and queue sweeps:

  • a prepared job whose handoff file is missing is re-enqueued while its exact authorization remains valid;
  • an expired authorization becomes terminally unavailable without a model call;
  • a running job with a live process remains running;
  • a running job whose process exited before typed submission becomes unavailable; and
  • a job left in launching after its launch lease expires becomes unavailable with launch_outcome_unknown; while
  • a job left in submitted has its stored typed payload integrity-checked, atomically projection-leased, and completed from that payload without starting another model call.

The last case is intentionally not replayed: the host cannot prove whether the external model call began before the crash. The model-call receipt has retry_limit: 0; queue retry handles pre-launch dispatch failure, not silent model-call replay.

Portable import enforces the same boundary without trusting runtime state: specialist sequence and parent links must match the admitted account-backed assignments in the frozen plan, completed result references must be complete, and the final handoff must target the run's initial coordinator. Receipts must retain the fixed cost ceiling, zero retry limit, human authorizer, exact provider/model, and captured-target-only specialist boundary.

The durable submitted boundary is not a call retry. It means the worker call already returned and the normalized typed payload plus SHA-256 digest were committed before consequence projection. Reconciliation can therefore append the same dispositions, next-job binding, Co-think outcome, or proposal exactly once under a projection lease. The portable Truth lifecycle also records the submitted fact, so a crash between runtime and Truth projection can be backfilled without exposing raw worker output.

Run history and inspection expose prepared/queued/running/completed/failure state and diagnostics. Queue state is operational only; it cannot invent a Truth result or proposal.

Recheck lineage

When a Verify result leads to a proposal, a ResultRelation records addresses → proposal. When that exact proposal is applied through a committed human sitting, verification_recheck_intents derives the pending obligation from durable sitting receipts, Verify runs, and result relations. It does not create another mutable recheck queue.

The intent binds:

  • sitting and source Verify run;
  • exact applied proposal IDs;
  • original action snapshot and target source/kind;
  • the original target reference when the action was scoped;
  • original provider/model; and
  • the original user goal and protected intent; and
  • committed timestamp.

A conforming recheck remains useful: it records that the exact deterministic criterion found no configured non-preferred term in the new frozen target.

Starting a recheck

A pending intent appears as a persistent Correction ready to recheck card in Review. It does not run a model on refresh, SSE invalidation, sitting commit, or background recovery. The Review action is only a contextual handoff: it opens the Verify dock and binds the source run, pending proposals, original intent, and required execution selection. Review cannot launch the worker.

Only Run Verify in that bound dock captures the fresh action snapshot and starts execution. When the durable original target still resolves, it is rebound automatically. When a legacy target cannot be resolved, the dock requires a newly chosen and affirmed exact Working on passage before the run can start. The affirmation captures the character-range reference identity and target-text hash in a separate non-executing server request. The server persists that human ActionSnapshot and returns its receipt. Run captures again, reloads the attested receipt, and must match both values; an edit inside the same apparent range invalidates the affirmation.

Every strict recheck start requires:

  • a fresh action snapshot captured after the sitting committed;
  • the source run’s provider/model;
  • the source run’s user goal and protected intent;
  • the exact still-pending proposal set; and
  • the exact derived recheck_intent_id;
  • a fresh model-call authorization.

For an ordinary durable intent, the fresh capture must also resolve the same target source, kind, and durable target reference. For a legacy user_action_required intent, the server instead requires the separately persisted human affirmation receipt, a fresh non-document Working on action, a character-granular durable reference, and exact reference/text hashes matching that affirmation. The receipt is bound to the intent, source run, proposal set, original goal, protected intent, actor, and document before Run. The confirmation, intent, source run, proposals, and original goal/intent travel together in the coordination request and model-call authorization context.

Neither path may widen an unresolved range to the whole document. Review only hands the context to the Verify dock; the person chooses and affirms the intended passage, and Run Verify remains the execution boundary.

An exact retry of the same Run capture and bindings returns the already-started run, even after the derived intent has become fulfilled. Reusing that capture with a changed goal, protected intent, model, configuration, lineage, or affirmation receipt fails closed.

New results record rechecks relations to the applied proposal and prior evaluation result. The derived intent becomes fulfilled only when later result relations prove that the exact pending proposals were re-evaluated by a run bound to that intent, target, provider/model, and source run.