Mining Document Extraction
Breaks at the Drill Log Interval
Canadian securities law defines data verification as the process of confirming that data was generated with proper procedures, was accurately transcribed from the original source, and is suitable to be used. Accurate transcription sits inside the definition of verification, before anyone mentions a resource estimate. Most mining document projects are scoped as a reading problem: can the software handle the faded scan? The failures happen one step later, where a single interval row has to reach the drillhole database with its hole ID, its from and to depths, its unit and its sample number unchanged.

Key Takeaways
- 化验单可以读得一字不差,孔号对不上,这一整行对模型就是不存在的。
- 导入校验抓得住重叠区间和缺失孔号,对 1.24 变成 1.42 的单元格一句话都不说。
- 在 ImageToTable.ai 里把列名照抄成数据库的字段名,证书编号单独占一列,重发的化验结果才能整行换掉。
Five Kinds of Records Sit Behind One Drillhole Database

A drill program produces five record types before anyone can model the deposit, and no single role owns all of them. That split is why a value can be read perfectly on the page and still arrive wrong in the database.
The drill log is where the sample interval is decided, at the rig, on paper or in a logging app. The assay certificate comes back from the laboratory as one PDF per submitted batch, with sample IDs, element columns, units, detection limits and the control samples inserted into that batch. The QA/QC report holds the charts that decide whether a batch is usable. A technical report restates the results for investors, and environmental or permit records follow the same table logic for a regulator.
| Record | Produced by | Who acts on it | What has to survive |
|---|---|---|---|
| Drill log | Geologist at the rig | Database geologist | Hole ID, sample number, from and to depths |
| Assay certificate | Assay laboratory | Database geologist | Sample IDs, element values, units, detection limits |
| QA/QC report | Lab and company geologist | Database geologist, QP | Batch reference, standard and blank results |
| Technical report | Qualified or Competent Person | Investors, regulators | Table values that match the database they summarize |
| Environmental and permit returns | Site and environmental staff | Compliance lead, regulator | Station ID, date, analyte, unit, limit |
The drill log decides what was sampled. The assay certificate decides what the lab found. If the two disagree on the sample number, neither document is wrong and the row is still unusable.
The same pattern appears one step downstream in procurement, where weighbridge tickets and weight certificates feed settlement. That document set has its own field logic, covered in the guide to extracting weighbridge ticket data for bulk procurement.
A Drillhole Database Accepts Exactly One Shape
Geological software stores drilling data in four tables, and every document has to be reduced to one of them: collar, survey, interval and event. The collar table holds the hole ID, coordinates, elevation and total depth. The survey table holds depth, dip and azimuth readings down the hole. Interval tables hold everything measured between two depths, which is where assays and lithology live. Event tables hold single-depth observations.
Micromine documents the structure as four file types, and the same arrangement appears in Datamine, Leapfrog, Maptek and acQuire whatever the vendor calls the tables. The interval table is keyed by three fields: hole ID, from and to. A row of assays that cannot find its collar is not an incomplete row. It is invisible to the model, and to everything built on the model.
That is why an extracted spreadsheet is a staging table. Staging holds what the document said. Loading applies the schema, the codes and the validation rules the geological team agreed on. A file that skips staging has not automated the workflow; it has moved the rework to whoever now has to reconcile a finished-looking table against a page.
The Record Breaks in Four Places

Four fields decide whether a row survives the trip: hole ID, the from and to pair, the unit and detection limit, and the sample number that ties the log to the certificate.
Hole ID and its variants
The same hole appears as DDH-24-001 on the log, DDH24-001 on the certificate header, and 24-001 in a historical summary, with an A or B suffix wherever a hole was wedged. Leapfrog reports these as a duplicate hole ID or as a hole ID not in the collar table, and the intervals behind them cannot be displayed until someone decides which variant is canonical. That decision belongs to the database geologist, and it is easy to make correctly once and badly forty times.
From and to
Intervals must not overlap, must not run past the total depth, and must not run backwards. Datamine's validation notes that an overlap greater than one metre is usually a data entry error, which is a polite way of saying somebody typed a depth from the row above. A table that continues onto the next page is the other common source: the last row is repeated as a header, gets read as data, and produces an interval that duplicates the one before it.
Unit and detection limit
Laboratories print the unit once, in the column header, and print a less-than sign when a result falls below the detection limit. Both conventions break naive extraction. A gold value of <0.005 entered as 0.005 overstates the grade; entered as 0 it becomes a zero that drags down every average and cannot be plotted on a log scale. Units compound it, because gold is reported in ppm and in g/t for the same number (1 g/t equals 1 ppm) while copper switches between percent and ppm by a factor of 10,000. A column that loses its unit is a column nobody can safely combine with another.
Sample number and certificate number
The sample number is the only link between the interval in the log and the value in the certificate. It is also where labs and companies diverge, because a lab may run its own internal numbering alongside the client's, and a certificate may be re-issued after a re-run. If the certificate number does not travel with the row, a superseded result cannot be found and replaced, so both versions get loaded and one of them silently wins.
Validation Catches Structure and Misses Values
Import validation catches the structural class of error and says nothing about the value class, which is why a clean import is not a correct import.
Overlaps, reversed intervals, missing collars and depths beyond the end of the hole are all detectable from the table alone, and the major modelling packages check them on import. A grade typed as 1.42 instead of 1.24 produces no warning at all: it sits inside a valid interval, under a valid hole ID, and looks like every other number in the column. The only way to find it is to compare the cell against the page it came from, which is what the legal definition of verification describes.
The comparison is the expensive part, and the people who do it describe it as a conversion project. One r/geology thread opens with "I've been with several companies now that have been trying to convert from paper logs to digital." The British Columbia Geological Survey published a drillhole database built from more than 400 assessment reports, containing over 6,000 drillholes, 80,000 samples and 3.8 million determinations drawn from 1,300 assay certificates. That works out to roughly 60 samples per certificate and about 47 element results per sample, so a single certificate is a wide table of a few thousand cells. Their pipeline ran more than 60 verification checks on the staged spreadsheets and still sent low-confidence characters back to the original document for a person to compare by eye.
Sixty automated checks will not tell you that 1.24 became 1.42. Only a comparison against the source page will.
This is also where manual entry stops being the cheaper option. If you want the arithmetic on how field-level typing errors accumulate into record-level errors under deadline pressure, the comparison of OCR and manual data entry works through it on a document set with the same shape.
Technical Reports Are a Different Extraction Problem
A technical report restates a database that already exists, so extracting its tables gives you a summary of a summary and not a source of record.
The three regimes converge on the same point. NI 43-101 requires a written statement of whether a qualified person verified the data, how, and with what limitations, and its form asks for the verification steps and the QP's opinion on whether the data is adequate for the purpose used. The JORC Code 2012 Table 1 asks the Competent Person to document primary data, data entry procedures, data verification and storage protocols, and to discuss any adjustment to assay data. SEC Regulation S-K 1300 requires a dated and signed technical report summary from a qualified person who cannot disclaim responsibility for information supplied by a third-party specialist.
Read together, those requirements describe a chain that ends with a named person signing. Extracting a technical report is useful for due diligence, for comparing a peer's disclosed intercepts against your own ground, and for checking whether a report table matches the database it claims to summarize. It is a poor way to rebuild a database, because those tables were aggregated, rounded and filtered before they were printed.
What an Extraction Layer Has to Preserve

The extraction step has one job: produce rows whose cells can be traced back to a page and dropped into staging without being re-keyed.
ImageToTable.ai does that through Custom Column Extraction. You type the column names you want, and the AI locates the matching value anywhere on the page by understanding what the field means rather than where it sits, so a certificate with a different layout still fills the same column. The names you type become the headers of the output table, which makes the fastest route to a staging table that matches your schema a direct copy of the schema's own field names: Hole ID, Sample ID, From (m), To (m), Au (ppm), Certificate No.
A folder of certificates uploaded as one batch returns one table, with the certificate number carried in a column so a re-issued result stays findable. Multi-Page Merge groups results by a tracked column, so a log whose interval table runs onto a second page comes back as one continuous set of intervals under one hole ID instead of two unrelated tables. Computed columns cover interval length as To minus From, a conditional check that returns the difference when To is not greater than From, and unit conversion against a fixed factor such as 10,000 for percent to ppm.
Review mode highlights the exact region of the original page behind any cell, which turns verification into a click per cell instead of a scroll between two documents. Printed table data is recognized at up to 99 percent, and a page processes in seconds rather than the minutes a person needs to type it. Dense handwriting, faded carbon copies and rotated scans are where a higher processing tier earns its cost, and they are also where verification matters most.
A Workflow That Survives the Import
Five steps, and the first one happens before anything is uploaded.
Start from the schema
List the fields your interval table expects, with units, and use those names verbatim as your columns. A column called Au (ppm) cannot quietly receive a value in g/t.
Extract one row per sample
Keep the certificate number and the lab's sample ID in their own columns. Those two fields are how you find rows to replace when a certificate is re-issued.
Run the structural checks in the sheet
Interval length, reversed depths, duplicate sample IDs and missing hole IDs can all be found before the import validator sees them.
Spot-check the rows that matter
Check by source on the highest-grade intervals, on every row that failed a structural check, and on a random sample of the rest.
Hand over staging, not a database
The file goes to the database geologist with certificate numbers attached, for schema mapping, code validation and import.
If you are also comparing extraction platforms across other industrial document types, the review of extraction tools tested on manufacturing documents covers how template-based, trained and vision-model approaches differ on real field-level accuracy.
What Stays With the Geologist, the Database Administrator and the QP
Extraction ends where judgement begins, and the list of things it does not do is longer than the list of things it does.
It does not interpret geology, decide whether a lithology code is correct, desurvey a hole, run QA/QC statistics such as bias and precision on standards and duplicates, or rule on whether a batch is acceptable. It does not import into acQuire, Datamine, Micromine, Leapfrog or Maptek, estimate a resource, or offer NI 43-101, JORC or S-K 1300 compliance advice. It will not know that a certificate supersedes an earlier one unless the certificate number is in the output for a person to compare.
What remains is the part that carries the signature: the database geologist resolving discrepancies between log and certificate, the resource geologist interpreting the intervals, and the qualified or competent person verifying the data and putting a name to it.
Frequently Asked Questions
Can it read handwritten drill logs from the 1970s and 1980s?
Often, but not reliably enough to skip review. The engine handles printed text, handwriting, cursive, tables and checkboxes, and a higher processing tier improves dense handwriting. Typewritten logs with handwritten corrections, faded photocopies and rotated pages are the hard cases, so plan on checking a larger share of cells against the source page.
How should a value like <0.005 be handled?
Extract it as printed, less-than sign included, and decide the substitution inside the database where the rule can be documented. Converting it to 0.005 or to 0 during extraction hides a decision that affects every average computed from the table. A separate column holding the detection limit keeps that decision auditable.
Can it write directly into acQuire, Datamine or Leapfrog?
No. Output is Excel, CSV, JSON or Word, and the import into a geological database is done by the database geologist through the software's own import and validation tools. The API can push structured JSON into your own systems, but the field mapping and validation rules still belong to your database.
Should I extract the tables in an NI 43-101 technical report?
For review, comparison and due diligence, yes. Those tables are aggregated and filtered summaries, so they are a weak substitute for assay certificates and drill logs when the goal is building or rebuilding a database. Extract them to check a claim, not to populate a table that will feed a resource estimate.
What accuracy should I expect on assay certificates?
Printed table data is recognized at up to 99 percent, and accuracy is not the same as correctness for your database: a value can be read correctly and still land in the wrong column if the column names do not match your schema.
Do I still need a database geologist if extraction is automated?
Yes. Someone has to decide which hole ID variant is canonical, whether a batch passes QA/QC, how below-detection values are treated, and what gets loaded and in which order. Extraction reduces the typing that precedes those decisions. It does not make them.
The industry has spent a decade improving how machines read pages, and reading is rarely the reason a project stalls. What decides the outcome is smaller and duller: whether each interval row reaches the database with the same hole ID, the same from and to, the same unit and the same sample number the certificate used. Get that right and the modelling software, the QA/QC review and the qualified person all have something solid to work with.