The Task Contract
Understand the explicit authorization boundary that turns a request into bounded, reviewable implementation work.
A Task Contract is the approved operating boundary for one unit of work. It is not just a summary of the request and it is not a giant prompt that tries to control every line of code.
It makes the important parts explicit before implementation begins:
- the outcome being requested;
- the project evidence that supports the task;
- what the AI may change;
- what must remain unchanged;
- acceptance criteria;
- relevant checks;
- stop conditions.
Generating a Task Contract does not authorize implementation. The developer reviews and approves it first.
Task Contract and Task-Contract Development
Task-Contract Development is the broader approach implemented by TCAF. It integrates spec-driven planning, agentic/harness execution and software delivery governance into explicit, bounded and verifiable units of change.
The Task Contract is the mechanism that makes that approach concrete for one unit of work. It connects the intended outcome to execution authority, preservation requirements, verification and human control.
Why a request is not enough
A request such as “add export to CSV” can describe the result clearly while leaving scope, affected files, existing patterns and verification implicit. An AI model can fill those gaps with assumptions.
The Task Contract exposes those assumptions before they become code.
What a useful contract contains
Task source
Where the work comes from: a developer request, backlog item, issue, specification, bug report or another declared source.
Objective
The observable result that should become true after the task.
Pertinent evidence
Only the repository facts needed for this task: current behavior, relevant architecture, existing methods or services, constraints and material uncertainty.
Allowed edit surface
The files, modules or behavioral areas that may need to change. It should be large enough for a coherent implementation but small enough to keep unrelated work out.
Preserved areas
Behavior, files, interfaces, validations, dependencies or other areas that must remain unchanged.
Acceptance and verification
Observable completion criteria plus the smallest relevant automatic or manual checks. Executed checks and DEVELOPER_RUN checks must remain distinguishable.
Stop conditions
Conditions that require the AI to stop instead of improvising: contradictory evidence, scope expansion, a missing dependency, an unapproved architectural decision or a destructive operation.
Review before approval
Before approving, check that the objective matches the real request, assumptions are supported by evidence, the edit surface is proportionate, existing behavior and developer edits are protected, and the checks are realistic.
If a substantial new decision appears, amend the contract or create a separate task instead of silently enlarging the current one.
Approval and execution
After approval, the AI can execute the approved work inside that boundary while respecting the current repository state.
The developer remains free to edit code, replace an approach, stop the run or perform part of the work manually. Those changes become current project state and must be re-read before the AI continues.
Relationship to preservation-first
The Task Contract defines what may change. Preservation-first defines how that change should fit the software that already exists.
Together they keep the requested delta explicit without freezing legitimate engineering decisions or authorizing unrelated rewrites.