An hour threshold is not a change boundary
Most change-order policies we inherit start with an hour threshold: under two hours, just do it; under a day, log it; anything bigger needs a signed change. That ladder feels fair and operational. It also misses the failure mode that actually blows the calendar — a small request that lands on a seam. We treat change boundaries by seam class first, effort second, so a "quick" ask that retunes inventory webhooks or reprint rules does not sneak past the same gate as a copy tweak.
Hours measure effort, not blast radius
Effort thresholds answer a useful question: how much calendar does this eat if everything stays the same shape? They do not answer whether the system stays the same shape. Renaming a button is an hour. Changing when an order becomes sellable is also "about an hour" if you only count the code — and a week if you count the states that break when the rule moves.
We have watched teams absorb a string of sub-threshold asks and still land late. None of the individual requests looked large. Together they rewrote the contract between surfaces: the theme, the catalog, the kitchen ticket, the return path. The hour counter stayed green. The seam did not.
So we keep hour estimates. We stop using them as the only gate. A change that stays inside one surface and one already-agreed behavior can move on a light path. A change that crosses a seam — another system, another owner, another invariant — gets the heavier path even when the patch looks small.
Name the seam classes up front
In scoping we already talk about seams: Shopify webhooks, OCR layouts, device backgrounds, CMS publish rules. Those same labels belong on the change-control note. We write three classes into the project notes before kickoff so mid-flight triage is not invented under pressure.
Surface-local means copy, layout, or behavior inside a boundary we already own and already tested. Cross-surface means two of our surfaces must agree on a new contract — web and field app, studio and storefront, order form and ticket printer. External-seam means someone else's system, data, or device has to move with us: a vendor PDF, a payment method, a webhook payload, an OEM battery policy.
The class decides the process. Surface-local can be a logged micro-change with a same-day note. Cross-surface needs an explicit impact check on both sides before work starts. External-seam needs a spike or a signed decision, because the calendar risk is not our typing speed — it is their behavior.
The small request that moved inventory
A familiar pattern: "Can we just hide out-of-stock variants on the collection page?" It sounds like a template filter. On a commerce build it can mean changing how available quantity relates to what the storefront is allowed to sell, how restocks reappear, and what a return inspection puts back into the pool.
Measured in hours, the first PR is short. Measured as a seam class, it is external and cross-surface: catalog truth, storefront rules, and warehouse disposition all have to say the same thing. Treating it as a micro-change is how you get a page that looks right while orders and restocks disagree.
The same trap shows up in document automation. "Just map this one new column" can be a field rename — or a silent rewrite of the invariant that refuses bad extractions values. If the change touches the gate, it is not a column. It is a seam.
Write the boundary into the scope, not the vibe
A policy that lives only in someone's head becomes generosity under calendar pressure. We put the classes in the scoping notes next to the assumption log: what counts as surface-local, what forces a cross-surface check, what forces a seam spike or a signed change before code moves.
We also name who can reclassify. The person who wants the change is rarely the right person to decide it is "just a couple hours." The owner of the seam — usually whoever spiked it in discovery — gets the call. If that owner is unavailable, the change waits or gets a short written impact note, not a verbal pass.
This is the same discipline as assumption triggers and estimate ranges. The artifact is not bureaucracy. It is a shared definition of which requests are allowed to stay quiet and which ones must reopen the schedule on purpose.
What we put in the scoping notes now
A short change-boundary section: three seam classes, one example each from this project, and the process each class uses. Hour ranges can sit beside them as capacity hints — not as the gate.
A named seam owner for every external integration we already flagged in discovery. Mid-project triage routes there first.
A one-line rule the whole team can repeat: small effort can still be a seam change; seam changes do not use the micro path. That sentence prevents a polite Slack thread from becoming the architecture.