Work contracts and completion receipts

Define. Limit. Prove.

Before an agent starts, define the job and what finished means. While it works, keep access inside the stated boundary. Before calling it complete, inspect the result and record the proof.

This is a work contract, not legal paperwork. Its purpose is to make expectations visible before effort begins.

Match the contract to the work

Use a quick contract for one small, reversible task. Write the result, source, access limit, acceptance test, and stop rule in five lines.

Use the full contract when work is multi-step, delegated, scheduled, saved for reuse, connected to outside systems, or capable of changing something important. A full contract adds named deliverables, an output structure, required evidence, and a destination.

Do not force YAML, JSON, or a long receipt onto a simple question. Use structured output when another tool will read it, fields must be compared, or omissions would be costly.

Write the work contract

1. Job — one observable result, not a broad ambition.
2. Source of truth — the records, files, accounts, or instructions that govern the result.
3. Deliverables — the exact files, decisions, drafts, or changes expected.
4. Definition of done — measurable conditions that must all be true.
5. Access boundary — tools and systems that may be used, plus actions that are prohibited or need approval.
6. Required evidence — tests, links, diffs, screenshots, receipts, or reconciliations a reviewer can inspect.
7. Output and destination — the human-readable answer, any machine-readable fields, and where artifacts belong.
8. Stop rule — the missing identity, permission, source, or fact that means the agent must pause rather than guess.

Keep access tied to the assignment

Capability is not permission. Give the agent only the tools needed for this job and prefer read, draft, or preview access before write access. A tool that happens to be available is outside the contract unless the assignment needs it.

If the target, payload, timing, price, permissions, or rollback plan changes, get a new confirmation before a consequential action.

Validate before saying complete

Check the original definition of done line by line. Open the artifacts, run the relevant tests, inspect visible output when appearance matters, and name anything that remains missing. A command that exited successfully is only evidence for what that command actually checked.

The result is complete only when every required condition passes. Otherwise report partial or blocked and state the next action.

Return a completion receipt

A useful receipt records:

• status: complete, partial, or blocked;
• requirements satisfied and total requirements;
• artifacts or files created or changed;
• tools and tests used;
• evidence a reviewer can open;
• missing items and the next action;
• whether any action fell outside the approved boundary.

Keep the receipt concise and link to the proof instead of repeating it.

Start from the template

Copy the work contract and completion receipt template. Fill only the sections justified by the task, then keep the completed version beside the resulting work.

Review rule: no completion claim without evidence-backed validation, and no tool use outside the assignment boundary.