Every statement of work has a list of what you will deliver. Open yours and look for the other list — the one that says what you will not.
If it is not there, then the boundary of the engagement exists only in your memory of a conversation, and the client has their own copy of that memory. Neither of you is lying when they disagree.
The engagement record in these components has two scope sections rather than one: ## Scope — what is in, and ## Scope — what is explicitly out. The second carries an instruction, and the instruction is more specific than it first looks:
Copy this straight from the exclusions section of the winning proposal. Not a summary of it.
"Not a summary of it" is the operative part. A summary is a new document. You write it after the proposal is signed, from memory, while feeling good about the engagement, and it will be softer than the text the client agreed to — not through dishonesty, but because that is what summarising does. When the boundary is tested, the softer version is the one you have to hand.
The literal paragraph costs one paste and is the only version that still means what both sides agreed it meant.
Underneath sits ## Assumptions we priced on. Its instruction states the mechanism outright:
Every one of these is a scope change waiting to happen. When one turns out to be false, that is not bad luck — it is a scope change, and it should be recorded the same day.
An assumption is a statement that can be true or false: the client's data is in one system, the subject-matter expert is available weekly, the legacy export already exists. Each one has a day on which it stops being true, and on that day the work you priced and the work in front of you are different work.
What makes the list valuable is not foresight. It is that the falsification becomes visible. If the assumption was never written down, nothing marks the day it failed — the extra work simply arrives, and it arrives as effort rather than as a change. Writing the assumption down in advance is what converts a quiet overrun into a dated event with a cause.
The sentence to borrow when it happens is the template's own: that is not bad luck — it is a scope change.
A scope change needs somewhere to land, and it is not the commitments list — that holds what each side will do. What happened is a different record.
The meeting note template carries a ## Decisions section for exactly this, with a rule attached:
Things that are now settled. A decision is different from a discussion, and only decisions go here. If it can still be reopened, it belongs above.
So: the assumption failed, you raised it, and the client agreed the deadline moves — that is a decision, in a dated note, attached to the engagement. The template also keeps ## Risks and blockers surfaced separate, which is where the same assumption goes while it is still only wobbling.
Three different states, three different places: still true but doubtful, settled, and the work each side now owes.
One more field, and it is a question rather than a plan. The engagement's frontmatter carries change_control, a boolean, documented in the field reference as is change control written into the contract?
It is answered once, when you create the engagement, and the Governance table next to it records the same thing in prose alongside the escalation route, the steering cadence and the acceptance authority.
A false here is not a failure. It is a fact you now hold on purpose: when an assumption turns out false, there is no contractual process to invoke and the conversation will be a negotiation. Knowing that at the start changes how carefully you write the exclusions. Discovering it when the assumption fails changes nothing, because by then you have already done the work.
Note that change_control is not one of the three fields the template requires before you set status: active — those are acceptance_authority, days_sold and end_date. It is a field you should fill, not a gate the template enforces.
Four things, all of them written before the work starts:
## Scope — what is explicitly out.change_control answered, and the Governance table filled in next to it.## Decisions section in every meeting note, kept separate from commitments and from risks.Then one habit: when an assumption turns out to be false, write it down that day — as a decision if it is settled, as a risk if it is not.
None of this requires a plugin. The scope sections are headings and the fields are plain frontmatter in a markdown file, which means they are greppable, diffable and yours.
The engagement and meeting-note templates described here are published as a free, MIT-licensed repository:
https://github.com/engagementdesk/obsidian-consulting-components
The scope sections, the assumptions section and the change_control field are in templates/engagement.md; the ## Decisions section is in templates/meeting-note.md. Every property named in this article is listed with its type and its permitted values in the field reference: README.md.
They are designed for Obsidian, which is free to download and published by its own publisher under that publisher's own terms. The tracker queries that come with the components use Dataview, a community plugin, MIT licensed, installed by you from its own author under its own licence — no plugin code is bundled by us. Nothing described in this article uses a query, so nothing here needs a plugin at all.
More guides on running client engagements in Obsidian: all guides.
---
Engagement Desk is not affiliated with, endorsed by, or supported by Obsidian or by the author of Dataview. Those are separate products from separate publishers, distributed under their own terms.