UK-based independent AI efficiency projectEvidence before claims ยท 2026

AI Workflow Acceptance: A Heartbeat Is Not a Verified Result

An attempted task moves through artifact, requirement and behavior checks before acceptance; no throughput statistic is shown.

Written by

Token Optimisation

in

,

Classification: reliability method based on two scoped published observations; no production throughput or success rate is claimed.

Acceptance: A Heartbeat Is Not a Verified ResultOUTCOME MODEL ยท NO THROUGHPUT DENOMINATOR. SCHEDULED โ†’ ATTEMPTED โ†’ ARTIFACT SAVED โ†’ VERIFIER PASSED. No production acceptance ledger provides an accepted-jobs-per-hour rate for this workflow.OUTCOME MODEL ยท NO THROUGHPUT DENOMINATOR1SCHEDULED2ATTEMPTED3ARTIFACT SAVED4VERIFIER PASSEDTrack failures and retries ยท Keep callback receipt separate
OUTCOME MODEL ยท NO THROUGHPUT DENOMINATOR. No production acceptance ledger provides an accepted-jobs-per-hour rate for this workflow.

An agent job is not complete because a process is alive, a provider streamed output or the model said โ€œdone.โ€ Define acceptance before execution and verify a durable artifact against that definition.

Write an acceptance contract

State the expected artifact, required fields, source boundary and deterministic checks. If judgement is needed, use an explicit rubric and identify when a person must review. Keep the check independent from a heartbeat or status message.

Track the stages separately

  1. Process is scheduled and alive.
  2. Provider call is pending, streaming, complete or failed.
  3. Workflow stage has emitted a checkpoint or artifact.
  4. Verifier evaluated the artifact.
  5. Job was accepted, partially accepted or rejected.

If a callback was sent but no acknowledgement arrived, preserve its identifier and reconcile delivery before resending. If a model result is missing, do not infer success or failure solely from a heartbeat. Record the uncertainty and inspect the attempt.

Connect claims to evidence

Post #42 documents one successful bounded canary with provider usage; it does not establish general success rates. Post #53 documents a reported stall whose exact earlier outcome is unknown; a later bounded check was separate. They show why liveness, provider activity and acceptance should not collapse into one status.

Use the agent rules builder for progress and verification safeguards, and read the measurement method before comparing runs.