Write down what you are not doing
Every dispute about delivered work is a dispute about something nobody wrote down. Not about quality, and rarely about price — about whether a thing was in the job.
The exclusions are the document
A scope that lists only what you will deliver is an invitation to argue, because the reader fills the gaps with their own assumptions and they are not unreasonable to do so.
The useful version says what is not included: which data sources are out, which edge cases go to a human, what happens when the upstream system changes, how many revisions, and who is on the hook at 2am. None of that is pessimism. It is the part the client is actually buying clarity about.
Scope one real job
Take a job you might genuinely do — for a client, an employer, or your own business. Write two lists.
In: the specific deliverables, with the measurable condition that says each one is finished.
Out: at least eight exclusions. If you cannot find eight, you do not yet understand the job well enough to price it, and that is the finding.
Six weeks in
Mid-project, the client asks for something reasonable, small, and not in the scope. It would take you two days.
How many exclusions did you find?
Count them. Then note which single one you think is most likely to be the argument, because that is the one to raise out loud before signing rather than to bury in a document.
Save the scope
Keep it somewhere you can link to. This is a reusable asset — the exclusions list for your second job is mostly your first one, and it gets better every time something goes wrong.