An assumption is not a signed decision
Scoping notes are full of sentences that sound settled and are not. "API access will be ready in week one." "Editors will fill every required field." "The print vendor accepts the same PDF we generate today." Those lines are assumptions masquerading as decisions. We write them down as assumptions on purpose — with an owner, a way to check them, and a named trigger for what happens when they turn out false — so the project does not absorb the surprise as unpaid scope.
What looks like agreement in a workshop
In a discovery workshop, people nod. Someone says the catalog export is clean. Someone else says the third-party sandbox will be open before kickoff. Nobody objects, so the sentence lands in the notes as if it were decided. Later, when the export arrives with missing SKUs or the sandbox ticket is still in a queue, the build team discovers they were carrying an assumption that never had an owner.
The failure mode is not optimism. It is format. An assumption written like a fact invites nobody to challenge it. A decision has a chooser and a consequence. An assumption needs both of those too, plus a date by which it must be checked — otherwise it is just hope that traveled into the schedule.
We have seen this on commerce seams and content handoffs alike. Shopify credentials that "will be in the shared vault," Sanity schemas that "match what marketing already uses," OEM devices that "behave like the Pixel we tested." Nodding is cheap. Naming who proves the sentence true is the actual work.
Write assumptions so they can fail in public
A useful assumption is a sentence you can prove wrong. "Product CSV arrives with SKU, title, price, and inventory columns for every active variant by kickoff" can be checked against a file. "Product data will be fine" cannot. The first version creates a validation task. The second version creates a mid-project argument.
Each row in our assumption log carries the statement, who owns validating it, how we will validate it, by when, and what changes if it is false. The last field is the important one. If the CSV is late or incomplete, the trigger might be: slip ingest by one sprint, or add a manual mapping pass, or cut the first launch to a subset of SKUs. Without that trigger written in advance, every broken assumption becomes a negotiation under deadline.
We keep the log short. Ten sharp assumptions beat forty vague ones. Prefer the seams: credentials, data quality, device behavior, third-party rate limits, who edits which CMS fields after launch. Those are the places a polite workshop nod turns into calendar damage.
The change-order trigger is part of the assumption
An assumption that fails without a pre-agreed response becomes invisible scope. The team just works longer. That is how "small" integrations grow a second spine. We treat a failed assumption as a change trigger: stop, re-estimate the affected slice, write down the delta, get an explicit yes before continuing on the new path.
That does not mean every surprise needs theater. It means the response is chosen, not absorbed. On a florist ticket pipeline, if PrintNode acceptance behaves differently than the spike showed, the next step is a scoped change — retry policy, printer monitoring, or a narrower launch — not a quiet weekend of heroics. On a field app, if offline sync assumptions from the spike do not hold on the OEM devices that matter, the sync budget gets re-cut in the open.
The point of writing the trigger early is social as much as technical. Both sides already agreed what "false" costs before anyone is embarrassed. The conversation is about which option to take, not whether the original smile in the workshop counted as approval.
Review open assumptions like unfinished work
Assumptions rot if they only live in a kickoff deck. We put open ones on the weekly checklist next to blockers. Anything past its validation date is either confirmed, rewritten, or escalated. Confirmed assumptions graduate into decisions or acceptance criteria. Invalidated ones fire their trigger.
This is also how we keep estimates honest after a range was published. A single number is not an estimate; an estimate that never revisits its assumptions is just a frozen guess. When a seam assumption clears, we tighten the band for that slice. When one fails, we widen or re-cut before the calendar pretends nothing happened.
If an assumption cannot be validated until late in the build, we say that out loud and keep contingency attached to that slice — not as a vague percentage over the whole project, but as a named fork still sitting in the log.
What we put in the scoping notes now
A short assumption table sits next to the happy-path scope and the refusal paths. Columns: statement, owner, validation method, due date, impact if false, trigger. We refuse to leave critical seams as workshop atmosphere.
Decisions are listed separately. "We will keep checkout on Shopify" is a decision. "Vendor PDF layouts will match last quarter's samples" is an assumption until someone checks a fresh batch. Mixing those two categories is how projects inherit false certainty.
When kickoff starts, every high-impact assumption either has a validation task on the board or an explicit reason it cannot be checked yet. That is the bar. A signed SOW full of unowned assumptions is not a plan — it is a delay with formatting.