Lists describe activity. Contracts define success
A checklist says what steps someone intends to take. A task contract says what result must exist, what conditions make that result acceptable, and what the system is allowed to do while producing it.
The difference matters when an agent changes its plan. A new step is not automatically a change in the objective. The contract gives both the user and the system a stable reference point.
The five parts of a useful contract
These fields are not administrative metadata. Each one changes what the execution engine can do and what evidence the final package must contain.
- Intent: a concrete description of the result to produce.
- Acceptance: structural, semantic, and human checks that define completion.
- Constraints: deadline, budget, data boundary, and forbidden actions.
- Authority: which capabilities may run automatically and which require confirmation.
- Checkpoints: when the task must pause before continuing.
Version the agreement, not the transcript
Sometimes the user genuinely needs to revise the task. The scope may become narrower, the deadline may move, or a newly discovered dependency may require another source.
That change should create a new contract version with a reason. The original purpose is not overwritten. The task keeps both the decision and the conditions under which it was made.
A contract makes a result reviewable
At acceptance, the user should not have to remember what they originally intended. The delivery package is checked against the accepted version. Every criterion has a result. Every exception is visible.
This is why LibreTask starts with the contract. The agreement is the first durable object in the task, and everything that follows points back to it.