Scope of work

The scope of work is the contract's answer to "what, exactly, am I buying." It describes the work, the deliverables, the standards to which they are done, and — the part that decides disputes — the boundaries: battery limits, interfaces with other contracts, inclusions and exclusions, who supplies what to whom. On a multi-contract project, the scopes are a jigsaw cut by the owner, and the cutting is a design act: every interface created is a coordination obligation someone must hold.

Scope fails at the seams, in two directions. Gaps — the item that falls between two contracts, described in neither, bought by no one — surface late, priced by whichever party is asked to absorb them, at post-award rates. Overlaps are quieter: the same work bought twice, discovered at payment if at all. Both are why interface registers and scope matrices exist, and why the exclusions list — read casually at award, forensically at claim — deserves its drafting time.

The recurring drafting sin is description by reference: scope defined as "all works shown in the documents," inheriting every inconsistency those documents contain and converting each one into a scope argument.