A clarification is not a change request
Mid-project asks arrive as Slack one-liners and demo asides. Some are missing acceptance criteria for work that was already in the signed intent. Some are new surfaces, new roles, or new integrations wearing the language of a tweak. Mixing those two is how a clarification silently expands the build and how a real change gets absorbed without a written decision. We classify the ask before we estimate it.
Two different animals share one Slack thread
A clarification answers: what did we already agree to mean. The order ticket should show gift vs delivery notes separately. The CMS handover includes the redirect map. The field app reuses the same session as the dashboard. Those lines may have been underspecified in the brief, but the outcome was on the page.
A change request answers: what are we newly agreeing to do. Add a wholesale quote path beside the cart. Stand up a second print destination. Expose a public API the original scope treated as internal. The work may be small in hours and still be new in outcome.
Teams get into trouble when they treat tone as taxonomy. Soft voice does not make a change a clarification. Firm voice does not make a clarification a change. The test is whether the signed scope already claimed the outcome — not whether the ask felt polite.
Map the ask back to evidence
Before we argue categories, we open the discovery notes, the assumption log, and the signed scope language. If the request maps to a line we already wrote — even awkwardly — it is a candidate clarification. The work is to write the missing acceptance criteria and any refusal or recovery paths the happy-path brief skipped.
If the request does not map, it is not a clarification waiting for friendlier wording. It is new scope until someone deliberately trades something else out or signs a change. We have watched projects burn a week debating whether a feature was "implied." Implication is not a category. Traceability is.
This is the same discipline as logging assumptions as falsifiable statements. Clarifications close underspecification. They do not invent deliverables that never appeared in the evidence. When two reasonable readings of the scope disagree, we treat that ambiguity as ours to resolve in writing — then classify what remains.
- Maps to signed intent or discovery evidence
- Missing criteria, not a new outcome
- Write acceptance the same day
- Still name refusal and recovery paths
- New outcome, surface, role, or integration
- Does not map to the signed claim
- Needs a written decide: yes / no / later
- Then classify by seam — not by Slack tone
Category first. Seam class and estimate second.
Trade is a third label, not a loophole
Sometimes the client wants to swap one in-scope item for another of similar weight. That is a trade: still inside the envelope, with a written swap so the dropped item does not resurrect in week six. A trade without a recorded drop is just a change with better manners.
We keep trades short and explicit. What leaves, what enters, who agreed, on what date. The backlog gets the new acceptance criteria; the change log keeps the swap. Memory is not a swap.
Bugs are not clarifications and not changes. They are defects against work we shipped, named plainly, fixed without ceremony. Mislabeling a bug as a change trains the wrong fight. Mislabeling a change as a bug trains silent expansion.
Classify the same day, in one place
The failure mode is not missing a fancy tool. It is letting the ask live only in a thread until someone builds it. We capture every mid-project ask in one shared change log the same working day: what was asked, which category, which evidence line it maps to, and the decision if one is required.
Clarifications still get written. They earn acceptance criteria and a check that the happy path is not pretending to be the whole scope. Changes get a decide step — yes, no, or later — before they enter the build queue. Later is a real answer; an unlabeled maybe is how requests rot and then reappear as urgency.
This sits beside, not instead of, seam-class thinking. A clarification can still touch a fragile integration and deserve a spike. A change that sounds like half a day can still move a payment or print seam. Hour count is not the category. Category is not the seam. You need both names or you will optimize the wrong one.
What we write when the ask arrives
Four lines are enough: the ask in the client's words, the category, the evidence link or the explicit "no map," and the next action — write criteria, record a trade, or open a change decision. If we cannot fill those four lines, we are not ready to pull work into the sprint.
On BuilderHelp-shaped platforms and commerce pipelines like Al's Flowers, the asks that look smallest are often the ones that cross a surface: dashboard vs field app, cart vs quote, ticket reprint vs void. Category errors there do not stay polite. They show up as duplicate paper, split sessions, or a scope that quietly became two products.
The point of the ritual is speed to a shared name, not theater. Once clarification, trade, and change are spoken aloud, the rest of the scoping habits — ranges instead of single numbers, assumptions that are not decisions, seams spiked before the calendar locks — have something solid to attach to.
Questions
- How do you tell clarification from change when the SOW is vague?
- Open the discovery evidence and assumption log. If the outcome was claimed and only the criteria are missing, write the criteria as a clarification. If the outcome was never claimed, it is a change — vagueness in the SOW does not invent deliverables.
- Does a clarification skip seam review?
- No. Category and seam class are separate. A clarification that lands on a webhook, payment, or print path can still need a short spike before acceptance is closed.
- What is a trade?
- A written swap of one in-scope item for another of similar weight, with the dropped item recorded so it cannot reappear as assumed work later.
Sources
- Change requests without the fight (clarification vs change vs trade) — 2026 agency practice on same-day categorization of mid-project asks
- Evidence-linked requirements (2026) — Requirements as conclusions tied to operational evidence, not free-floating statements
- Specification ambiguity vs scope creep — Ambiguous agreement is a different failure mode than adding new work