How to Validate Drillhole Data Before Resource Estimation
80% of resource model errors start with bad collar, survey, or assay data. Here's the 6-step QA checklist that catches problems before they cost you a feasibility study.
A resource model is only as good as the data underneath it. And in 12 years of looking at exploration databases, the same five problems keep showing up: duplicate collar IDs, surveys that disagree with downhole depth, assay intervals that overlap, lithology codes nobody documented, and the silent killer — partial data that looks fine until you actually start estimating.
This post walks through the 6-step validation checklist I use on every project before starting EDA. It’s not exhaustive. It’s the minimum to avoid embarrassing errors later.
Why this matters
JORC 2012 Table 1 Section 1 and KCMI 2017 both require you to disclose your data validation procedures. “I trusted the database” is not a procedure. Your Competent Person needs to be able to point at concrete checks — and so do you, when an investor’s technical advisor starts asking questions.
More practically: a bad assay interval at 80m depth in one hole won’t change your global mean. A systematic error — like all REVERSE-CIRCULATION holes having a survey offset of 3° because the survey tool wasn’t zeroed — will silently shift your entire variogram and skew your kriging.
The 6-step checklist
1. Collar validation
Before you load anything else, the collar table must be clean.
Checks:
- Unique hole IDs — no duplicates. If you see
TRRC014twice, one is wrong. - Coordinate ranges — are easting/northing within the project area? An 8000 km offset is a real thing that happens when someone enters UTM zone wrong.
- Elevation sanity — does collar elevation match topography (DEM check)? Holes that “start underground” are a red flag.
- Hole type — DDH, RC, AC labeled consistently. Mixed casing breaks downstream filters.
Decision gate: 100% unique IDs, all coordinates in project bounding box, elevation within ±10m of DEM.
2. Survey validation
Surveys are where projection errors hide.
Checks:
- Azimuth range: 0–360°. Any 999, -1, or blank is a flag.
- Dip range: -90° to 0° for downhole drilling (most common convention). Positive dips? Re-check sign convention.
- Depth monotonic: surveys must go DOWN, not jump backward.
[15, 30, 25, 60]is broken. - Survey interval: typical 30m for DDH, 6m for RC. Gaps >50m without explanation are suspect.
- Final depth match: last survey depth ≤ final hole depth. Not the other way around.
Decision gate: All azimuths 0–360°, all dips negative or zero, depths monotonic, no unexplained gaps.
3. Assay validation
This is where most issues live, because assay tables are the largest.
Checks:
- From-To overlaps:
[10–15, 12–18]is broken. Adjacent intervals can share a boundary, never overlap it. - From-To gaps: gaps without a “no sample” reason recorded? Investigate.
- BDL flags: below detection limit values — are they encoded as
-1,0, half-detection-limit, or text"BDL"? Pick one convention and verify. - Negative grades: should never exist (except as BDL placeholder).
- Duplicate samples: same hole-from-to with different grade? Investigation, not deletion.
- Unit consistency: gram-per-tonne (Au) vs ppm (base metals) — don’t mix.
Decision gate: 0 overlaps, BDL convention documented, 0 unexpected negatives, duplicate sample IDs reconciled.
4. Geology validation
Lithology drives domain separation. Bad lithology = bad domains = bad estimates.
Checks:
- Code consistency:
GRT,Granite,graniteare three different codes to a database. Standardize. - Missing intervals: every depth interval should have a lithology code.
nulllithology in the middle of a hole is a data entry error. - Code count: typical project has 5-15 lithology codes. 50+ codes means someone got creative — consolidate.
- Major-Minor structure: if you have
MAJOR_LITHandMINOR_LITHcolumns, both should be coded consistently.
Decision gate: Lithology code dictionary documented, 0 missing intervals, ≤20 unique codes (after consolidation).
5. Visual inspection
Numbers can pass all of the above and still be visually wrong. Eyes catch what scripts miss.
Checks:
- Strip log per hole (random sample of 5-10 holes): do lithology bands and grade curves look geologically reasonable?
- Cross-section (at least 2 azimuths): are holes spatially clustered as expected? Outliers in 3D space?
- Hole length distribution: histogram of
final_depth. Any holes <5m? That’s likely an aborted hole — flag or remove. - Sample interval distribution: histogram of
to - from. Bimodal distributions usually mean someone changed sampling protocol mid-project.
Decision gate: Subjective — but you should be able to say “I looked at strip logs for holes X, Y, Z and they’re consistent with the geological model.”
6. Cross-table joins
The final check is whether your tables actually connect.
Checks:
- Collar ↔ Survey: every hole in collar table has at least one survey record. Holes with no survey can’t be desurveyed.
- Collar ↔ Assay: every assay record points to a valid hole ID. Orphan assays from deleted holes are a thing.
- Hole length consistency: max assay depth ≤ collar
final_depth≤ max survey depth. Inconsistency = data entry mismatch.
Decision gate: 100% join completeness across collar/survey/assay/geology.
What good validation output looks like
For each project, I output a 1-page validation summary:
| Check | Pass/Fail | Notes |
|---|---|---|
| Unique collar IDs | ✓ | 40 holes, 0 duplicates |
| Coord in bbox | ✓ | 100% within project polygon |
| Survey azimuth range | ✓ | All 0–360° |
| Survey depth monotonic | ✓ | All holes |
| Assay overlaps | ✓ | 0 overlaps detected |
| BDL convention | ✓ | -1 = BDL, documented |
| Lithology completeness | ⚠️ | 3 intervals missing in TRRC008 — flagged |
| Strip log review | ✓ | Sampled 8/40 holes |
| Section view | ✓ | Two NS sections, no spatial outliers |
| Cross-table joins | ✓ | 100% join completeness |
That table is what gets attached to your Table 1 Section 1 disclosure. No table = no data validation = JORC concern.
Automating this
Manual validation on a 40-hole project is a half-day. On a 400-hole project it’s a week. That’s why I built Orebit Corelhole Prep (Phase 01) — every check above runs automatically when you upload your CSVs:
- Auto-detects column mappings (no manual schema setup)
- Flags overlaps, gaps, BDL values, code inconsistencies
- Generates strip logs and cross-sections in one click
- Outputs a JORC-aligned validation report (PDF + CSV)
- 100% offline — your data never leaves your laptop
Phase 01 covers steps 1-6 above. Phase 02 (Orebit Assay) extends into bivariate/multivariate analysis. Phase 03 (Orebit Resourcee Estimation) handles variography and kriging. Once your data is clean, the compositing guide walks through picking the right composite length, and the resource estimation mistakes post shows what happens when validation is skipped.
One-time payment: IDR 49K per module / IDR 99K full bundle. No subscription. Buy once, use forever.
Bottom line
Drillhole data validation isn’t glamorous, but it’s the work that separates a Resource Estimation Report you can defend from one that gets re-done by an external auditor. Six steps. Half a day with manual tools. Three minutes with Orebit.
Either way — do the work.
Got a validation horror story or a check I missed? Email me at hello@orebit.id. I read everything.
Part of the Orebit ecosystem —
geological workflow tools for drillhole validation, resource estimation, and JORC/KCMI reporting.
→ Explore GeoSuite
Try the toolkit this article uses.
Orebit GeoSuite — single-file HTML, works offline, no install. From CSV to resource report in one afternoon.
Explore GeoSuite →# From this article: open geosuite.orebit.id load(your_drillhole.csv) apply(workflow_above) # Done. Ship the report.