The Contract Gap: What Is Almost Never Specified
A standard civil engineering engagement contract will specify:
- Horizontal accuracy (e.g., ±0.05 ft 2-sigma)
- Deliverable format (AutoCAD DWG, Shapefile)
- Survey methodology (RTK GNSS, Total Station)
But rarely specified — and dangerously omitted:
- The exact datum realization (NAD83(2011) vs NAD83(HARN) vs NAD83(NSRS2007))
- The epoch of the coordinates
- The GNSS reference frame (WGS84 G1762 vs ITRF2014)
- The required transformation tool (NADCON5, VERTCON3)
- The geoid model used for orthometric height conversion
When a dispute arises, the absence of these specifications means the professional is judged against the ambiguous "prevailing standard of care" — which is increasingly interpreted to include current NGS guidance on datum handling.
How Datum Ambiguity Triggers Claims
The following scenario illustrates the mechanism:
1. Client provides existing site plan in NAD83(HARN) [2003 vintage]
2. Surveyor performs GNSS survey, outputs NAD83(2011) coordinates
3. Difference between NAD83(HARN) and NAD83(2011) in CONUS: 1–50 cm depending on location
4. Client's CAD operator overlays data assuming same datum — 10–50 cm offset appears
5. Building staked 0.3 m off design location; discovered at foundation inspection
6. Re-staking, concrete demolition, and delay claim: $180k
7. Surveyor's contract says "NAD83" — no realization specified
Required Contract Language (Model Clauses)
Professional organizations recommend the following contract specification language as minimum datum definition requirements for geodetic work:
transformed using NADCON 5.01 via NGS NCAT.
Vertical elevations shall reference NAVD88 (EPSG:5703),
using GEOID18 for ellipsoid-to-orthometric conversion.
GNSS baselines computed relative to NGS CORS stations."
This level of specificity eliminates ambiguity about which NAD83 realization is required — a difference that can be centimeters to decimeters depending on location and vintage.
Datum Specification Risk Matrix
| Missing Contract Element | Potential Error | Liability Exposure |
|---|---|---|
| Datum realization not specified | NAD83(1986) vs (2011): 1–50 cm | MEDIUM |
| WGS84 frame not specified | WGS84 vs ITRF2014: 2–4 cm | LOW–MEDIUM |
| Vertical datum not specified | NGVD29 vs NAVD88: 0.3–0.5 m | HIGH |
| Geoid model not specified | GEOID12B vs GEOID18: 5–20 cm | MEDIUM |
| Transformation tool not specified | Helmert vs NADCON5: up to 1 m | HIGH |
✅ Pre-Submission Compliance Checklist
- Specify exact datum realization in all contracts (e.g., NAD83(2011) not just 'NAD83')
- Specify the epoch of coordinates for high-accuracy work near tectonic boundaries
- Explicitly name the vertical datum (NAVD88 EPSG:5703) in all civil engineering contracts
- Name the geoid model required for ellipsoidal-to-orthometric conversion (GEOID18)
- Identify the State Plane zone or projection system explicitly
- Require client to provide all existing data with explicit datum documentation
- Include a clause requiring client sign-off on datum reconciliation when mixing data vintages
- Retain transformation logs and software version records for the full liability period
Frequently Asked Questions
Does a contract saying 'NAD83' protect me legally?
No. 'NAD83' alone is ambiguous — there are multiple realized versions of NAD83 differing by up to 1 meter across the CONUS. Professional standards now require specifying the realization (e.g., NAD83(2011)) and epoch to be unambiguous.
Who is responsible for reconciling mismatched datums on a project with multiple data sources?
Absent specific contract language, courts typically assign responsibility to the licensed professional of record who integrates the data. This means surveyors and engineers who overlay client-furnished GIS data with their own GNSS data without explicit datum reconciliation bear the integration risk.
Is datum reconciliation billable?
Yes — and it should always be explicitly scoped in the contract. Datum reconciliation (transforming historic data to match the project datum) can consume significant professional time and requires NGS tooling. Treating it as included overhead is a systematic profit-reduction error.