Drillhole Database Management: From Field Log to Resource Estimate

The most expensive data corruption I’ve seen wasn’t caused by a software bug. It was caused by a geologist at a field camp in Kalimantan who sorted an assay spreadsheet by the Au column without selecting all columns. The hole IDs stayed in place. The assays shifted down by 12 rows. 84 samples were assigned to the wrong hole. The error propagated through compositing, variography, and kriging. The resource statement was published with the wrong data. The error was caught six months later during a due-diligence review — by me, checking a single high-grade intersection against the original lab certificate.

This is not a rare type of failure. Drillhole databases are fragile, and the way they’re managed on Indonesian projects — field camp spreadsheets emailed to Jakarta, merged into a master file, re-exported for estimation — creates multiple points of failure. The drillhole validation checklist catches data quality issues at the estimation stage. This post is about preventing the issues at the management stage, before they reach estimation.

The four-table structure

Every drillhole database has four core tables. Understanding their relationships is the foundation of data integrity.

1. Collar table

One row per hole. Contains: hole_id, easting, northing, elevation, max_depth, hole_type (DDH/RC/AC), azimuth, dip.

Primary key: hole_id. Must be unique. No duplicates, ever.

2. Survey table

One row per downhole survey station. Contains: hole_id, depth, azimuth, dip.

Foreign key: hole_id → collar.hole_id. Every survey hole_id must exist in the collar table.

Integrity rule: Survey depths must be ≤ collar.max_depth for the same hole. A survey at 250m depth on a hole with max_depth of 200m is a data error.

3. Assay table

One row per assay interval. Contains: hole_id, from, to, Au, Cu, Pb, Zn, Ag, … (as many elements as assayed).

Foreign key: hole_id → collar.hole_id.

Integrity rules:

• from < to for every row
• No overlapping intervals within the same hole
• No gaps larger than the sampling protocol allows (e.g., if you sample every 2m, a 10m gap is suspicious)
• BDL (below detection limit) values must be coded consistently (e.g., -1, 0, or the detection limit value — pick one and document it)

4. Geology table

One row per logged interval. Contains: hole_id, from, to, lithology_code, weathering_code, alteration_code, structure_code.

Foreign key: hole_id → collar.hole_id.

Integrity rules: Same as assay — from < to, no overlaps, no unexpected gaps.

The relationships that break

The foreign key relationships are where corruption enters. The four failure modes I see repeatedly:

Failure 1: Orphan records

An assay row with hole_id “DDH-047” that doesn’t exist in the collar table. Usually caused by a typo (DDH-047 vs DDH_047 vs DDH047). The estimation software either crashes or silently drops the records.

Prevention: Enforce referential integrity at import. Every hole_id in survey, assay, and geology must exist in collar. Reject the import if it doesn’t.

Failure 2: Interval overlap

Two assay rows for the same hole with overlapping from-to intervals: 10.0-12.0 and 11.5-13.5. The estimation software doesn’t know which assay to use for the 11.5-12.0 interval.

Prevention: Sort by hole_id, then by from. Check that each row’s from ≥ previous row’s to within the same hole. Flag overlaps at import.

Failure 3: The sort-without-select-all corruption

This is the Kalimantan case. A user sorts by one column without selecting all columns. The rows get misaligned. Hole IDs no longer correspond to the correct assays.

Prevention: Never edit the database in a spreadsheet after import. Use the database tool’s edit interface, which enforces row-level integrity. If you must use a spreadsheet for data entry, use a single sheet with all columns locked except the one being edited, and never sort.

Failure 4: Version drift

The field camp has version 3 of the database. Jakarta has version 4. The estimation consultant has version 5. Three versions of the truth. The resource estimate uses version 5. The due-diligence reviewer is given version 3.

Prevention: Single source of truth. One database, one location, one version. Field camps submit data via upload (not email attachment), and the upload creates a new version with a timestamp and contributor name. The master database is never edited — it’s only appended to.

The Indonesian field-camp-to-office workflow

The typical workflow on an Indonesian project:

1. Field camp: Geologist logs core, enters data into a spreadsheet, emails it to the Jakarta office weekly
2. Jakarta office: Data manager receives the email, copies the data into a master spreadsheet, sends the master to the estimation consultant monthly
3. Estimation consultant: Receives the master spreadsheet, imports into estimation software, runs the estimate
4. CP review: CP receives the estimation report and the data files, reviews, signs off

Where it breaks:

• Step 1 → 2: Email attachments get lost. Field camp sends “DDH_assay_week3.xlsx” but Jakarta already has a file with that name from a different project. Overwrite happens. Data lost.
• Step 2 → 3: The master spreadsheet has 15 tabs, some with formulas, some with hard-coded values. The consultant imports the wrong tab. Or the formulas don’t calculate because the spreadsheet was opened in a different version of Excel.
• Step 3 → 4: The consultant’s import creates a new database in the estimation software. The CP reviews the report but doesn’t re-check the import against the original data. If the import was wrong, the error is baked into the signed report.

The fix: A single database system that all parties access. Field camp enters data via a web form or uploads a CSV. The system validates at entry (referential integrity, interval overlap, BDL coding). Jakarta and the consultant access the same database. The CP can audit the import log. Version control is automatic — every change is timestamped and attributed.

If a full database system isn’t available, the minimum is:

• One master CSV per table (collar, survey, assay, geology)
• Version numbering (v1, v2, v3 — never overwrite, always create new version)
• Change log (what changed between versions, who made the change, when)
• MD5 checksums on files to detect silent corruption during transfer

Import validation — the last line of defense

Before any data enters the estimation database, run these checks:

These checks are non-negotiable. The getting started guide walks through how Orebit GeoSuite runs all of these automatically on import.

Version control and audit trails

Every resource estimate should be reproducible from the database. That means:

1. Database version: A version number or hash that uniquely identifies the data state used for the estimate
2. Parameter log: Every estimation parameter (top-cut, composite length, variogram model, search ellipsoid) recorded with the date and the person who set it
3. Output log: The date and parameters of every estimation run, with the output file names
4. Change log: Every change to the database after the estimation, with date, person, and reason

If an auditor asks “what data was used for the December 2025 resource estimate?”, you should be able to point to a specific database version and parameter set. If you can’t, the estimate is not auditable.

The block model validation checklist assumes the data is correct. If the database is corrupted, validation will pass — the model is consistent with the data, but the data is wrong. Database management is the upstream control that makes validation meaningful.

How Orebit GeoSuite helps

Orebit Core (Phase 01) is built as a database management tool, not just a validator:

• CSV import with validation: Upload collar, survey, assay, geology CSVs. Every import runs the 10 checks above. Failures are reported with row numbers and specific error messages. You fix the data and re-upload — the tool won’t import corrupted data.
• Single database: After import, the data lives in a single structured database within the tool. No spreadsheets, no version drift, no sort-without-select-all corruption.
• Audit trail: Every import is timestamped. Every parameter change is logged. You can reconstruct the exact data state at any point in time.
• Export for estimation: The database exports clean CSVs for Orebit Assay (Phase 02) and Orebit Resource (Phase 03). No manual data handling between phases.
• MD5 checksums: Every export includes a checksum file. If the file is corrupted during transfer, the checksum won’t match.
• Version comparison: If you import new data, the tool shows what changed (new holes, new assays, modified records) compared to the previous version.

Try Core free → · Get the bundle — Rp 99K → (single modules Rp 49K · one-time · yours forever)

Bottom line

Your resource estimate is only as good as your database. The most sophisticated kriging can’t fix corrupted data. The most experienced CP can’t catch a 12-row misalignment by looking at a report. The discipline of database management — referential integrity, version control, audit trails, import validation — is what makes the entire resource estimation chain trustworthy. Treat the database as the asset, not the estimate.

Concerned about your database integrity? Email hello@orebit.id with the database size (hole count, sample count) and I’ll tell you what to check first.