{{project}} / scope owner {{business}} / approver {{contact}} / target {{deadline}}

Purpose: establish a baseline someone else can check. Replace vague words such as 'simple', 'finished', or 'as needed' with quantities, boundaries, and evidence.
Baseline version/date: [ ]; agreement reference: [ ]; approval authority: [ ].
Buyer/user task: [What should the delivered work enable?]

Deliverable ID | output and quantity | included work | excluded work | acceptance evidence | reviewer
D1 | [named output] | [limits] | [likely assumption] | [observable check] | [name]
Inputs/dependencies: [item / owner / due date / effect if unavailable]
Feedback: [number of rounds / consolidated feedback owner / agreed response window]
Working milestone dates: [dependencies and approval points]; target is conditional on [ ].

Definitions to agree
A revision changes the agreed work within an included round and boundary. A change adds or alters a deliverable, quantity, requirement, or dependency. A defect fails a stated acceptance criterion. Check the actual agreement for treatment; a request is not extra-charge work merely because it arrived late.

Open question | effect on scope or date | resolver | due | proceed/hold
[Question | consequence | owner | date | decision]
Do not mark the baseline approved while a material boundary is unknown.

Baseline decision: approved / revise / waiting for evidence.
Authorized approver, date, and reference: [ ].
Keep this version. Subsequent changes create a new version linked to the decision record; these notes alone do not modify contract terms.

Your decision
Can each deliverable be accepted or rejected against a stated criterion?
My answer: [ ]
Source and date: [ ]
Still to check: [ ]
Next action, owner, and due date: [ ]

Before you start
- Deliverable list: [Source or notes]
- Approval owner: [Source or notes]
- Revision expectations: [Source or notes]

What you will make
An agreed scope, acceptance criteria, and a record of requested changes.