Symptom
An entire class of products — crowdfunded items — was excluded from the sourcing policy outright. The reasoning looked solid: "we structurally cannot meet the 7-day dispatch deadline." For goods shipping in one to three months, obviously true. That call kept 41 suspected items across 11 domains and one entire retailer out of the catalog.
Cause
7 days was not the platform's limit. It was a number sitting in our own registration pipeline's canonical-values table:
| dispatch_deadline_days | 7 |A per-product value we send. Raising it to 20 was the whole fix. Not "structurally impossible" — just "a field we never changed."
★★★ Defaults look like constraints. Once a value is a constant in the code, people read it every day and never re-ask "is this something we can change?" If anything, its being tidily listed in a canonical-values table lends it the air of a fixed specification.
★★★ When a policy rests on an impossibility, check where the impossibility comes from — the platform's documentation, or your own code. If it's the latter, it is not a constraint; it is a choice you made. Same shape as don't read a 404 as "the feature doesn't exist" elsewhere in this collection: we read what we hadn't looked for as what wasn't there.
Fix
The detection logic stayed; only what happens after detection changed — from exclusion to inserting a shipping notice and raising the dispatch window. The policy's skeleton was fine; one branch pointed the wrong way.
★ The honest remaining limit: 20 is also a number we picked. An item shipping in three months misses 20 days too. Detection alone is not enough — read the actual estimated ship date and set the field from it. Where that isn't possible, explicit notice in the title and description is the real defense.
How to verify
★★ Demand a citation for every "impossible" in a policy document. An impossibility claim with no platform-doc URL should be suspected of being a constant in your own code. Grepping the codebase for that number takes a minute — we didn't, and excluded a product class for over ten days.
★★★ A second instance turned up the same day — this time an estimate
Another clause in the same policy document excluded an entire price band because "fixed shipping costs make low-priced items structurally unprofitable." Measured, shipping came in at $0, $4, $11, and $32 depending on the supplier. Where shipping is free, that price band is wide open.
| The number it rested on | What it actually was | |
|---|---|---|
| Clause A | dispatch deadline of 7 days | a default in our code |
| Clause B | a fixed ~$20 shipping cost | an estimate of ours |
★★★ Both excluded a product class on the words "structurally impossible," and both numbers were ours. Neither had ever been measured.
★★★ Once an estimate becomes the basis of a policy, the label "estimate" falls off. Only the number survives, and being written in a policy document lends it authority. A constant in code can at least be grepped; an estimate dissolved into prose in a document cannot even be found.
★★ The fix — attach a release condition to every estimate
One note in the same system did this correctly. Using the same estimated shipping cost, it said:
"This shipping cost is an assumption, to be recalculated once real shipping-rate data exists."
★★★ Only the note that wrote down the condition could recognize the condition being met. The day measured data appeared, that item became releasable immediately — while the others still sat there asserted as fact.
★ Rule: when an estimate goes into a document, three things go with it — ① that it is an estimate, ② its provenance (where the number came from), ③ its release condition (what has to exist before you recompute). Miss any one and the number becomes a fact before long.
★ And a broken premise does not invalidate the whole argument. "Where fixed costs are large, repricing cannot rescue the low band" still holds. What was wrong was one premise: that every supplier is like that. Don't throw out the policy — turn the global condition into a per-case one.