April 8, 2026
· 8 min read· OmniTakeoff TeamCatching decimal-place typos with regional cost bounds
Across pilot data, a meaningful fraction of catastrophic typos per bid survive review and land in the final number. Most are decimal-place errors. Here's the structural fix.
We track 'bid-day defects' on every pilot. Across our pilot cohort the average defect rate per bid is meaningfully higher than teams typically realize, and a notable fraction of those defects survive review and land in the final number. Most of the survivors are decimal-place typos. Specific cohort counts are shared under NDA on reference calls rather than published.
Why this is structural, not stylistic
Estimators check their work. They print the bid, mark it up, run it past a second pair of eyes. Defects survive anyway. Why? Because the human visual system isn't reliable at catching decimal-place errors in dense numerical data. The estimator looks at $160/LF and the brain auto-corrects to $16/LF if they expected $16. Confirmation bias is fast and silent.
The fix isn't training estimators harder — they're already trying. The fix is mechanical: bound-check every line item against an objective range that doesn't care about the reader's expectations.
Two signals we use
- Regional cost bounds — every (CSI division, unit) pair has a US-average floor + ceiling, scaled by an ENR city cost index for the project's location. Outside the band → warning. >5x outside → error.
- Org-history outliers — when the org has historical avg unit cost for the same (division, unit), flag any line ≥3x or ≤⅓ that average. Catches typos that are within the regional band but obviously wrong vs. how this org has bid before.
We deliberately tuned the system to err toward false positives over false negatives. A warning the estimator dismisses costs 5 seconds. A defect that survives costs the bid.
What's NOT in scope
Semantic defects — wrong product spec, missing scope item, code violation — still need human review. We can't catch those with bound checks. But typos and decimal-place errors should be a solved problem in 2026.