Work Contract fields and Handoff APIs follow the latest published official docs. This page helps you finish one handoff and see which step writes a Source.
What the loop looks like
The Work Contract, Handoff boundary, acknowledgement receipt, and Task Outcome each leave a Source receipt. A committed Handoff also has an immutable Artifact Revision. Preparing writes a boundary Source, so it is not a read-only preview.Complete Python example
Createhandoff_loop.py:
model_validate for nested requests because the JSON contract names the field schema, while generated Python models expose an internal alias.
Boundaries at each step
Work Contract is a delegation baseline
It records the objective, in-scope work, exclusions, completion criteria, authorization notes, and consequential questions. The Contract is anuntrusted_input Source and grants no new authority. A claim with basis="verified" needs exact evidence; a declared claim carries none.
handoff_current_work writes a boundary Source
It returns:
prepared_work.handoff, not the whole response, to commit or continue.
This operation creates no Handoff Revision, but it does persist the boundary Source. It is not a read-only preview.
Temporary transfer needs no commit
The example first usescontinue_handoff(selection="prepared"). A temporary transfer works and has selected_revision=None.
Call commit_handoff only when the work needs a durable milestone.
latest discovers; exact acknowledges
Latest returns the current head in both selected_revision and current_revision. After inspection, bind acknowledgement to that exact Revision.
acknowledge_handoff does not accept selection="latest".
Accepted has hard requirements
All three checks must be confirmed, and all evidence must be available:needs_clarification or declined with a message.
Acknowledgement records receiver judgment. It grants no permission.
Outcome links an accepted exact receipt
Use:handoff_receipt_ref.
Only an accepted receipt with exact selection and a selected committed Revision can cover a durable Handoff. A prepared acknowledgement receipt cannot establish that link.
Outcome and check states
OverallTaskOutcome.status accepts:
TaskCheck.status accepts:
Negative experiments
Read latest without commit
Before commit,continue_handoff(selection="latest") returns status="empty". The Prepared Handoff still works with selection="prepared".
Accept with authorization unchecked
Change authorization tonot_checked. The operation rejects accepted status. Use needs_clarification and state what is missing.
Link a prepared receipt to a committed outcome
Acknowledge prepared, then use that receipt ashandoff_receipt_ref. The Server rejects it because the receipt is not bound to an exact committed Revision.
Prepare twice from one base
Prepare two Handoffs, commit the first, then commit the second. The second returns a Revision conflict. Read the new head and prepare again rather than guessing a revision.Boundary succeeds and commit fails
The boundary Source remains, but no new Handoff Revision exists. Report both facts. Do not say that nothing was written or that the milestone was saved.How you know it worked
- The Work Contract receipt is saved.
- Prepared Handoff can continue temporarily.
- Commit returns an exact Handoff Revision.
- After you find the latest version, acknowledgement binds to that exact Revision.
- Before accept, you check evidence, live state, capability, and authorization.
- Task Outcome links the acknowledgement receipt SourceRef.
- Overall outcome and individual check statuses stay separate.
Next step
Experience, Skill, and Review
A Candidate enters Review first. An approved Skill still needs an explicit export.
If you are stuck
You asked for a preview, then called Handoff. Start there.

